Een bestaande verbinding is geforceerd gesloten door de externe host (besturingssysteemfout 10054)

Van toepassing op: SQL Server

Overzicht

In dit artikel worden scenario's beschreven waarin de SQL Server verbindingsfout 'Een bestaande verbinding is geforceerd gesloten door de externe host' optreedt en oplossingen biedt. De fout is gekoppeld aan een mislukte TLS-handshake tussen de client en SQL Server, vaak omdat de client en server niet akkoord kunnen gaan met een TLS-protocolversie (bijvoorbeeld TLS 1.2 of TLS 1.3) of een coderingssuite.

In het artikel worden de volgende foutberichten behandeld:

Er is een verbinding tot stand gebracht met de server, maar er is een fout opgetreden tijdens het aanmeldingsproces. (provider: SSL-provider, fout: 0 - Een bestaande verbinding is geforceerd gesloten door de externe host.)

Er is een verbinding met de server tot stand gebracht, maar vervolgens is er een fout opgetreden tijdens de handshake voorafgaand aan de aanmelding. (provider: TCP-provider, fout: 0 - Een bestaande verbinding is geforceerd gesloten door de externe host.)

De besturingssysteemfout 10054 treedt op in de Windows Sockets-laag. Zie Windows Sockets-foutcodes: WSAECONNRESET 10054 voor meer informatie.

Voordat u begint met het oplossen van problemen, controleert u de vereisten en doorloopt u de controlelijst.

Wanneer deze fout optreedt

Secure Channel, ook wel bekend als Schannel, is een SSP (Security Support Provider ). Het bevat een set beveiligingsprotocollen die identiteitsverificatie bieden en persoonlijke communicatie beveiligen via versleuteling. Een functie van Schannel SSP is het implementeren van verschillende versies van het TLS-protocol (Transport Layer Security). TLS is een industriestandaard die is ontworpen ter bescherming van de privacy van informatie die via internet wordt gecommuniceerd.

Het TLS-handshake-protocol is verantwoordelijk voor de sleuteluitwisseling die nodig is om beveiligde sessies tot stand te brengen of te hervatten tussen twee toepassingen die communiceren via TCP. Tijdens de preaanmeldingsfase van het verbindingsproces gebruiken SQL Server en clienttoepassingen het TLS-protocol om een beveiligd kanaal in te stellen voor het verzenden van referenties.

TLS-versies in één oogopslag

In de volgende tabel worden de TLS-versies vergeleken die kunnen optreden bij het oplossen van deze fout:

Zie Protocollen in TLS/SSL (Schannel SSP) voor de huidige ondersteuningsstatus van TLS-protocollen op Windows.

Bepalen welk scenario van toepassing is in uw omgeving

In de volgende secties worden verschillende scenario's beschreven die ervoor kunnen zorgen dat de handshake mislukt. Als u niet zeker weet welke overeenkomt met uw omgeving, gebruikt u deze uitgangspunten om deze te verfijnen:

• Leg een netwerktracering vast bij de client en de server tijdens een mislukte verbinding. Inspecteer vervolgens de Client Hello - en Server Hello-pakketten om de onderhandelde TLS-versie en coderingssuite te bevestigen.
• Controleer het SQL Server foutenlogboek voor de successfully loaded for encryption vermelding om te bevestigen welk certificaat wordt gebruikt. Controleer het vingerafdruk-algoritme.
• Vergelijk de ingeschakelde TLS-versies en coderingssuites op de client en server met behulp van Get-TlsCipherSuite en de registersleutels onder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
• Controleer of het clientstuurprogramma TLS 1.2 of hoger ondersteunt. Oudere stuurprogramma's, zoals SQL Server Native Client, worden afgeschaft en worden niet aanbevolen.

Geen overeenkomend TLS-protocol tussen client en server

Secure Sockets Layer (SSL) en versies van TLS ouder dan TLS 1.2 hebben verschillende bekende beveiligingsproblemen. In moderne versies van Windows (Windows 11, Windows Server 2022 en hoger) zijn TLS 1.0 en TLS 1.1 standaard uitgeschakeld. Beheerders implementeren vaak ook groepsbeleid of registerinstellingen om deze oudere protocollen in oudere omgevingen uit te schakelen.

Connectiviteitsfouten treden op wanneer uw toepassing gebruikmaakt van een ouder ODBC-stuurprogramma (Open Database Connectivity), OLE DB-provider, .NET Framework-onderdeel of SQL Server versie die TLS 1.2 of hoger niet ondersteunt. Het probleem treedt op omdat de server en de client geen overeenkomend protocol kunnen vinden. Er is een overeenkomend protocol nodig om de TLS-handshake te voltooien.

Los de protocolmismatch tussen client en server op

Gebruik een van de volgende methoden om dit probleem op te lossen:

