SSL-Fehler werden nach dem Upgrade auf TLS 1.2 gemeldet.

Dieser Artikel enthält Informationen zu den SSL-Fehlern (Secure Sockets Layer), die nach dem Upgrade auf TLS 1.2 in SQL Server auftreten können. Außerdem werden die Methoden aufgelistet, nach denen Sie die Daten manuell abrufen können. Sie können auch das SQLCHECK-Tool ausführen und die Informationen in der SQLCHECK-Protokolldatei überprüfen.

Symptome

Berücksichtigen Sie das folgende Szenario, in dem nach dem Upgrade des TLS-Protokolls auf TLS 1.2 möglicherweise die folgenden Probleme auftreten.

• Microsoft SQL Server verwendet ein Zertifikat, das von einem schwachen Hashalgorithmus signiert ist. Zu diesen Zertifikaten gehören MD5, SHA224 und SHA512.

• TLS 1.2-Upgrades wurden nur auf den Client oder den Server angewendet, aber nicht beide.

• TLS 1.0 ist deaktiviert.

• Es gibt keine übereinstimmenden kryptografischen Algorithmen zwischen dem Client und dem Server.

In diesem Szenario treten nach Abschluss des Upgrades die folgenden Probleme auf:

• Probleme, die sich auf das Serverzertifikat auswirken, wirken sich auch auf lokale Verbindungen und Verbindungen von Clientcomputern aus. Weitere Informationen finden Sie unter Verschlüsseln von Verbindungen zu SQL Server.

• Die Anwendung generiert möglicherweise eine der folgenden Fehlermeldungen:

  Named Pipes

  Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber dann trat während des Anmeldevorgangs ein Fehler auf. (Anbieter: SSL-Anbieter, Fehler: 0 - Kein Prozess am anderen Ende der Pipe) Microsoft SQL Server, Fehler: 233.

  TCP

  Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber dann trat während des Anmeldevorgangs ein Fehler auf. (Anbieter: SSL-Anbieter, Fehler: 0 – Die Verbindung wurde durch Remotehost 10054 forcibly geschlossen) Microsoft SQL Server, Fehler: 233.

Wenn Sie über eine Netzwerkaufnahme verfügen, ähnelt es möglicherweise dem folgenden Screenshot, der zeigt, dass der Server auf das Client Hello Paket reagiert, indem die Verbindung geschlossen wird.

Lösung

Führen Sie die folgenden Schritte aus, um diese Fehler zu beheben:

1. Öffnen Sie SQL Server-Konfigurations-Manager, klicken Sie mit der rechten Maustaste auf "Protokolle für <InstanceName>", und wählen Sie dann "Eigenschaften" aus.

2. Wählen Sie die Registerkarte "Zertifikat " aus, und überprüfen Sie, welches Zertifikat verwendet wird.

   

   • Wenn ein Zertifikat vorhanden ist, wählen Sie "Anzeigen" aus, um es zu untersuchen, und wählen Sie dann "Löschen" aus. Wechseln Sie dann zu Schritt 4.

   • Wenn kein Zertifikat vorhanden ist, überprüfen Sie die SQL Server-Fehlerprotokolldatei, um den Hashcode abzurufen. Möglicherweise wird einer der folgenden Einträge angezeigt:

     2023-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption. oder 2023-05-19 04:58:56.42 spid11s A self-generated certificate was successfully loaded for encryption. Wenn das Zertifikat selbst generiert wird, fahren Sie mit Schritt 2 fort.

3. Öffnen Sie den Computerzertifikatspeicher in der Microsoft Management Console (MMC).

   1. Navigieren Sie zu persönlichen Zertifikaten.

   2. Erweitern Sie die Spalte "Beabsichtigte Zwecke ", und doppelklicken Sie auf Zertifikate, die für die Serverauthentifizierung aktiviert sind.

   3. Überprüfen Sie, ob der Fingerabdruck mit dem Fingerabdruck in der Fehlerprotokolldatei übereinstimmt. Falls nicht, versuchen Sie es mit einem anderen Zertifikat.

   4. Überprüfen Sie den Signaturhashalgorithmus. Wenn es SICH um MD5, SHA224 oder SHA512 handelt, wird TLS 1.2 nicht unterstützt. Wenn es sich um eine der schwachen Algorithmen handelt, deaktivieren Sie die Serverauthentifizierung , damit SQL Server sie nicht verwenden kann.

   5. Wenn das Zertifikat in SQL Server-Konfigurations-Manager explizit angegeben ist, wählen Sie "Löschen" aus, um es zu entfernen.

   6. Suchen Sie das Zertifikat in MMC.

   7. Klicken Sie in MMC mit der rechten Maustaste auf das Zertifikat, und wählen Sie dann "Eigenschaften" aus.

   8. Deaktivieren Sie auf der Registerkarte "Allgemein " entweder das Zertifikat vollständig oder selektiv die Serverauthentifizierung.

      

