Freigeben über

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

  • Artikel

Gilt für: SQL Server

Hinweis

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 ist während des Anmeldevorgangs ein Fehler aufgetreten. (Anbieter: SSL-Anbieter, Fehler: 0 – Eine vorhandene Verbindung wurde vom Remotehost erzwungen geschlossen.)

  • Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber dann ist während des Handshakes vor der Anmeldung ein Fehler aufgetreten. (Anbieter: TCP-Anbieter, Fehler: 0 – Eine vorhandene Verbindung wurde vom Remotehost erzwungen geschlossen.)

Der Betriebssystemfehler 10054 wird in der Windows-Socketebene 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). Es enthält eine Reihe von Sicherheitsprotokollen, die Identitätsauthentifizierung und sichere private Kommunikation durch Verschlüsselung ermöglichen. Eine Funktion von Schannel SSP besteht darin, verschiedene Versionen des TLS-Protokolls (Transport Layer Security) zu implementieren. Dieses Protokoll ist ein Branchenstandard, der entwickelt wurde, um die Privatsphäre von Informationen zu schützen, die über das Internet übermittelt werden.

Das TLS-Handshakeprotokoll ist für den Schlüsselaustausch verantwortlich, der zum Einrichten oder Fortsetzen sicherer Sitzungen zwischen zwei Anwendungen, die über TCP kommunizieren, erforderlich ist. Während der Phase vor der Anmeldung des Verbindungsprozesses verwenden SQL Server- und Clientanwendungen das TLS-Protokoll, um einen sicheren Kanal für die Übertragung von Anmeldeinformationen einzurichten.

Die folgenden Szenarien beschreiben Fehler, die auftreten, wenn der Handshake nicht abgeschlossen werden kann:

Szenario 1: Zwischen Client und Server sind keine übereinstimmenden TLS-Protokolle vorhanden.

Secure Socket Layer (SSL) und TLS-Versionen vor TLS 1.2 weisen mehrere bekannte Sicherheitsrisiken auf. Es wird empfohlen, ein Upgrade auf TLS 1.2 durchzuführen und frühere Versionen nach Möglichkeit zu deaktivieren. Entsprechend könnten Systemadministratoren Updates über Gruppenrichtlinien oder andere Mechanismen pushen, 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), einen OLE DB-Anbieter, .NET Framework-Komponenten oder eine SQL Server Version verwendet, die TLS 1.2 nicht unterstützt. Das Problem tritt auf, weil der Server und der Client kein übereinstimmende Protokoll (z. B. TLS 1.0 oder TLS 1.1) finden können. Ein entsprechendes Protokoll ist erforderlich, um den TLS-Handshake abzuschließen, der zum Fortsetzen der Verbindung erforderlich ist.

Lösung

Wenden Sie eine der folgenden Methoden an, um dieses Problem zu beheben:

  • Aktualisieren Sie Ihre 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 Verschlüsselungssammlungen im IIS-Kryptografietool , um die aktuellen TLS-Einstellungen zu überprüfen und änderungen daran vorzunehmen.
    • Starten Sie die Registrierungs-Editor, und suchen Sie nach den Schannel-spezifischen Registrierungsschlüsseln: 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: Übereinstimmende TLS-Protokolle 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 server aus Sicherheitsgründen eingeschränkt haben.

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

Lösung

Führen Sie die folgenden Schritte aus, um das Problem zu überprüfen:

  1. Wenn keine Netzwerkablaufverfolgung 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 Verschlüsselungssammlungen im IIS-Kryptografietool , 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-Upgradeworkflow und TLS-Verbindungen (Transport Layer Security) können beim Herstellen einer Verbindung oder beim Versuch einer Wiederaufnahme fehlschlagen oder timeouts auftreten.

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

Dieses Problem tritt auf, wenn der Client oder Server unter Windows 2012, 2016 und höheren Versionen gehostet wird. Obwohl beide Betriebssystemversionen über die gleiche Verschlüsselung (TLS_DHE*) verfügen, 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 Anwendungen treten erzwungene TLS-Verbindungsfehler beim Herstellen einer Verbindung mit SQL Server in Windows auf.

Szenario 4: SQL Server ein Zertifikat verwendet, das von einem Schwachhashalgorithmus wie MD5, SHA224 oder SHA512 signiert ist.

