Schließung einer bestehenden Verbindung wurde vom Remotehost erzwungen

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 Ursachen 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 zwangsweise geschlossen.)

• Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber dann ist beim Handshake vor der Anmeldung ein Fehler aufgetreten. (Anbieter: TCP-Anbieter, Fehler: 0 – Eine vorhandene Verbindung wurde vom Remotehost zwangsweise geschlossen.)

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 bieten. Eine Funktion von Schannel SSP ist die Implementierung verschiedener Versionen des TLS-Protokolls (Transport Layer Security). Dieses Protokoll ist ein Industriestandard, der darauf ausgelegt ist, die Privatsphäre von Informationen zu schützen, die über das Internet kommuniziert werden.

Das TLS-Handshake-Protokoll ist für den Schlüsselaustausch verantwortlich, der zum Einrichten oder Fortsetzen sicherer Sitzungen zwischen zwei Anwendungen erforderlich ist, die über TCP kommunizieren. Während der Voranmeldungsphase des Verbindungsprozesses verwenden SQL Server und Clientanwendungen das TLS-Protokoll, 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: Zwischen dem Client und dem Server sind keine übereinstimmenden TLS-Protokolle vorhanden.

SSL und Versionen von TLS vor TLS 1.2 weisen mehrere bekannte Sicherheitsrisiken auf. Sie werden aufgefordert, 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 herausschieben, um diese unsicheren TLS-Versionen auf verschiedenen Computern in Ihrer Umgebung zu deaktivieren.

Verbindungsfehler 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 übereinstimmendes Protokoll finden können (z. B. TLS 1.0 oder TLS 1.1). Ein übereinstimmendes Protokoll ist erforderlich, um den TLS-Handshake abzuschließen, der erforderlich ist, um mit der Verbindung fortzufahren.

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 auf client- und servercomputern zu aktivieren, indem Sie eine der folgenden Aktionen ausführen:
  • Verwenden Sie das IIS Crypto-Tool (Abschnitt "Ciphers Suites") zum Überprüfen und Ändern der aktuellen TLS-Einstellungen.
  • 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 server für zusätzliche Sicherheit eingeschränkt haben.

Die TLS-Versionen von Clients und Servern, Verschlüsselungssammlungen können in den Client Hello - und Server Hello-Paketen in einer Netzwerkablaufverfolgung problemlos untersucht werden. Das Client Hello-Paket wirbt für alle Clientchiffre-Suites, 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 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 diesen 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 ein Tool wie IIS Crypto (Ciphers Suites Section), um zu überprüfen, ob übereinstimmende Algorithmen vorhanden sind. Wenn keine übereinstimmenden Algorithmen gefunden werden, wenden Sie sich an den Microsoft-Support.

Weitere Informationen finden Sie unter TLS 1.2 Upgrade Workflow and Transport Layer Security (TLS) connections might fail or timeout when connecting or attempting a resumption.

Szenario 3: SQL Server verwendet ein Zertifikat, das von einem Schwachhashalgorithmus signiert wurde, z. B. MD5, SHA224 oder SHA512

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 genannten 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 in SQL Server-Konfigurations-Manager im Konsolenbereich SQL Server Netzwerkkonfiguration.
2. Wählen Sie Protokolle für <instance name>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 wie folgt aussieht, und notieren Sie sich den Hash-/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 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 oder durch Untersuchen des Fingerabdruckwerts verschiedener Zertifikate im Zertifikatspeicher verwendet, und öffnen Sie den Eigenschaftenbereich.
   5. Wählen Sie auf der Registerkarte "Allgemein**" die Option "Nur die folgenden Zwecke aktivieren**" aus, und deaktivieren Sie die Option "Serverauthentifizierung".
5. Starten Sie den SQL Server-Dienst neu.

Szenario 4: Der Client und der Server verwenden TLS_DHE Verschlüsselungssuite für TLS-Handshake, aber eines der Systeme verfügt nicht über führende Nullkorrekturen für die TLS_DHE installiert.

Weitere Informationen zu diesem Szenario finden Sie unter Anwendungserfahrung mit zwangsschließend geschlossenen TLS-Verbindungsfehlern beim Verbinden von SQL-Servern 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 sein können.

Siehe auch

• Behandeln von Konnektivitätsproblemen in SQL Server

• Fehler bei SSIS-Paketen auf SQL-Servern, die für die Verwendung von Verschlüsselung und Netzwerkpaketgröße konfiguriert sind

• Empfohlene Voraussetzungen und Prüfliste für die Problembehandlung bei Konnektivitätsproblemen

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.