☰

SSL-Fehler auf der Auzre-Webfarm mit gemeinsam genutzter Konfiguration und zentralisierten Zertifikaten

tag-icon • tag-icon ssl certificate iis windows-server-2012 azure
SSL-Fehler auf der Auzre-Webfarm mit gemeinsam genutzter Konfiguration und zentralisierten Zertifikaten

[Entschuldigen Sie, wenn die Frage etwas lang ist. Es gibt viele zusätzliche Informationen, falls sie relevant sind.]

Überblick

Ich habe ein Problem mit SSL auf einer lastausgeglichenen Farm mit 4 VMs in Azure. Wenn die HTTPS-Anforderung an den ersten Server in der Farm geht, ist alles in Ordnung. Wenn sie bei einem der anderen 3 ankommt, schlägt der Aufruf fehl. Chrome gibt einen SSL-Protokollfehler aus, IE und Firefox sagen einfach, dass die Seite nicht angezeigt werden kann.

Die Einrichtung

Ich habe vier Windows Server 2012-VMs auf Azure (kleine Instanz, nur zum Testen). Die VMs befinden sich im selben Cloud-Dienst und Verfügbarkeitsset. Lastenausgleichsendpunkte wurden für die Ports 80 und 443 hinzugefügt (direkte Serverrückgabe istNICHTaktiviert). Alle vier Maschinen wurden über dasselbe PowerShell-Skript eingerichtet und mit zwei Ausnahmen vollständig auf diese Weise konfiguriert.

Die IIS-Konfiguration jedes Servers ist so eingestellt, dass eine freigegebene Konfiguration verwendet wird, die über DFS vom ersten Server in der Gruppe auf jeden Server repliziert wird. Dies wurde für jeden Server manuell konfiguriert und funktioniert einwandfrei.

DFS wird auch verwendet, um den Webordner vom ersten Server auf die anderen zu replizieren.

Ich habe auch die „neue“ Funktion für zentralisierte Zertifikate entdeckt, nachdem ich das Bereitstellungsskript geschrieben hatte. Daher wurde diese Funktion auch auf den vier Servern manuell installiert und konfiguriert. Ich verwende eine Freigabe auf einem separaten Server, um die Zertifikatsdateien zu speichern.

Die Zertifikatsanforderung wurde auf dem ersten Server generiert und ich habe SSL.com verwendet, um ein kostenloses 90-Tage-SSL für eine Adresse zu erhalten . Ich habe dem DNS subdomain.domain.comeinen CNAME-Eintrag hinzugefügt, um auf die Azure- Adresse zu verweisen.subdomaindomain.comcloudapp

Ich habe das SSL-Zertifikat auf dem ersten Server importiert, es dann erneut exportiert subdomain.domain.com.pfx(mit einem Passwort) und es in die Zertifikatsdateifreigabe kopiert. Beim Überprüfen der zentralisierten Zertifikate auf allen vier Servern wird das Zertifikat einwandfrei aufgelistet, ohne Fehlersymbole, die darauf hinweisen, dass das Passwort in der Konfiguration falsch war usw.

Schließlich habe ich die Bindungen von Server 1 geändert, um https mit Hostnamen hinzuzufügen subdomain.domain.com, und mit demAngabe des Servernamens erforderlichUndZentralisierten Zertifikatspeicher verwendenOptionen aktiviert. Beim Überprüfen der anderen Server werden die Bindungen wie erwartet weitergegeben.

Das Problem

Ich habe eine einfache Seite hinzugefügt, die einfach den Namen des Servers ausgibt, von dem die Anfrage bearbeitet wurde. Wenn ich mehrere IE-Fenster über eine Shell darauf zugreife http://subdomain.domain.com, drucken sie eine Reihe von Servernamen aus, was zeigt, dass die IIS-Konfigurations- und Webdateien korrekt bereitgestellt werden und dass das Azure-Loadbalancing-Ding auch seine Arbeit macht. Das fand ich eigentlich echt cool.