• Upgrade SQL Server of uw clientproviders naar een versie die TLS 1.2 ondersteunt (en, indien mogelijk, TLS 1.3). Zie TLS 1.2-ondersteuning voor Microsoft SQL Server voor meer informatie.
• Als tijdelijke oplossing voor de korte termijn vraagt u uw systeembeheerders om TLS 1.0 of TLS 1.1 tijdelijk in te schakelen op zowel de client als de server. Doe dit alleen totdat de onderdelen kunnen worden bijgewerkt. Gebruik een van de volgende acties:
  • Gebruik het tabblad Coderingssuites in het hulpprogramma IIS Crypto om de huidige TLS-instellingen te controleren en te wijzigen.
  • Start de Register-editor en ga naar de Schannel-specifieke registersleutels onder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Zie tls 1.2-upgradewerkstroom - en SSL-fouten na een upgrade naar TLS 1.2 voor meer informatie.

Voorbeeld: minimale clientstuurprogrammaversies voor TLS 1.2

Gebruik clientonderdelen die systeemeigen ondersteuning bieden voor TLS 1.2 of hoger. De volgende onderdelen zijn algemene veilige basislijnen:

• Microsoft ODBC-stuurprogramma 17 of 18 voor SQL Server.
• Microsoft OLE DB-stuurprogramma 18 of 19 voor SQL Server.
• .NET Framework 4.6.2 of hoger, of een ondersteunde versie van .NET (.NET 6 en hoger).
• Microsoft JDBC-stuurprogramma 9.4 of hoger.

De verouderde SQL Server Native Client (SNAC) en de SQL Server OLE DB-provider die is geleverd met Windows (SQLOLEDB) worden afgeschaft. Vervang ze door de onderdelen in de vorige lijst.

Overeenkomende TLS-protocollen, maar geen overeenkomende coderingssuites

Dit scenario treedt op wanneer u of een beheerder bepaalde algoritmen op de client of de server beperkt voor extra beveiliging.

U kunt de CLIENT- en server-TLS-versies en coderingssuites in de client Hello - en Server Hello-pakketten in een netwerktrace onderzoeken. Het Client Hello-pakket kondigt alle client-coderingssuites aan en het Server Hello-pakket retourneert het pakket dat de server heeft gekozen. Als er geen overeenkomende suites zijn, sluit de server de verbinding in plaats van een Server Hello-pakket te verzenden.

Los een afwijkende coderingssuite op

Volg deze stappen om het probleem te controleren:

1. Als een netwerktracering niet beschikbaar is, controleert u de Functions waarde onder deze registersleutel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002.

   Gebruik de volgende PowerShell-opdracht om de geconfigureerde TLS-coderingssuites weer te geven:

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

   Op Windows 10, Windows 11, Windows Server 2016 en later kunt u ook Get-TlsCipherSuite uitvoeren om de ingeschakelde suites in een beter leesbare vorm weer te geven.

2. Gebruik het tabblad Coderingssuites in het hulpprogramma IIS Crypto om te controleren of er overeenkomende algoritmen zijn. Als er geen overeenkomende algoritmen worden gevonden, neemt u contact op met Microsoft Ondersteuning.

Zie TLS 1.2-upgradewerkstroom - en Transport Layer Security-verbindingen (TLS) kunnen mislukken of time-outs hebben wanneer u verbinding maakt of een hervatting probeert uit te voeren.

TLS_DHE coderingssuites zijn ingeschakeld voor verschillende Windows versies

Dit probleem kan optreden wanneer de client en server worden uitgevoerd op verschillende Windows versies (bijvoorbeeld Windows Server 2012 en Windows Server 2016 of hoger) en beide coderingssuites adverterenTLS_DHE_*. Deze Windows versies verwerken Diffie-Hellman sleuteluitwisseling in TLS anders, waardoor de handshake mislukt.

TLS_DHE coderingssuites verwijderen

Als u dit probleem wilt oplossen, verwijdert u alle ciphersuites die beginnen met TLS_DHE_ uit het lokale beleid. Zie Toepassingen ondervinden fouten met geforceerd gesloten TLS-verbindingen wanneer ze in Windows verbinding maken met SQL Server voor meer informatie over fouten die optreden wanneer toepassingen verbinding proberen te maken met SQL Server in Windows.

SQL Server certificaat maakt gebruik van een zwak hash-algoritme

SQL Server versleutelt altijd netwerkpakketten die betrekking hebben op aanmelden. Hiervoor wordt een handmatig ingericht certificaat of een zelfondertekend certificaat gebruikt. Als SQL Server een certificaat vindt dat ondersteuning biedt voor de serververificatiefunctie in het certificaatarchief, wordt dat certificaat gebruikt, zelfs als het niet handmatig is ingericht. Als voor het certificaat een zwak hash-algoritme (vingerafdruk) wordt gebruikt, zoals MD5, SHA224 of SHA512, werkt het niet met TLS 1.2 en wordt de fout veroorzaakt.

Certificaten vervangen of opnieuw configureren met zwakke hash-algoritmen

Volg deze stappen om het probleem op te lossen:

1. Vouw in SQL Server Configuration Manager SQL Server-netwerkconfiguratie uit in het deelvenster Console.

2. Selecteer Protocollen voor <instantienaam>.

