Freigeben über

Behandeln von PROBLEMEN im Zusammenhang mit SSL (Serverzertifikat)

  • Artikel

Gilt für: Internetinformationsdienste 6.0, Internetinformationsdienste 7.0 und höhere Versionen

Übersicht

In diesem Artikel erfahren Sie, wie Sie SSL-Probleme (Secure Sockets Layer) nur im Zusammenhang mit Internetinformationsdienste (IIS) beheben. Sie deckt Serverzertifikate ab, die für die Serverauthentifizierung bestimmt sind, und nicht Clientzertifikate.

Wenn der Abschnitt Clientzertifikate auf "Erforderlich" festgelegt ist und Dann Probleme auftreten, ist dieser Artikel nicht der Artikel, auf den Sie sich beziehen sollten. Dieser Artikel dient nur zur Behandlung des Problems mit SSL-Serverzertifikaten.

Es ist wichtig zu wissen, dass jedes Zertifikat einen öffentlichen Schlüssel (für die Verschlüsselung verwendet) und einen privaten Schlüssel (für die Entschlüsselung verwendet) umfasst. Der private Schlüssel ist nur dem Server bekannt.

Der Standardport für HTTPS ist 443. Es wird davon ausgegangen, dass Sie mit SSL-Handshake und dem Serverauthentifizierungsprozess während des SSL-Handshakes vertraut sind.

In dieser Problembehandlung verwendete Tools

Folgende Tools werden für die Problembehandlung in den verschiedenen Szenarien verwendet:

  • SSLDiag
  • Netzwerkmonitor 3.4 oder Wireshark

Szenarien

Beim Durchsuchen einer Website über HTTPS wird die folgende Fehlermeldung angezeigt:

Screenshot einer Browserseite mit der Meldung Internet Explorer kann die Webseite nicht anzeigen.

Die erste Voraussetzung, die überprüft werden muss, ist, ob die Website über HTTP zugänglich ist. Wenn dies nicht der Fall ist, liegt wahrscheinlich ein separates Problem vor, das in diesem Artikel nicht behandelt wird. Bevor Sie diese Problembehandlung verwenden können, muss die Website über HTTP betriebsbereit sein.

Angenommen, die Website ist über HTTP zugänglich, und die vorherige Fehlermeldung wird angezeigt, wenn Sie versuchen, über HTTPS zu navigieren. Die Fehlermeldung wird angezeigt, weil der SSL-Handshake fehlgeschlagen ist. Es kann viele Gründe geben, die in den nächsten Szenarien ausführlich erläutert werden.

Szenario 1

Überprüfen Sie, ob das Serverzertifikat über den entsprechenden privaten Schlüssel verfügt. Sehen Sie sich den folgenden Screenshot des Dialogfelds Zertifikat an:

Zwei Screenshots des Dialogfelds

Lösung

Wenn der private Schlüssel fehlt, müssen Sie ein Zertifikat abrufen, das den privaten Schlüssel enthält, bei dem es sich im Wesentlichen um einen handelt. PFX-Datei. Hier sehen Sie einen Befehl, den Sie ausführen können, um den privaten Schlüssel dem Zertifikat zuzuordnen:

C:\>certutil - repairstore my "[U+200E] 1a 1f 94 8b 21 a2 99 36 77 a8 8e b2 3f 42 8c 7e 47 e3 d1 33"

Screenshot der Befehlskonsole mit der certutil-Syntax.

Wenn die Zuordnung erfolgreich ist, wird das folgende Fenster angezeigt:

Screenshot der Befehlskonsole mit einer Meldung, dass der Befehl erfolgreich abgeschlossen wurde.

In diesem Beispiel 1a 1f 94 8b 21 a2 99 36 77 a8 8e b2 3f 42 8c 7e 47 e3 d1 33 ist der Fingerabdruck des Zertifikats. So rufen Sie den Fingerabdruck ab:

  1. Öffnen Sie das Zertifikat.
  2. Wählen Sie die Registerkarte Details aus.
  3. Scrollen Sie nach unten, um den Abschnitt fingerabdruck zu finden.
  4. Wählen Sie den Abschnitt fingerabdruck aus, und klicken Sie auf den text unten.
  5. Drücken Sie STRG+A und dann STRG+C , um es auszuwählen und zu kopieren.

Screenshot des Dialogfelds

Hinweis

Der certutil Befehl ist möglicherweise nicht immer erfolgreich. Wenn dies fehlschlägt, müssen Sie ein Zertifikat mit dem privaten Schlüssel von der Zertifizierungsstelle (CA) abrufen.

