Freigeben über

Eine vorhandene Verbindung wurde vom Remotehost forcibly geschlossen (Betriebssystemfehler 10054)

  • Artikel

Gilt für: SQL Server

Notiz

Bevor Sie mit der Problembehandlung beginnen, sollten Sie die Voraussetzungen überprüfen und die Checkliste durchgehen.

In diesem Artikel werden verschiedene Szenarien beschrieben und Lösungen für die folgenden Fehler bereitgestellt:

  • Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber dann trat während des Anmeldevorgangs ein Fehler auf. (Anbieter: SSL-Anbieter, Fehler: 0 – Eine vorhandene Verbindung wurde vom Remotehost forcibly geschlossen.)

  • Es konnte eine Verbindung mit dem Server hergestellt werden, doch während des Handshakes vor der Anmeldung trat ein Fehler auf. (Anbieter: TCP-Anbieter, Fehler: 0 – Eine vorhandene Verbindung wurde vom Remotehost forcibly geschlossen.)

Der Betriebssystemfehler 10054 wird in der Windows-Sockets-Ebene ausgelöst. Weitere Informationen finden Sie unter Windows Sockets Error Codes: WSAECONNRESET 10054.

Wann wird der Fehler angezeigt?

Secure Channel, auch bekannt als Schannel, ist ein Security Support Provider (SSP). Sie enthält eine Reihe von Sicherheitsprotokollen, die die Identitätsauthentifizierung und sichere private Kommunikation über Verschlüsselung bereitstellen. Eine Funktion von Schannel SSP ist die Implementierung verschiedener Versionen des TLS-Protokolls (Transport Layer Security). Dieses Protokoll ist ein Industriestandard, der zum Schutz der Privatsphäre der über das Internet kommunizierten Informationen entwickelt wurde.

Das TLS Handshake-Protokoll ist für den Schlüsselaustausch verantwortlich, der erforderlich ist, um sichere Sitzungen zwischen zwei Anwendungen herzustellen oder fortzusetzen, die über TCP kommunizieren. Während der Verbindungsprozessphase vor der Anmeldung wird für SQL Server und Clientanwendungen das TLS-Protokoll verwendet, um einen sicheren Kanal für die Übertragung von Anmeldeinformationen einzurichten.

In den folgenden Szenarien werden Fehler beschrieben, die auftreten, wenn der Handshake nicht abgeschlossen werden kann:

Szenario 1: Es sind keine übereinstimmenden TLS-Protokolle zwischen dem Client und dem Server vorhanden.

Secure Socket Layer (SSL) und Versionen von TLS vor TLS 1.2 weisen mehrere bekannte Sicherheitsrisiken auf. Sie werden empfohlen, ein Upgrade auf TLS 1.2 durchzuführen und frühere Versionen nach Möglichkeit zu deaktivieren. Dementsprechend könnten Systemadministratoren Updates über Gruppenrichtlinien oder andere Mechanismen übertragen, um diese unsicheren TLS-Versionen auf verschiedenen Computern in Ihrer Umgebung zu deaktivieren.

Konnektivitätsfehler treten auf, wenn Ihre Anwendung eine frühere Version des ODBC-Treibers (Open Database Connectivity), OLE DB-Anbieter, .NET Framework-Komponenten oder eine SQL Server-Version verwendet, die TLS 1.2 nicht unterstützt. Das Problem tritt auf, da der Server und der Client kein übereinstimmenes Protokoll (z. B. TLS 1.0 oder TLS 1.1) finden können. Zum Abschließen des TLS-Handshakes, der zum Fortsetzen der Verbindung erforderlich ist, ist ein übereinstimmende Protokoll erforderlich.

Lösung

Sie können dieses Problem mit einer der folgenden Methoden beheben:

  • Aktualisieren Sie Ihren SQL Server oder Ihre Clientanbieter auf eine Version, die TLS 1.2 unterstützt. Weitere Informationen finden Sie unter TLS 1.2-Unterstützung für Microsoft SQL Server.
  • Bitten Sie Ihre Systemadministratoren, TLS 1.0 oder TLS 1.1 vorübergehend sowohl auf dem Client als auch auf den Servercomputern zu aktivieren, indem Sie eine der folgenden Aktionen ausführen:
    • Verwenden Sie die Registerkarte "Ciphers Suites " im IIS-Kryptotool , um die aktuellen TLS-Einstellungen zu überprüfen und vorzunehmen.
    • Starten Sie den Registrierungs-Editor, und suchen Sie die schannel-spezifischen Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Weitere Informationen finden Sie unter TLS 1.2-Upgradeworkflow und SSL-Fehler nach dem Upgrade auf TLS 1.2.