Allerdings geht es schief, wenn ich es über HTTPS versuche. Nur die Anfragen, die den ersten Server erreichen, sind erfolgreich, der Rest stürzt ab und wird mit „Diese Seite kann nicht angezeigt werden“ oder „SSL-Protokollfehler“ angezeigt, je nachdem, mit welchem ​​Browser ich teste. Auf Server 1 wird die Seite einwandfrei angezeigt, das Zertifikat ist sichtbar und es gibt keine Zertifikatsfehler.

Ich bin sicher, dass es sich hier um ein Konfigurationsproblem irgendwo auf den Servern handelt, aber ich kann einfach nicht sagen, was in aller Welt es ist. Das meiste, womit ich spiele, ist neu für mich, da wir in der Vergangenheit physische, nicht geclusterte Windows 2003-Server mit IIS6 verwendet haben.

Noch rätselhafter ist, dass ich die vier VMs über Nacht heruntergefahren habe und als ich den Dienst heute Morgen neu gestartet habe, reagiert nun offenbar neben Server 1 auch Server 2 auf SSL-Anfragen. Allerdings hatte ich gestern auch einen vollständigen Shutdown durchgeführt und trotzdem funktionierte danach nur Server 1.

Die IIS-Protokolldateien zeigen die fehlgeschlagenen SSL-Anfragen nicht an, sondern nur eine Reihe von 200ern für Port 80 und eine Mischung aus 200 und 304 für Port 443 auf Server 1 und 2.

Ich habe einige sorgfältige Google-Suchen durchgeführt, aber nichts hat Licht ins Dunkel gebracht. Das genaue Gegenteil ist der Fall. Soweit ich das beurteilen kann, sollte das, was ich getan habe, einfach funktionieren.

Jeder Ratschlag zur Lösung dieses Problems ist willkommen.

Antwort1

Ich möchte Ihnen einige Schritte erläutern, mit denen die meisten Probleme mit dem zentralisierten Zertifikatspeicher auf IIS behoben werden können. Der zentralisierte Zertifikatspeicher (CCS) erstellt eine falsche Zertifikatsbindung, mit der SSL-Zertifikatsanforderungen an den CCS weitergeleitet werden. Wenn diese Bindung nicht vorhanden ist oder mehrere Bindungen an dieselbe IP-Adresse angelegt werden, werden Browserfehler angezeigt, wenn Clients versuchen, eine Verbindung zu SSL-fähigen Websites herzustellen.

Stellen Sie sich das folgende Setup vor: Ein IIS-Server mit IP-Adresse 172.16.0.41und aktiviertem zentralisierten Zertifikatspeicher enthält zwei Domänen. Für jede der Domänen sind PFX-Zertifikatpakete im zentralisierten Zertifikatspeicher von IIS installiert.www.adomain.comwww.bdomain.com

Normalerweise gibt es zwei Fehler;

PROBLEM 1

Wenn Browser eine Verbindung zur Website herstellen, wird das falsche Zertifikat weitergegeben. Wenn ein Browser beispielsweise www.adomain.comzum ersten Mal auf zugreift, wird das richtige Zertifikat bereitgestellt. Wenn ein Browser jedoch auf zugreift www.bdomain.com, wird das Zertifikat für www.adomain.comzurückgegeben, was dazu führt, dass der Browser einen Fehler mit einem ungültigen Zertifikat meldet.

LÖSUNG

Der Grund für dieses Problem liegt normalerweise darin, dass mehrere Websites an dieselbe IP-Adresse gebunden sind und mindestens eine der Websites nicht aktiviert istIdentifizierung des Servernamens erforderlich. Wenn diese Einstellung nicht für alle Websites aktiviert ist, die dieselbe IP-Adresse und denselben Port verwenden, kann IIS nicht bestimmen, welches Zertifikat verwendet werden soll.der erste gewinntDie Richtlinie scheint zu gelten.