4. Speichern Sie die Änderungen.

5. Starten Sie SQL Server neu.

   Das Fehlerprotokoll sollte nun angeben, dass ein selbst generiertes Zertifikat verwendet wird. Wenn das Problem behoben ist, kann SQL Server mithilfe des selbstsignierten Zertifikats erfolgreich ausgeführt werden. Wenn Sie ein Verisign oder ein anderes Zertifikat benötigen, müssen Sie den Zertifikatanbieter bitten, sicherzustellen, dass ein starker Hash verwendet wird, der für TLS 1.2 geeignet ist. Wenn das Problem nicht behoben ist, kehren Sie zu Schritt 2 zurück.

Überprüfen aktivierter und deaktivierter TLS-Protokolle

Führen Sie die folgenden Schritte aus, um die aktivierten und deaktivierten TLS-Protokolle zu überprüfen:

1. Überprüfen Sie den Hintergrund- und den Standardupgradeworkflow, wenn Sie dies noch nicht getan haben.

   Sowohl der Client als auch der Server müssen aktualisiert werden, um TLS 1.2 zu erzwingen. Wenn dies erforderlich ist, können Sie den Server aktualisieren, tls 1.0 jedoch aktiviert lassen, damit nicht aktualisierte Clients eine Verbindung herstellen können.

2. Überprüfen Sie die SSL- oder TLS-Registrierung mithilfe von REGEDIT.

   Sie finden die aktivierten und deaktivierten SSL- oder TLS-Versionen unter dem folgenden Registrierungsunterschlüssel:

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

   Es gibt Client- und Serverunterschlüssel für jede Version von SSL oder TLS, und beide verfügen über "Enabled " und "Disabled ":

   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

   Notiz

   Jeder Wert ungleich Null wird als WAHR behandelt. 1 wird jedoch im Allgemeinen anstelle von FFFFFFFF (oder -1) bevorzugt.

3. Stellen Sie sicher, dass keine inkompatiblen Einstellungen vorhanden sind.

   Tls 1.0 ist beispielsweise deaktiviert und TLS 1.2 ist auf dem Server aktiviert. Dies liegt daran, dass diese Einstellungen möglicherweise nicht mit den Einstellungen auf dem Client übereinstimmen, oder der Clienttreiber wird möglicherweise nicht aktualisiert.

   Sie können diese Situation testen, indem Sie für TLS 1.2 festlegen Enabled=0 (und auch TLS 1.0 erneut aktivieren, wenn sie deaktiviert ist).

4. Starten Sie SQL Server neu, um zu überprüfen, ob das Problem mit TLS 1.2 verknüpft ist oder ob es sich um ein allgemeines Problem handelt.

Keine übereinstimmenden Verschlüsselungssammlungen

Sie können die Client- und Server-TLS-Versionen und Verschlüsselungssammlungen in den Client Hello Paketen Server Hello und Paketen untersuchen. Das Client Hello Paket kündigt alle Clientchiffresammlungen an, und das Server Hello Paket gibt eine Verschlüsselungssuite an. Wenn keine übereinstimmenden Suites vorhanden sind, schließt der Server die Verbindung, anstatt zu reagieren, indem das Server Hello Paket gesendet wird.

Wenn keine Netzwerkablaufverfolgung verfügbar ist, können Sie den Funktionswert unter dem folgenden Registrierungsunterschlüssel überprüfen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

Wenn keine übereinstimmenden Algorithmen angezeigt werden, wenden Sie sich an Microsoft-Support. Um den Supporttechniker zu unterstützen, erfassen Sie Netzwerkablaufverfolgungen oder BID-Ablaufverfolgungen, wie bei advanced SSL Data Capture angegeben.