Szenario 2: Abgleichen von TLS-Protokollen auf dem Client und dem Server, aber keine übereinstimmenden TLS-Verschlüsselungssammlungen

Dieses Szenario tritt auf, wenn Sie oder Ihr Administrator bestimmte Algorithmen auf dem Client oder dem Server für zusätzliche Sicherheit eingeschränkt haben.

Die TLS-Versionen von Client und Server können in den Paketen "Client Hello" und "Server Hello" in einer Netzwerkablaufverfolgung problemlos untersucht werden. Das Client Hello-Paket kündigt alle Clientchiffresammlungen an, während das Server Hello-Paket eine davon angibt. Wenn keine übereinstimmenden Suites vorhanden sind, schließt der Server die Verbindung, anstatt auf das Server Hello-Paket zu reagieren.

Lösung

Führen Sie diese Schritte aus, um das Problem zu beheben:

  1. Wenn eine Netzwerkablaufverfolgung nicht verfügbar ist, überprüfen Sie den Funktionswert unter diesem Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    Verwenden Sie den folgenden PowerShell-Befehl, um die TLS-Funktionen zu finden.

    Get-ItemPropertyValue  -Path HKLM:\System\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\ -Name Functions

  2. Verwenden Sie die Registerkarte "Ciphers Suites " im IIS-Kryptotool , um zu überprüfen, ob übereinstimmende Algorithmen vorhanden sind. Wenn keine übereinstimmenden Algorithmen gefunden werden, wenden Sie sich an Microsoft-Support.

Weitere Informationen finden Sie unter TLS 1.2 Upgrade Workflow and Transport Layer Security (TLS)-Verbindungen möglicherweise fehl oder timeout beim Herstellen einer Verbindung oder beim Versuch einer Erneutaufnahme.

Szenario 3: Die TLS_DHE Verschlüsselungen sind möglicherweise aktiviert.

Dieses Problem tritt auf, wenn der Client oder Server unter Windows 2012, 2016 und höheren Versionen gehostet wird. Trotz beider Betriebssystemversionen mit derselben Verschlüsselung (TLS_DHE*), behandeln Windows 2012 und 2016+ Kryptografieschlüssel innerhalb des TLS unterschiedlich. Dies kann zu Kommunikationsfehlern führen.

Lösung

Um dieses Problem zu beheben, entfernen Sie alle Verschlüsselungen, die mit "TLS_DHE*" beginnen, aus der lokalen Richtlinie. Weitere Informationen zu Fehlern, die auftreten, wenn Anwendungen versuchen, eine Verbindung mit SQL Server in Windows herzustellen, finden Sie unter Anwendungserfahrung beim Verbinden von SQL Server in Windows forcibly closed TLS connection errors.

Szenario 4: SQL Server verwendet ein Zertifikat, das von einem schwachen Hashalgorithmus signiert ist, z. B. MD5, SHA224 oder SHA512

SQL Server verschlüsselt immer Netzwerkpakete, die mit der Anmeldung zusammenhängen. Zu diesem Zweck wird ein manuell bereitgestelltes Zertifikat oder ein selbstsigniertes Zertifikat verwendet. Wenn SQL Server ein Zertifikat findet, das die Serverauthentifizierungsfunktion im Zertifikatspeicher unterstützt, wird das Zertifikat verwendet. SQL Server verwendet dieses Zertifikat auch dann, wenn es nicht manuell bereitgestellt wurde. Wenn diese Zertifikate einen Schwachhashalgorithmus (Fingerabdruckalgorithmus) wie MD5, SHA224 oder SHA512 verwenden, funktionieren sie nicht mit TLS 1.2 und verursachen den zuvor erwähnten Fehler.

Notiz

Selbstsignierte Zertifikate sind von diesem Problem nicht betroffen.