Szenario 2

Berücksichtigen Sie in diesem Szenario, dass Sie über ein Serverzertifikat verfügen, das den privaten Schlüssel auf der Website enthält. Der in Szenario 1 angezeigte Fehler wird jedoch weiterhin angezeigt. Sie können immer noch nicht über HTTPS auf die Website zugreifen.

Lösung

  1. Laden Sie das SSL-Diagnosetool herunter, und installieren Sie es auf dem Server.

  2. Wenn Sie über ein Zertifikat verfügen, das den privaten Schlüssel enthält und Sie immer noch nicht auf die Website zugreifen können, führen Sie dieses Tool aus, oder überprüfen Sie die Systemereignisprotokolle auf Warnungen oder Fehler im Zusammenhang mit SChannel.

    Beim Ausführen des SSLDiag-Tools wird möglicherweise die folgende Fehlermeldung angezeigt:

    Sie verfügen über einen privaten Schlüssel, der diesem Zertifikat entspricht, aber CryptAcquireCertificatePrivateKey ist fehlgeschlagen.

    Screenshot des Fensters

    Darüber hinaus wird die folgende SChannel-Warnung in den Systemereignisprotokollen angezeigt:

    Event Type: Error 
Event Source: Schannel 
Event Category: None 
Event ID: 36870 
Date: 2/11/2012 
Time: 12:44:55 AM 
User: N/A 
Computer: 
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090016.

    Dieses Ereignis oder dieser Fehler gibt an, dass beim Abrufen des privaten Schlüssels des Zertifikats ein Problem aufgetreten ist. Führen Sie daher die folgenden Schritte aus, um die Warnung zu beheben:

  3. Überprüfen Sie zunächst die Berechtigungen für den Ordner MachineKeys . Alle privaten Schlüssel werden im Ordner MachineKeys gespeichert. Stellen Sie daher sicher, dass Sie über die erforderlichen Berechtigungen verfügen.

  4. Wenn die Berechtigungen vorhanden sind und das Problem immer noch nicht behoben ist, liegt möglicherweise ein Problem mit dem Zertifikat vor. Möglicherweise war es beschädigt. Im folgenden SChannel-Ereignisprotokoll wird möglicherweise der Fehlercode 0x8009001a angezeigt:

    Event Type: Error 
Event Source: Schannel 
Event Category: None 
Event ID: 36870 
Date: 2/11/2012 
Time: 12:44:55 AM 
User: N/A 
Computer: 
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009001a.

  5. Überprüfen Sie, ob die Website mit einem Testzertifikat funktioniert.

  6. Erstellen Sie eine Sicherung des vorhandenen Zertifikats, und ersetzen Sie es dann durch ein selbstsigniertes Zertifikat.

  7. Versuchen Sie, über HTTPS auf die Website zuzugreifen. Wenn dies funktioniert, wurde das zuvor verwendete Zertifikat beschädigt, und es muss durch ein neues Arbeitszertifikat ersetzt werden. Manchmal kann das Problem nicht beim Zertifikat, sondern beim Aussteller auftreten. Möglicherweise wird in SSLDiag der folgende Fehler angezeigt:

    Screenshot des Fensters

    CertVerifyCertificateChainPolicy schlägt mit CERT_E_UNTRUSTEDROOT (0x800b0109)fehl, wenn das Zertifikat der Stammzertifizierungsstelle nicht als vertrauenswürdig eingestuft wird.

  8. Um diesen Fehler zu beheben, fügen Sie das Zertifikat der Zertifizierungsstelle dem Speicher "Vertrauenswürdige Stammzertifizierungsstelle" unter Mein Computerkonto auf dem Server hinzu. Möglicherweise erhalten Sie auch den folgenden Fehler:

    CertVerifyCertificateChainPolicy hat den Fehler -2146762480(0x800b0110) zurückgegeben.

  9. Um den Fehler zu beheben, überprüfen Sie den Verwendungstyp des Zertifikats, indem Sie die folgenden Schritte ausführen:

    1. Öffnen Sie das Zertifikat.
    2. Wählen Sie die Registerkarte Details aus.
    3. Wählen Sie Eigenschaften bearbeiten... aus.
    4. Stellen Sie sicher, dass auf der Registerkarte Allgemein die Option Alle Zwecke für dieses Zertifikat aktivieren ausgewählt ist und vor allem die Serverauthentifizierung in der Liste enthalten sein sollte.

    Screenshot: Teil des Dialogfelds

Szenario 3

