Certificats SSL SNI et génériques sur le même serveur avec IIS


12

Je voudrais héberger un site Web qui devrait écouter des sous-domaines (par exemple, sub.domain.com) ainsi que plusieurs sites Web qui vivent juste sous un domaine de deuxième niveau (par exemple, domain2.com, domain3.com) avec IIS et SSL.

Pour le site Web avec les sous-domaines, j'ai un certificat générique (* .domain.com) et j'ai également des certificats spécifiquement pour les autres sites (domain2.com et domain3.com).

Une telle configuration peut-elle être hébergée sur le même IIS (si cela est important, dans un rôle Web Azure Cloud Service)?

Le problème est exactement ce que titobf a expliqué ici : pour cela, nous aurions besoin de liaisons en utilisant SNI, avec l'hôte spécifié pour domain2 / 3.com, puis un site Web fourre-tout avec * host pour * .domain.com. Mais dans la pratique, peu importe la façon dont les liaisons sont configurées si le site Web fourre-tout est activé, il recevra également toutes les demandes adressées à domain2 / 3.com (bien qu'il ne soit supposé correspondre qu'en dernier recours).

Toute aide serait appréciée.

Pas encore résolu

Malheureusement, je n'ai pas été en mesure de résoudre ce problème: il semble être résolu uniquement de manière extrêmement compliquée, comme la création d'un logiciel qui se situe entre IIS et Internet (donc essentiellement un pare-feu) et modifie les demandes entrantes (avant la prise de contact SSL! ) pour autoriser le scénario. Je suis assez confiant que ce n'est pas possible avec IIS, quoi qu'il arrive, même pas à partir d'un module natif.