Dies bedeutet, dass nachfolgende Anfragen an andere Websites, die auf demselben IIS-Server gehostet werden, das falsche Zertifikat zurückgeben.

Schritte zur Lösung

  1. Stellen Sie sicher, dass alle Websites auf eingestellt sind Require Server Name Identification. Klicken Sie dazu im IIS-Manager auf die einzelnen Websites und wählen Sie Bindungen... -> HTTPS-Bindung auswählen -> Bearbeiten auswählen -> Prüfen. Require Server Name IdentificationStellen Sie sicher, Use Centralized Certificate Storedass auch geprüft wurde.

  2. Überprüfen Sie die Bindungen auf dem Server. Führen Sie in einem erhöhten Befehlsfeld Folgendes aus:netsh http show sslcert

Die Bindung für das CCS sollte vorhanden sein:

SSL Certificate bindings:
------------------------- 

Central Certificate Store    : 443
Certificate Hash             : (null)
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Beachten Sie, dass die Bindung mit dem (null)Zertifikat-Hash das Vorhandensein der CCS-Passthrough-Bindung anzeigt. Wenn andere Bindungen auf der IP-Adresse Ihres Servers und dem SSL-Port ( 172.16.0.41:443in unserem Szenario) lauschen, müssen diese entfernt werden.

  1. Um die Bindungen zu entfernen, geben Sie ein netsh http delete sslcert <binding>. In unserem Szenario wäre dies netsh http delete sslcert 172.16.0.41:443und die Bindung sollte entfernt werden. Die (null)CCS-Passthrough-Bindung sollte nicht entfernt werden. Wenn diese Bindung nicht vorhanden ist, siehePROBLEM 2unten.

  2. Setzen Sie IIS zurück iisresetund stellen Sie eine Verbindung zu jeder Domäne auf dem Webserver her. Das richtige Zertifikat sollte freigegeben sein. Sie können die Bindungen auch überprüfen, indem Sie Schritt 2 wiederholen und sicherstellen, dass keine spezifischen IP:PORTBindungen an Ihren SSL-Port und Ihre Webserver-IP vorhanden sind.

PROBLEM 2

Auch wenn Sie bestätigt haben, dass der zentrale Zertifikatspeicher aktiviert ist, die Zertifikate sichtbar sind und alle Websites ihn verwenden müssen, wird beim Herstellen einer Verbindung mit der Website durch einen Browser ein Fehler ausgegeben Page Cannot be displayed. invalid encryptionDie gewünschte Website wird nicht angezeigt.

Im Internet Explorer (Edge) äußert sich dies typischerweise in einem Vorschlag, zu überprüfen, ob im Browser die entsprechenden Verschlüsselungsarten aktiviert sind.

Ein iisresetNeustart des Servers behebt das Problem nicht.

LÖSUNG

Dies scheint ein Fehler bei der Erstellung der CCS-Passthrough-Bindung zu sein. Sie wird nicht auf dem Webserver erstellt, wenn die CCS-Funktionalität aktiviert ist, sodass eingehende Anforderungen für ein Zertifikat stillschweigend gelöscht werden.

Schritte zur Lösung

  1. Überprüfen Sie zunächst, ob der zentrale Zertifikatspeicher aktiviert wurde und alle Zertifikate in seinem Pfad angezeigt werden. Wählen Sie dazu IISManagerden Serverknoten -> Zentrale Zertifikate (im Abschnitt „Verwaltung“) -> Funktionseinstellungen bearbeiten und stellen Sie sicher, dass er konfiguriert und aktiviert ist.

  2. Überprüfen Sie, ob alle Websites, die allgemeine Zertifikate verwenden, an CCS gebunden sind. Klicken Sie dazu im IIS-Manager auf jede Website, wählen Sie Bindungen... -> HTTPS-Bindung auswählen -> Bearbeiten auswählen -> Überprüfen Require Server Name Identificationund stellen Sie sicher Use Centralized Certificate Store, dass auch überprüft wird.

  3. Überprüfen Sie, ob die CCS-Bindung erstellt wurde. Führen Sie den Befehl aus netsh http show sslcert. Wenn die Ergebnisse leer sind oder das (null)Pass-Through-Zertifikat nicht vorhanden ist (siehe Schritt 2 unter PROBLEM 1, um zu sehen, wie die CCS-Bindung aussieht), wurde die CCS-Bindung nicht aktiviert.

    SSL Certificate bindings:
-------------------------

  4. Wählen Sie im IIS-Manager eine Website aus, die CCS verwendet, und klicken Sie auf Bindungen...->Wählen Sie die HTTPS-Bindung aus->Wählen Sie Bearbeiten->unddeaktivieren Use Centralized Certificate StoreUnddeaktivieren Require Server Name Identification.

Wählen Sie in der SSL certificateDropdown-Liste das Standardzertifikat des Servers aus WMSVCund klicken Sie auf OK. Lassen Sie das Site BindingsFenster geöffnet.

  1. Wechseln Sie zurück zur Eingabeaufforderung mit erhöhten Rechten und führen Sie aus netsh http show sslcert. Dies sollte eine Bindung wie die folgende ergeben:

    SSL Certificate bindings:
------------------------- 
IP:port                      : 172.16.0.41:443
Certificate Hash             : 64498c920fecb31b8f7ccbdac2fa2baa2ec4f19a
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

  2. Kehren Sie zum Site BindingsFenster zurück und machen Sie die Änderungen aus Schritt 4 rückgängig. Aktivieren Sie Require Server Name Indicationund Use Centralized Certificate Storeund klicken Sie auf OK.

  3. Wechseln Sie zurück zur Eingabeaufforderung mit erhöhten Rechten und führen Sie es netsh http show sslcertnoch einmal aus. Wenn die Götter Ihnen wohlgesonnen sind, sollte die Bindung des zentralisierten Zertifikatspeichers entstanden sein und die aktuelle Bindung ersetzen:

      SSL Certificate bindings:
  -------------------------

  Central Certificate Store    : 443
  Certificate Hash             : (null)
  Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
  Certificate Store Name       : (null)
  Verify Client Certificate Revocation : Enabled
  Verify Revocation Using Cached Client Certificate Only : Disabled
  Usage Check                  : Enabled
  Revocation Freshness Time    : 0
  URL Retrieval Timeout        : 0
 Ctl Identifier               : (null)
 Ctl Store Name               : (null)
 DS Mapper Usage              : Disabled
 Negotiate Client Certificate : Disabled

Wenn Sie die obige Zertifikatsbindung mit dem (null)Wert sehen Certificate Hash, hat sie funktioniert und die CSS-Weiterleitung sollte jetzt aktiviert sein.

  1. Starten Sie einen Browser und versuchen Sie, über den sicheren Socket (HTTPS) eine Verbindung zu den Domänen auf dem Server herzustellen. Dann sollte alles funktionieren.

Wichtige Notizen

  • Sie müssen diesen Vorgang auf jedem Webserver in Ihrer Webfarm wiederholen. Der Vorgang sollte über PowerShell automatisiert und überprüft werden können.

  • Sobald die Passthrough-Bindung erstellt wurde, bleibt sie auf unbestimmte Zeit erhalten (es sei denn, Sie deaktivieren die Unterstützung für zentralisierte Zertifikate auf dem Knoten).

Dieser Link enthält nebenbei Informationen zur technischen Funktionsweise des CCS und ist lesenswert:https://blogs.msdn.microsoft.com/kaushal/2012/10/11/central-certificate-store-ccs-with-iis-8-windows-server-2012/

Ich hoffe das hilft.

verwandte Informationen