Certificati SSL SNI e jolly sullo stesso server con IIS

Vorrei ospitare un sito Web che dovrebbe ascoltare i sottodomini (ad esempio sub.dominio.com) insieme a più siti Web che vivono appena sotto un dominio di secondo livello (ad esempio dominio2.com, dominio3.com) con IIS e con SSL.

Per il sito Web con i sottodomini ho un certificato con caratteri jolly (* .domain.com) e ho anche certificati specifici per gli altri siti (domain2.com e domain3.com).

È possibile ospitare tale configurazione nello stesso IIS (se ciò è importante, in un ruolo Web del servizio cloud di Azure)?

Il problema è esattamente ciò che titobf ha spiegato qui : teoricamente per questo avremmo bisogno di collegamenti usando SNI, con l'host specificato per domain2 / 3.com e quindi un sito Web generico con * host per * .domain.com. Ma in pratica, indipendentemente dal modo in cui i collegamenti sono impostati se il sito Web generale è su di esso, riceverà anche tutte le richieste a domain2 / 3.com (anche se presumibilmente è abbinato solo come ultima risorsa).

Qualsiasi aiuto sarebbe apprezzato.

Ancora irrisolto

Purtroppo non sono stato in grado di risolverlo: sembra essere risolvibile solo in modi estremamente complicati, come la creazione di un software che si trova tra IIS e Internet (quindi sostanzialmente un firewall) e modifica le richieste in arrivo (prima che avvenga l'handshake SSL! ) per consentire lo scenario. Sono abbastanza sicuro che questo non sia possibile con IIS, indipendentemente da quale sia un modulo nativo.

Devo chiarire: usiamo Azure Cloud Services, quindi abbiamo un ulteriore vincolo che non possiamo usare più indirizzi IP (vedere: http://feedback.azure.com/forums/169386-cloud-services-web-and -worker-role / suggestions / 1259311-multiple-ssl-and-domains-to-one-app ). Se puoi indirizzare più IP al tuo server, non hai questo problema poiché puoi creare collegamenti anche per IP, e questi funzioneranno insieme collegamenti jolly. Più specificamente, è necessario un IP per il sito jolly (ma poiché si dispone di un IP separato ora non è necessario configurare un'associazione del nome host jolly) e un altro IP per tutti gli altri non jolly.

In realtà la nostra soluzione alternativa era l'uso di una porta SSL non standard, 8443. Quindi l'associazione SNI è in realtà associata a questa porta, quindi funziona insieme alle altre associazioni. Non carino, ma una soluzione accettabile per noi fino a quando non puoi utilizzare più IP per ruoli Web.

I vincoli non funzionanti ora

La prima associazione https è SNI con un certificato semplice, la seconda non è SNI, con un certificato jolly.

Il sito http funziona, così come il sito https SNI, ma quello con l'associazione jolly fornisce un "Errore HTTP 503. Il servizio non è disponibile." (senza ulteriori informazioni, nessuna traccia di richiesta non riuscita o voce del registro eventi).

Finalmente funziona praticamente

L'abilitazione del registro di traccia ETW come descritto da Tobias ha mostrato che l'errore di root era il seguente:

Richiesta (ID richiesta 0xF500000080000008) rifiutata a causa del motivo: UrlGroupLookupFailed.

A quanto ho capito, ciò significa che http.sys non è in grado di indirizzare la richiesta a nessun endpoint disponibile.

Il controllo degli endpoint registrati con ha netsh http show urlaclmostrato che c'era effettivamente qualcosa registrato per la porta 443:

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

Rimuovendolo con netsh http delete urlacl url=https://IP:443/finalmente abilitato il mio binding SSL.

Baris ha ragione! Il certificato SSL configurato su un binding IP: PORT (esempio: 100.74.156.187:443) ha sempre la precedenza in http.sys! Quindi la soluzione è la seguente:

Non configurare un'associazione IP: 443 per il certificato con caratteri jolly di fallback, ma configurare un'associazione *: 443 (* significa "Tutti non assegnati") .

Se il certificato con caratteri jolly è stato configurato sull'endpoint SSL del servizio cloud di Azure (come ho fatto io), è necessario modificare l'associazione SSL creata da Azure Cloud Service Runtime (IISconfigurator.exe) da IP: PORT a *: PORT. Sto chiamando il seguente metodo in OnStart del mio ruolo 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 seguente schermata mostra una configurazione funzionante del nostro servizio cloud. Non essere confuso riguardo alle porte non standard. Lo screenshot proviene dal servizio cloud emulato.

Un'altra cosa da menzionare: non modificare tutti i binding in * perché l'associazione HTTP (porta 80) funziona solo con l'associazione IP: PORT nel servizio cloud distribuito. Qualcos'altro è associato a IP: 80, quindi *: 80 non funziona perché * sta per "tutti non assegnati" e l'IP è già assegnato altrove in http.sys.

Assicurati che il bind non sia del tipo IP: Porta. Quando esiste un IP: l'associazione della porta per un'associazione HTTPS mentre SNI non è richiesta, tale associazione avrà sempre la precedenza. Per il tuo caso generale, usa un *: Port binding (* essendo il tutto non assegnato).

IIS supporta SNI, anche nei ruoli Web del servizio cloud azzurro anche se non è possibile accedere alla configurazione attraverso il portale e se lo si fa sulla scatola dopo la distribuzione, verrà cancellato con la distribuzione successiva. La soluzione è automatizzare la configurazione. Dai un'occhiata qui per i dettagli:

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