SNI- und Wildcard-SSL-Zertifikate auf demselben Server mit IIS

Ich möchte eine Website hosten, die Subdomains (z. B. sub.domain.com) zusammen mit mehreren Websites abhören soll, die knapp unter einer Domain der zweiten Ebene (z. B. domain2.com, domain3.com) mit IIS und SSL leben.

Für die Website mit den Subdomains habe ich ein Platzhalterzertifikat (* .domain.com) und ich habe auch Zertifikate speziell für die anderen Websites (domain2.com und domain3.com).

Kann ein solches Setup auf demselben IIS gehostet werden (falls dies wichtig ist, in einer Azure Cloud Service-Webrolle)?

Das Problem ist genau das, was titobf hier erklärt hat : Theoretisch benötigen wir dafür Bindungen mit SNI, wobei der Host für domain2 / 3.com angegeben ist, und dann eine Sammelwebsite mit * host for * .domain.com. In der Praxis werden jedoch unabhängig davon, wie die Bindungen eingerichtet sind, wenn die Catch-All-Website aktiviert ist, auch alle Anfragen an domain2 / 3.com empfangen (obwohl sie angeblich nur als letztes Mittel abgeglichen werden).

Jede Hilfe wäre dankbar.

Immer noch ungelöst

Leider konnte ich das nicht lösen: Es scheint nur auf äußerst komplizierte Weise lösbar zu sein, wie das Erstellen einer Software, die sich zwischen IIS und dem Internet befindet (also im Grunde eine Firewall) und eingehende Anforderungen ändert (bevor der SSL-Handshake stattfindet! ), um das Szenario zuzulassen. Ich bin ziemlich sicher, dass dies mit IIS nicht möglich ist, egal was passiert, auch nicht mit einem nativen Modul.

Ich muss klarstellen: Wir verwenden Azure Cloud Services, daher haben wir eine weitere Einschränkung, dass wir nicht mehrere IP-Adressen verwenden können (siehe: http://feedback.azure.com/forums/169386-cloud-services-web-and -Werkerrolle / Vorschläge / 1259311-mehrere-SSL-und-Domänen-zu-einer-App ). Wenn Sie mehrere IPs auf Ihren Server verweisen können, tritt dieses Problem nicht auf, da Sie auch Bindungen für IPs erstellen können und diese Platzhalterbindungen zusammenarbeiten. Insbesondere benötigen Sie eine IP für die Wildcard-Site (da Sie jetzt eine separate IP haben, müssen Sie keine Bindung für den Wildcard-Hostnamen konfigurieren) und eine andere IP für alle anderen Nicht-Wildcard-Sites.

Tatsächlich bestand unsere Problemumgehung in der Verwendung eines nicht standardmäßigen SSL-Ports, 8443. Die SNI-Bindung ist also tatsächlich an diesen Port gebunden und funktioniert daher zusammen mit den anderen Bindungen. Nicht schön, aber eine akzeptable Problemumgehung für uns, bis Sie mehrere IPs für Webrollen verwenden können.

Die nicht funktionierenden Bindungen jetzt

Die erste https-Bindung ist SNI mit einem einfachen Zertifikat, die zweite ist nicht SNI mit einem Platzhalterzertifikat.

Die http-Site funktioniert ebenso wie die SNI-https-Site, aber die mit der Platzhalterbindung gibt einen "HTTP-Fehler 503" aus. Der Dienst ist nicht verfügbar. (ohne weitere Informationen, keine fehlgeschlagene Anforderungsverfolgung oder Ereignisprotokolleintrag).

Endlich funktioniert es im Grunde

Das Aktivieren des ETW-Ablaufverfolgungsprotokolls wie von Tobias beschrieben zeigte, dass der Grundfehler der folgende war:

Anfrage (Anforderungs-ID 0xF500000080000008) aus folgendem Grund abgelehnt: UrlGroupLookupFailed.

Soweit ich weiß, bedeutet dies, dass http.sys die Anforderung nicht an einen verfügbaren Endpunkt weiterleiten kann.

Das Überprüfen der registrierten Endpunkte mit netsh http show urlaclergab, dass tatsächlich etwas für Port 443 registriert war:

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

Das Entfernen mit netsh http delete urlacl url=https://IP:443/endlich aktivierter SSL-Bindung.

Baris hat recht! Das für eine IP: PORT-Bindung konfigurierte SSL-Zertifikat (Beispiel: 100.74.156.187:443) hat in http.sys immer Vorrang! Die Lösung lautet also wie folgt:

Konfigurieren Sie keine IP: 443-Bindung für Ihr Wildcard-Fallback-Zertifikat, sondern konfigurieren Sie eine *: 443-Bindung (* bedeutet "Alle nicht zugewiesen") dafür .

Wenn Sie Ihr Platzhalterzertifikat auf dem Azure Cloud Service-SSL-Endpunkt konfiguriert haben (wie ich), müssen Sie die von der Azure Cloud Service-Laufzeit (IISconfigurator.exe) erstellte SSL-Bindung von IP: PORT in *: PORT ändern. Ich rufe in OnStart der folgenden Methode meiner Webrolle auf:

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());
        }
    }
}

Der folgende Screenshot zeigt eine funktionierende Konfiguration unseres Cloud-Dienstes. Bitte verwechseln Sie nicht die nicht standardmäßigen Ports. Der Screenshot stammt vom emulierten Cloud-Dienst.

Eine weitere zu erwähnende Sache: Ändern Sie nicht alle Bindungen in *, da die HTTP-Bindung (Port 80) nur mit der IP: PORT-Bindung im bereitgestellten Cloud-Dienst funktioniert. Etwas anderes ist an IP: 80 gebunden, daher funktioniert *: 80 nicht, da * für "alle nicht zugewiesen" steht und die IP bereits an einer anderen Stelle in http.sys zugewiesen ist.

Stellen Sie sicher, dass Ihre Sammelbindung nicht vom Typ IP: Port ist. Wenn für eine HTTPS-Bindung eine IP: Port-Bindung vorhanden ist, während keine SNI erforderlich ist, hat diese Bindung immer Vorrang. Verwenden Sie für Ihren Sammelfall eine *: Port-Bindung (* ist die nicht zugewiesene).

IIS unterstützt SNI auch in Azure Cloud Service-Webrollen, obwohl Sie nicht über das Portal zur Konfiguration gelangen können. Wenn Sie dies nach der Bereitstellung auf der Box tun, wird es bei Ihrer nächsten Bereitstellung gelöscht. Die Lösung besteht darin, die Konfiguration zu automatisieren. Schauen Sie hier für Details:

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