Die ersten beiden Szenarien helfen, die Integrität des Zertifikats zu überprüfen. Nachdem Sie bestätigt haben, dass keine Probleme mit dem Zertifikat vorliegen, wird ein großes Problem behoben. Was aber, wenn die Website immer noch nicht über HTTPS zugänglich ist? Überprüfen Sie die HTTPS-Bindungen der Website, und ermitteln Sie, an welchem Port und welcher IP-Adresse sie lauscht.

Lösung

  1. Führen Sie den folgenden Befehl aus, um sicherzustellen, dass kein anderer Prozess am ssl-Port lauscht, der von der Website verwendet wird.

    netstat -ano" or "netstat -anob

  2. Wenn ein anderer Prozess an diesem Port lauscht, überprüfen Sie, warum dieser Prozess diesen Port verwendet.

  3. Versuchen Sie, die IP-Port Kombination zu ändern, um zu überprüfen, ob die Website zugänglich ist.

Szenario 4

Bis jetzt können Sie sicher sein, dass Sie ein ordnungsgemäßes funktionierendes Zertifikat auf der Website installiert haben und es keinen anderen Prozess gibt, der den SSL-Port für diese Website verwendet. Beim Zugriff auf die Website über HTTPS wird jedoch möglicherweise weiterhin der Fehler "Seite kann nicht angezeigt werden" angezeigt. Wenn ein Client eine Verbindung herstellt und eine SSL-Aushandlung initiiert, durchsucht HTTP.sys seine SSL-Konfiguration nach dem "IP:Port"-Paar, mit dem der Client verbunden ist. Die HTTP.sys SSL-Konfiguration muss einen Zertifikathash und den Namen des Zertifikatspeichers enthalten, bevor die SSL-Aushandlung erfolgreich ist. Das Problem kann mit dem auftreten HTTP.SYS SSL Listener.

Der bei HTTP.sys registrierte Zertifikathash kann NULL sein oder eine ungültige GUID enthalten.

Lösung

  1. Führen Sie den folgenden Befehl aus:

    IIS 6: "httpcfg.exe query ssl"
IIS 7/7.5: "netsh http show ssl"

    Hinweis

    HttpCfg ist Teil der Windows-Supporttools und auf dem Installationsdatenträger vorhanden.

    Es folgt ein Beispiel für ein funktionierendes und nicht funktionierendes Szenario:

    Arbeitsszenario

    Konfiguration Einstellung
    IP 0.0.0.0:443
    Hash
    GUID {00000000-0000-0000-0000-000000000000}
    CertStoreName MEINE
    CertCheckMode 0
    RevocationFreshnessTime 0
    UrlRetrievalTimeout 0
    SslCtlIdentifier 0
    SslCtlStoreName 0
    Flags 0

    Nicht funktionierendes Szenario

    Konfiguration Einstellung
    IP 0.0.0.0:443
    Hash c09b416d6b 8d615db22 64079d15638e96823d
    GUID {4dc3e181-e14b-4a21-b022-59fc669b0914}
    CertStoreName MEINE
    CertCheckMode 0
    RevocationFreshnessTime 0
    UrlRetrievalTimeout 0
    SslCtlIdentifier 0
    SslCtlStoreName 0
    Flags 0

    Der Hashwert im Arbeitsszenario ist der Fingerabdruck Ihres SSL-Zertifikats. Beachten Sie, dass die GUID in einem nicht funktionierenden Szenario 0 (null) ist. Möglicherweise wird für den Hash ein Wert oder ein Leerzeichen angezeigt. Auch wenn Sie das Zertifikat von der Website entfernen und dann ausführen httpcfg query ssl, listet die Website die GUID weiterhin als alle 0s auf. Wenn die GUID als "{0000...............000}" angezeigt wird, liegt ein Problem vor.

  2. Entfernen Sie diesen Eintrag, indem Sie den folgenden Befehl ausführen:

    httpcfg delete ssl -i "IP:Port Number"

    Zum Beispiel:

    httpcfg delete ssl -i 0.0.0.0:443

  3. Um zu ermitteln, ob IP-Adressen aufgelistet sind, öffnen Sie eine Eingabeaufforderung, und führen Sie dann die folgenden Befehle aus:

    IIS 6: httpcfg query iplisten

    IIS 7/7.5: netsh http show iplisten

    Wenn die Liste IP-Lausch leer ist, gibt der Befehl die folgende Zeichenfolge zurück:

    HttpQueryServiceConfiguration completed with 1168.

    Wenn der Befehl eine Liste von IP-Adressen zurückgibt, entfernen Sie jede IP-Adresse in der Liste mit dem folgenden Befehl:

    httpcfg delete iplisten -i x.x.x.x

    Hinweis

    Starten Sie IIS anschließend mit dem net stop http /y Befehl neu.