3. Selecteer het tabblad Certificaat en voer vervolgens een van de volgende acties uit:

   • Als er een certificaat wordt weergegeven, selecteert u Weergeven om het vingerafdrukalgoritmen te controleren en te controleren of er een zwak hash-algoritme wordt gebruikt. Selecteer vervolgens Wissen en ga naar stap 4.

   • Als er geen certificaat wordt weergegeven, controleert u het SQL Server foutenlogboek voor een vermelding zoals hieronder en noteert u de hash- of vingerafdrukwaarde:

     2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"] was successfully loaded for encryption

4. Serververificatie verwijderen uit het certificaat:

   1. Selecteer Start>Uitvoeren, en voer MMC (Microsoft Management Console) in.
   2. Voeg in MMC de invoegtoepassing Certificaten toe en selecteer Computeraccount.
   3. Vouw Personal>Certificates uit.
   4. Zoek het certificaat dat SQL Server gebruikt op naam of vingerafdruk en open het deelvenster Eigenschappen.
   5. Selecteer op het tabblad Algemeenalleen de volgende doeleinden inschakelen en wis serververificatie.

5. Start de SQL Server-service opnieuw.

TLS_DHE-oplossing voor voorloopnul niet geïnstalleerd

Dit scenario treedt op wanneer de client en de server onderhandelen over een TLS_DHE_* coderingssuite voor de TLS-handshake, maar één zijde niet beschikt over de Windows update waarmee de oplossing voor voorloopnul voor de Diffie-Hellman sleuteluitwisseling wordt toegevoegd. Zie Toepassingen ondervinden fouten vanwege een geforceerd gesloten TLS-verbinding bij het verbinding maken met SQL -servers in Windows voor meer informatie over dit scenario.

Time-out van de TCP-drieweghandshake door een tekort aan IOCP-werkthreads

Op systemen met hoge werkbelastingen waarop SQL Server 2017 of eerder wordt uitgevoerd, kunt u mogelijk af en toe 10054-fouten zien die worden veroorzaakt door mislukte TCP-three-way handshakes, die leiden tot TCP-weigeringen. De hoofdoorzaak is vaak een vertraging bij het verwerken van TCPAcceptEx aanvragen. De vertraging kan worden veroorzaakt door een tekort aan IOCP-listeners (Input/Output Completion Port), die de acceptatie van binnenkomende verbindingen beheren. Wanneer IOCP-werknemers te weinig of bezet zijn met het verwerken van andere aanvragen, worden verbindingsaanvragen te laat verwerkt, wat resulteert in handshakefouten en TCP-afwijzingen. Mogelijk ziet u ook time-outs voor aanmelden tijdens de SSL-handshake of tijdens de verwerking van aanmeldingsaanvragen, waarbij verificatiecontroles zijn betrokken.

IoCP-werkroltekorten en time-outs voor handshake beperken

Een tekort aan IOCP-workers en aan SOS Worker-resources die zijn toegewezen aan authenticatie- en versleutelingsbewerkingen, is de belangrijkste oorzaak van deze time-outs bij de TCP-drieweghandshake en bij het aanmelden. SQL Server 2019 en hoger bevatten verschillende prestatieverbeteringen op dit gebied. Een belangrijke verbetering is een toegewezen pool voor aanmeldingsverzenders, waarmee de resourcetoewijzing voor aanmeldingstaken wordt geoptimaliseerd. Deze wijziging vermindert time-outs en verbetert de algehele systeemprestaties. Als u last hebt van dit probleem, plant u een upgrade naar een momenteel ondersteunde SQL Server versie.

Andere scenario's met TLS-verbindingsfouten

Als het foutbericht dat u tegenkomt niet overeenkomt met een van de vorige scenario's, raadpleegt u de volgende aanvullende scenario's:

• Lokale SQL Server kan geen verbinding maken met een gekoppelde server wanneer RSA-versleuteling wordt gebruikt
• Er kan een verbindingsfout 10054 optreden na de SQL Server-upgrade
• Onregelmatige verbindingsfouten treden op bij het toevoegen van een knooppunt aan de AlwaysOn-omgeving in SQL Server
• Onregelmatige verbindingsfouten treden op bij het gebruik van het SQLCMD-hulpprogramma
• De SSL_PE_NO_CIPHER fout treedt op op eindpunt 5022 in SQL Server
• Connectiviteitsfout 0x80004005 optreedt bij SSIS-fouten met SQL-serveragent
• Fout 'Client kan geen verbinding tot stand brengen' na het implementeren van het coderingspakketbeleid op een SQL Server-machine
• Fout 'Verbinding met de gekoppelde server is mislukt' nadat u Windows Server hebt bijgewerkt
• SQL Server Agent kan niet worden gestart tijdens het maken van verbinding met SQL Server
• Fout bij het verbinden met een hogere versie van SQL Server met behulp van de functionaliteit van SQL Server Linked Server

Verwante inhoud

• Verbindingsproblemen in SQL Server oplossen
• Fout voor SSIS-pakketten op SQL-servers die zijn geconfigureerd voor het gebruik van versleuteling en netwerkpakketgrootte
• Aanbevolen vereisten en controlelijst voor het oplossen van verbindingsproblemen
• Protocollen in TLS/SSL (Schannel SSP)

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.