Lösung

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

  1. Erweitern Sie in SQL Server-Konfigurations-Manager die SQL Server-Netzwerkkonfiguration im Konsolenbereich.
  2. Wählen Sie Protokolle für <den Namen der Instanz> aus.
  3. Wählen Sie die Registerkarte "Zertifikat " aus, und folgen Sie dem entsprechenden Schritt:
    • Wenn ein Zertifikat angezeigt wird, wählen Sie "Ansicht" aus, um den Fingerabdruckalgorithmus zu überprüfen, um zu überprüfen, ob es einen schwachen Hash-Algorithmus verwendet. Wählen Sie dann "Löschen" aus, und wechseln Sie zu Schritt 4.
    • Wenn kein Zertifikat angezeigt wird, überprüfen Sie das SQL Server-Fehlerprotokoll für einen Eintrag, der den folgenden ähnelt, und notieren Sie sich den Hash- oder Fingerabdruckwert:
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Führen Sie die folgenden Schritte aus, um die Serverauthentifizierung zu entfernen:
    1. Wählen Sie Start>Ausführen aus, und geben Sie MMC ein. (MMC wird auch als Microsoft Management Console bezeichnet.)
    2. Öffnen Sie in MMC die Zertifikate, und wählen Sie "Computerkonto" im Snap-In-Bildschirm "Zertifikate" aus.
    3. Klappen Sie Persönlich>Zertifikate auf.
    4. Suchen Sie das Zertifikat, das SQL Server mit seinem Namen verwendet, oder überprüfen Sie den Fingerabdruckwert verschiedener Zertifikate im Zertifikatspeicher, und öffnen Sie den Eigenschaftenbereich .
    5. Aktivieren Sie auf der Registerkarte Allgemein die Option Nur folgende Zwecke aktivieren, und deaktivieren Sie Serverauthentifizierung.
  5. Starten Sie den SQL Server-Dienst neu.

Szenario 5: Der Client und der Server verwenden TLS_DHE Verschlüsselungssuite für TLS-Handshake, aber eines der Systeme hat keine führenden Fixes für die TLS_DHE installiert.

Weitere Informationen zu diesem Szenario finden Sie unter Für Anwendungen treten bei der Verbindungsherstellung für SQL Server-Instanzen unter Windows Fehler aufgrund des erzwungenen Schließens der TLS-Verbindung auf.

Notiz

Wenn Ihr Problem in diesem Artikel nicht behoben wurde, können Sie überprüfen, ob die allgemeinen Artikel zu Konnektivitätsproblemen hilfreich sind.

Szenario 6: TCP Three-Way Handshake Timeout (SYN Fail, TCP-Ablehnung) aufgrund des Mangels an IOCP-Mitarbeitern

In Systemen mit hohen Workloads in SQL Server 2017 und früheren Versionen können Sie einen zeitweiligen 10054-Fehler beobachten, der durch dreidirektionale TCP-Handshakefehler verursacht wird, was zu TCP-Ablehnungen führt. Die Ursache dieses Problems kann sich in der Verzögerung bei der Verarbeitung TCPAcceptEx von Anforderungen befinden. Diese Verzögerung kann auf einen Mangel an IOCP(Input/Output Completion Port)-Listenermitarbeitern zurückzuführen sein, die für die Verwaltung der Akzeptanz eingehender Verbindungen verantwortlich sind. Die unzureichende Anzahl der IOCP-Mitarbeiter und der gebuchten Wartung anderer Anforderungen führt zu verzögerter Verarbeitung von Verbindungsanforderungen, was letztendlich zu Handshake-Fehlern und TCP-Ablehnungen führt. Sie können auch Anmeldetimeouts während des Start-SSL-Handshake (falls vorhanden) oder die Verarbeitung von Anmeldeanforderungen beobachten, die sich auf Authentifizierungsprüfungen beziehen.

Lösung

Ein Mangel an IOCP-Mitarbeitern und SOS-Workerressourcen, die der Verarbeitung von Authentifizierungs- und Verschlüsselungsvorgängen zugeordnet sind, ist die Hauptursache für die dreiseitigen TCP-Handshake-Timeouts und zusätzliche Anmeldetimeouts. SQL Server 2019 enthält mehrere Leistungsverbesserungen in diesem Bereich. Eine wichtige Verbesserung ist die Implementierung eines dedizierten Login Dispatcher-Pools. Dadurch wird die Zuordnung von Ressourcen für anmeldebezogene Vorgänge optimiert, wodurch das Auftreten von Timeouts reduziert und die Gesamtleistung des Systems verbessert wird.

Andere Szenarien, in denen TLS-Verbindungen fehlschlagen

Wenn die aufgetretene Fehlermeldung keinem der vorherigen Szenarien entspricht, lesen Sie die folgenden zusätzlichen Szenarien:

Siehe auch

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.