Szenario 5

Wenn Sie trotzdem nicht über HTTPS auf der Website surfen können, erfassen Sie eine Netzwerkablaufverfolgung entweder vom Client oder Server. Filtern Sie die Ablaufverfolgung nach "SSL oder TLS", um den SSL-Datenverkehr anzuzeigen.

Es folgt eine Netzwerkablaufverfolgung Momentaufnahme eines nicht funktionierenden Szenarios:

Screenshot des Fensters

Es folgt eine Netzwerkablaufverfolgung Momentaufnahme eines Arbeitsszenarios:

Screenshot des Fensters

Dies ist die Methode, wie Sie eine Netzwerkablaufverfolgung betrachten. Sie müssen die Framedetails erweitern und sehen, welches Protokoll und welche Verschlüsselung vom Server ausgewählt wurde. Wählen Sie in der Beschreibung "Server Hello" aus, um diese Details anzuzeigen.

In diesem Szenario wurde der Client nur für die Verwendung von TLS 1.1 und TLS 1.2 konfiguriert. Der Webserver war jedoch IIS 6, das bis TLS 1.0 unterstützen kann und daher der Handshake fehlgeschlagen ist.

Überprüfen Sie die Registrierungsschlüssel, um zu ermitteln, welche Protokolle aktiviert oder deaktiviert sind. Hier ist der Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Das DWORD "Aktiviert" sollte auf "1" festgelegt werden. Wenn es auf 0 festgelegt ist, ist das Protokoll deaktiviert.

Ssl 2.0 ist beispielsweise standardmäßig deaktiviert.

Szenario 6

Wenn alles überprüft wurde und weiterhin Probleme beim Zugriff auf die Website über HTTPS auftreten, ist es höchstwahrscheinlich ein Update, das dazu führt, dass der SSL-Handshake fehlschlägt.

Microsoft hat ein Update für die Implementierung von SSL in Windows veröffentlicht:

MS12-006: Vulnerability in SSL/TLS could allow information disclosure: January 10, 2012

Dieses Update kann sich auf Kunden auswirken, die Internet-Explorer oder eine Anwendung verwenden, die internet Explorer zum Ausführen von HTTPS-Anforderungen verwendet.

Es wurden tatsächlich zwei Änderungen an der Sicherheitslücke zur Offenlegung von Informationen in SSL 3.0/TLS 1.0 vorgenommen. Das MS12-006-Update implementiert ein neues Verhalten in schannel.dll, das einen zusätzlichen Datensatz sendet, während eine gemeinsame SSL-Verkettungsblockchiffre verwendet wird, wenn Clients dieses Verhalten anfordern. Die andere Änderung erfolgte in Wininet.dll, Teil des kumulativen Updates für Internet Explorer vom Dezember (MS11-099), sodass internet Explorer das neue Verhalten anfordern.

Wenn ein Problem vorliegt, kann es zu einem Fehler beim Herstellen einer Verbindung mit einem Server oder zu einer unvollständigen Anforderung führen. Internet Explorer 9 und höher kann den Fehler "Internet Explorer kann die Webseite nicht anzeigen" anzeigen. In früheren Versionen von Internet Explorer wird möglicherweise eine leere Seite angezeigt.

Fiddler verwendet den zusätzlichen Datensatz nicht, wenn https-Anforderungen erfasst und an den Server weitergeleitet werden. Wenn fiddler zum Erfassen von HTTPS-Datenverkehr verwendet wird, werden die Anforderungen daher erfolgreich ausgeführt.

Registrierungsschlüssel

Wie in MS12-006 dokumentiert: Sicherheitsanfälligkeit in SSL/TLS kann Offenlegung von Informationen ermöglichen: 10. Januar 2012, es gibt einen SendExtraRecord-Registrierungswert, der folgendes kann:

  • Globales Deaktivieren des neuen SSL-Verhaltens,
  • Global aktivieren oder
  • (Standardmäßig) aktivieren Sie sie für SChannel-Clients, die das neue Verhalten auswählen.

Für Internet Explorer und für Clients, die Internet Explorer-Komponenten nutzen, gibt es einen Registrierungsschlüssel im Abschnitt FeatureControl FEATURE_SCH_SEND_AUX_RECORD_KB_2618444, der bestimmt, ob iexplore.exe oder eine andere benannte Anwendung das neue Verhalten auswäht. Standardmäßig ist dies für internet-Explorer aktiviert und für andere Anwendungen deaktiviert.

Weitere Informationen