fragen stichworte

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, die nur unter einer Second-Level-Domäne (z. B. domain2.com, domain3.com) leben, mit IIS und mit SSL.

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

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

Das Problem ist genau das, was titobf hier erläutert hat:: theoretisch würden wir Bindungen über SNI benötigen, wobei der Host für domain2/3.com und dann eine Catch-All-Website mit * host für angegeben ist * .domain.com. Unabhängig davon, wie die Bindungen eingerichtet werden, wenn die catch-all-Website aktiviert ist, werden auch alle Anfragen an domain2/3.com empfangen (obwohl dies angeblich nur als letzter Ausweg erfolgt).

Jede Hilfe wäre dankbar.

Noch nicht gelöst

Leider konnte ich das nicht lösen: Es scheint nur auf äußerst komplizierte Weise lösbar zu sein, z. B. das Erstellen einer Software, die zwischen IIS und dem Internet (also im Wesentlichen einer Firewall) liegt und eingehende Anforderungen modifiziert (vor dem SSL-Handshake) findet statt!) um das Szenario zu ermöglichen. Ich bin ziemlich zuversichtlich, dass dies mit IIS nicht möglich ist, egal was passiert, nicht einmal aus einem nativen Modul.

Ich muss Folgendes 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-worker-role/suggestions/1259311-multiple-ssl-and-domains-zu-one-app). Wenn Sie mehrere IP-Adressen auf Ihren Server verweisen können, besteht dieses Problem nicht, da Sie auch Bindungen für IP-Adressen erstellen können und diese Platzhalter-Bindungen zusammenarbeiten. Insbesondere benötigen Sie eine IP-Adresse für die Wildcard-Site (da Sie jetzt jedoch eine separate IP-Adresse haben, müssen Sie keine Wildcard-Hostnamenbindung konfigurieren) und eine andere IP-Adresse für alle anderen, die keine Wildcard sind.

Unsere Problemumgehung bestand in der Verwendung eines nicht standardmäßigen SSL-Ports (8443). Daher ist die SNI-Bindung tatsächlich an diesen Port gebunden, sodass sie mit den anderen Bindungen zusammenarbeitet. Nicht schön, aber eine akzeptable Lösung 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, die mit der Platzhalterbindung erhält jedoch den Hinweis "HTTP-Fehler 503". Der Dienst ist nicht verfügbar. (ohne weitere Informationen, keine fehlgeschlagene Anforderungsverfolgung oder Ereignisprotokolleintrag). Bindings

Endlich funktioniert es

Wenn das ETW-Traceprotokoll wie von Tobias beschrieben aktiviert wurde, zeigte sich, dass der Root-Fehler der folgende war:

Request (request ID 0xF500000080000008) rejected due to reason: UrlGroupLookupFailed.

Meines Wissens bedeutet dies, dass http.sys die Anforderung nicht an einen verfügbaren Endpunkt weiterleiten kann.

Die Überprüfung der registrierten Endpunkte mit netsh http show urlacl ergab, dass tatsächlich etwas für Port 443 registriert wurde:

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

Durch das Entfernen von netsh http delete urlacl url=https://IP:443/ wurde schließlich meine SSL-Bindung aktiviert.

antworten

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

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

Wenn Sie Ihr Platzhalterzertifikat auf dem Azure Cloud Service-SSL-Endpunkt (wie ich) konfiguriert haben, müssen Sie die von der Azure Cloud Service-Laufzeit (IISconfigurator.exe) erstellte SSL-Bindung von IP: PORT in *: PORT ändern. Ich rufe die folgende Methode in OnStart 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-Service. Bitte verwechseln Sie die nicht standardmäßigen Ports nicht. Der Screenshot stammt vom emulierten Cloud-Service.

working IIS configuration

Eine weitere Bemerkung: Ändern Sie nicht alle Bindungen in *, da die HTTP-Bindung (Port 80) nur mit der IP: PORT-Bindung im bereitgestellten Cloud-Service funktioniert. Etwas anderes ist an IP: 80 binden, daher funktioniert *: 80 nicht, da * für "Alle nicht zugewiesen" steht und die IP bereits an anderer Stelle in http.sys zugewiesen ist.

Stellen Sie sicher, dass Ihre Catch-all-Bindung nicht vom Typ IP: Port ist. Wenn eine IP: Port-Bindung für eine HTTPS-Bindung existiert, während SNI nicht benötigt wird, hat diese Bindung immer Vorrang. Für Ihren Catch-All-Fall verwenden Sie eine *: Port-Bindung (* ist alles nicht zugewiesen).

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

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