Je dois clarifier: nous utilisons Azure Cloud Services, nous avons donc une contrainte supplémentaire de ne pas pouvoir utiliser plusieurs adresses IP (voir: http://feedback.azure.com/forums/169386-cloud-services-web-and -worker-role / suggestions / 1259311-multiple-ssl-and-domains-to-one-app ). Si vous pouvez pointer plusieurs adresses IP vers votre serveur, vous n'avez pas ce problème car vous pouvez également créer des liaisons pour les adresses IP, et celles-ci fonctionneront ensemble avec des liaisons génériques. Plus précisément, vous avez besoin d'une IP pour le site générique (mais comme vous avez maintenant une IP distincte, vous n'aurez plus à configurer une liaison de nom d'hôte générique) et une autre IP pour tous les autres non génériques.

En fait, notre solution de contournement consistait à utiliser un port SSL non standard, 8443. La liaison SNI est donc réellement liée à ce port, elle fonctionne donc avec les autres liaisons. Pas sympa, mais une solution de contournement acceptable pour nous jusqu'à ce que vous puissiez utiliser plusieurs IP pour les rôles Web.

Les fixations non fonctionnelles maintenant

La première liaison https est SNI avec un certificat simple, la seconde n'est pas SNI, avec un certificat générique.

Le site http fonctionne, ainsi que le site SNI https, mais celui avec la liaison générique donne une «erreur HTTP 503. Le service n'est pas disponible». (sans aucune autre information, pas de suivi de la demande d'échec ou d'entrée du journal des événements). Liaisons

Enfin le faire fonctionner fondamentalement

L'activation du journal de suivi ETW comme Tobias décrit a montré que l'erreur racine était la suivante:

Demande (ID de demande 0xF500000080000008) rejetée pour la raison: UrlGroupLookupFailed.

Pour autant que je sache, cela signifie que http.sys n'est pas en mesure d'acheminer la demande vers un point de terminaison disponible.

La vérification des points d'extrémité enregistrés avec a netsh http show urlaclmontré qu'il y avait effectivement quelque chose d'enregistré pour le port 443:

Reserved URL            : https://IP:443/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

La suppression de ceci a netsh http delete urlacl url=https://IP:443/finalement activé ma liaison SSL.


Vous devez absolument être en mesure de le faire sur IIS à l'aide de SNI, sans avoir recours à plusieurs adresses IP ou ports non standard.
Joe Sniderman

Vous voulez dire que IIS devrait prendre en charge cela? Je suis d'accord :-).
Piedone du

Je suis totalement d'accord avec toi, Piedone. Je suis vraiment déçu que IIS (ou pour être plus précisément http.sys) ne prenne PAS en charge la combinaison d'un certificat générique comme certificat SSL par défaut et de plusieurs certificats concrets avec SNI COMME ATTENDU. Le problème est bien connu depuis 2012 comme vous pouvez le voir ici: forums.iis.net/t/1192170.aspx . Je viens d'écrire un e-mail à Microsoft et j'espère recevoir rapidement des commentaires.
Tobias J.27

Merci Tobias. Veuillez revenir ici une fois que Microsoft aura répondu.
Piedone

2
Http.sys refuse probablement la demande, donc aucune demande ayant échoué n'est enregistrée dans IIS. Créez un journal de trace http.sys ETW: 1) lancez le journal de trace. exécuter: logman start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl -ets2) faire la demande 503 3) arrêter le journal de suivi. exécuter: logman stop httptrace -ets4) écrire le journal de suivi dans le fichier. run: tracerpt.exe httptrace.etl -of XML -o httptrace.xml5) vérifiez la raison de 503 dans le fichier xml et postez-le ici.
Tobias

Réponses:


6

Baris a raison! Le certificat SSL configuré sur une liaison IP: PORT (exemple: 100.74.156.187:443) a toujours la priorité dans http.sys! La solution est donc la suivante:

Ne configurez pas une liaison IP: 443 pour votre certificat de remplacement générique, mais configurez une liaison *: 443 (* signifie "Tous non attribués") pour cela .

Si vous avez configuré votre certificat générique sur le point de terminaison SSL Azure Cloud Service (comme je l'ai fait), vous devez modifier la liaison SSL créée par Azure Cloud Service Runtime (IISconfigurator.exe) de IP: PORT à *: PORT. J'appelle la méthode suivante dans OnStart de mon rôle Web:

public static void UnbindDefaultSslBindingFromIp()
{
    Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
    using (var serverManager = new Microsoft.Web.Administration.ServerManager())
    {
        try
        {
            var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
            var site = serverManager.Sites[websiteName];
            var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
            defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
            serverManager.CommitChanges();
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.ToString());
        }
    }
}

La capture d'écran suivante montre une configuration de travail de notre service cloud. Veuillez ne pas être confus au sujet des ports non standard. La capture d'écran provient du service cloud émulé.

configuration IIS fonctionnelle

Une autre chose à mentionner: ne changez pas toutes les liaisons en * car la liaison HTTP (port 80) ne fonctionne qu'avec la liaison IP: PORT dans le service cloud déployé. Quelque chose d'autre est lié à IP: 80, donc *: 80 ne fonctionne pas car * signifie "tout non attribué" et l'adresse IP est déjà attribuée ailleurs dans http.sys.


Merci pour votre réponse détaillée. J'ai mis à jour ma question: si je me souviens bien maintenant, je n'ai probablement pas choisi cette configuration car j'ai eu la même erreur que maintenant.
Piedone

4

Assurez-vous que votre liaison fourre-tout n'est pas de type IP: Port. Lorsqu'une liaison IP: Port existe pour une liaison HTTPS alors que SNI n'est pas requis, cette liaison aura toujours la priorité. Pour votre cas fourre-tout, utilisez une liaison *: Port (* étant le tout non attribué).


Merci, mais comme vous pouvez le voir dans ma description, j'ai d'abord essayé de configurer la liaison SNI sans port, mais comme cela ne fonctionnait pas, je me suis retrouvé avec une liaison de port personnalisée.
Piedone

Par port, je suppose que vous voulez dire l'IP. Vous ne pouvez pas avoir de liaison sans port. Inetmgr ne le permettra pas. Pour les liaisons SNI, vous pouvez utiliser l'IP spécifique ou "All Unassigned" et le résultat sera le même. C'est la liaison Catch All, pour laquelle vous avez un certificat générique, qui doit être sur "All Unassigned" et non sur une IP spécifique.
bariscaglar

Je voulais dire port mais je voulais dire "port non standard". L'IP n'a pas été spécifiée, comme vous le dites et cela ne fonctionne toujours pas, voir aussi le lien de Tobias. Il existe deux façons de contourner cette limitation d'IIS: utilisez un port personnalisé ou une IP différente des autres liaisons: sur les services cloud Azure, cette dernière n'est pas disponible, nous avons donc opté pour un port personnalisé.
Piedone

bariscaglar est le développeur Microsoft (travaillant sur IIS) avec qui j'ai eu une conversation très agréable et utile! Thx Baris! Ensemble, nous avons analysé le comportement et nous sommes arrivés à la conclusion que le comportement décrit est le comportement souhaité de http.sys. Mais il existe une bonne solution de contournement. Voir ma réponse pour plus de détails.
Tobias J.

Juste une note pour tous ceux qui lisent, j'ai récemment découvert que si vous utilisez le portail Azure pour configurer un service pour le bureau à distance (ou sinon changer la configuration du certificat), cela peut provoquer la création automatique d'une liaison IP: Port et casser tous vos SNI . Je n'ai pas de solution à ce problème particulier. Cela se produit après RoleEnvironment.Changed, donc je ne peux pas l'attraper dans WebRole.cs.
Mike

1

IIS prend en charge SNI, même dans les rôles Web de service cloud azur bien que vous ne puissiez pas accéder à la configuration via le portail et si vous le faites sur la boîte après le déploiement, il sera effacé avec votre prochain déploiement. La solution est d'automatiser la configuration. Jetez un œil ici pour plus de détails:

http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/


Merci, mais comme je l'ai expliqué, il n'y a pas de problème avec SNI lui-même (je l'utilise), mais plutôt comment la correspondance des noms d'hôtes génériques fonctionne dans IIS.
Piedone

Cet article n'existe plus, mais le voici sur les archives Web: web.archive.org/web/20151020041907/http://www.vic.ms/microsoft/…
Mike
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.