SQL Server verschlüsselt immer Netzwerkpakete, die sich auf die Anmeldung beziehen. 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.

Hinweis

Selbstsignierte Zertifikate sind von diesem Problem nicht betroffen.

Lösung

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

  1. Erweitern Sie SQL Server-Konfigurations-Manager im Bereich KonsoleSQL Server Netzwerkkonfiguration.
  2. Wählen Sie Protokolle für <instance Namen> aus.
  3. Wählen Sie die Registerkarte Zertifikat aus, und führen Sie den entsprechenden Schritt aus:
    • Wenn ein Zertifikat angezeigt wird, wählen Sie Ansicht aus, um den Fingerabdruckalgorithmus zu überprüfen, um zu überprüfen, ob ein Schwachhashalgorithmus verwendet wird. Wählen Sie dann Löschen aus, und fahren Sie mit Schritt 4 fort.
    • Wenn kein Zertifikat angezeigt wird, überprüfen Sie das SQL Server Fehlerprotokoll auf einen Eintrag, der dem 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 Ausführung starten> 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 im Snap-In-Bildschirm Zertifikate die Option Computerkonto aus.
    3. Erweitern Sie Persönliche>Zertifikate.
    4. Suchen Sie das Zertifikat, das SQL Server anhand seines Namens verwendet, oder überprüfen Sie den Fingerabdruckwert verschiedener Zertifikate im Zertifikatspeicher, und öffnen Sie den Bereich Eigenschaften.
    5. Wählen Sie auf der Registerkarte Allgemeindie Option Nur die folgenden Zwecke aktivieren aus, und heben Sie die Option Serverauthentifizierung auf.
  5. Starten Sie den SQL Server-Dienst neu.

Szenario 5: Der Client und der Server verwenden TLS_DHE Verschlüsselungssammlung für DEN TLS-Handshake, aber eines der Systeme verfügt nicht über keine führenden Fixes für die installierten TLS_DHE

Weitere Informationen zu diesem Szenario finden Sie unter Anwendungserfahrung erzwungene TLS-Verbindungsfehler beim Herstellen einer Verbindung mit SQL Server in Windows.

Hinweis

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

Szenario 6: TCP Three-Way Handshake Timeout (SYN-Fehler, TCP-Ablehnung) aufgrund eines Mangels an IOCP-Workern

In Systemen mit hohen Workloads in SQL Server 2017 und früheren Versionen kann es vorkommen, dass ein zeitweiliger 10054-Fehler aufgrund von Tcp-Drei-Wege-Handshakefehlern auftritt, was zu TCP-Ablehnungen führt. Die Grundursache dieses Problems kann in der Verzögerung bei der Verarbeitung TCPAcceptEx von Anforderungen sein. Diese Verzögerung kann auf einen Mangel an IOCP-Listener-Workern (Input/Output Completion Port) zurückzuführen sein, die für die Verwaltung der Akzeptanz eingehender Verbindungen verantwortlich sind. Die unzureichende Anzahl von IOCP-Workern und die ausgelastete Wartung anderer Anforderungen führt zu einer verzögerten Verarbeitung von Verbindungsanforderungen, was letztendlich zu Handshakefehlern und TCP-Ablehnungen führt. Sie können auch Anmeldetimeouts während des START-SSL-Handshakes (falls vorhanden) oder der Verarbeitung von Anmeldeanforderungen beobachten, die mit Authentifizierungsprüfungen verbunden sind.

Lösung

Ein Mangel an IOCP-Workern und SOS-Workerressourcen, die für die Verarbeitung von Authentifizierungs- und Verschlüsselungsvorgängen zugeordnet sind, ist die Standard Ursache für die Drei-Wege-Handshake-Timeouts von TCP und zusätzlichen Anmeldetimeouts. SQL Server 2019 umfasst mehrere Leistungsverbesserungen in diesem Bereich. Eine wichtige Verbesserung ist die Implementierung eines dedizierten Anmeldeverteilerpools. Dadurch wird die Zuordnung von Ressourcen für Anmeldeaufgaben optimiert, wodurch das Auftreten von Timeouts reduziert und die Gesamtleistung des Systems verbessert wird.

Andere Szenarien, in denen TLS-Verbindungen fehlschlagen

Wenn die angezeigte 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.