Une connexion existante a été fermée de force par l’hôte distant (erreur de système d’exploitation 10054)

S'applique à : SQL Server

Résumé

Cet article décrit les scénarios dans lesquels l’erreur de connectivité SQL Server « Une connexion existante a été fermée de force par l’hôte distant » et fournit des résolutions. L'erreur est liée à une négociation TLS ayant échoué entre le client et SQL Server, souvent parce que le client et le serveur ne peuvent pas accepter une version du protocole TLS (par exemple, TLS 1.2 ou TLS 1.3) ou une suite de chiffrement.

L’article décrit les messages d’erreur suivants :

Une connexion a été établie avec le serveur, mais une erreur s’est ensuite produite pendant le processus de connexion. (fournisseur : Fournisseur SSL, erreur : 0 - Une connexion existante a été fermée de force par l’hôte distant.)

Une connexion a été établie avec succès au serveur, mais une erreur s'est ensuite produite pendant la phase de négociation préalable à l'ouverture de session. (fournisseur : Fournisseur TCP, erreur : 0 - Une connexion existante a été fermée de force par l’hôte distant.)

L’erreur du système d’exploitation 10054 est générée dans la couche sockets Windows. Pour plus d’informations, consultez Codes d’erreur Windows Sockets : WSAECONNRESET 10054.

Avant de commencer la résolution des problèmes, vérifiez les prérequis et passez par la liste de contrôle.

Lorsque cette erreur se produit

Secure Channel, également appelé Schannel, est un fournisseur de support de sécurité (SSP). Il contient un ensemble de protocoles de sécurité qui fournissent une authentification d’identité et une communication privée sécurisée par le biais du chiffrement. L’une des fonctions du SSP Schannel consiste à implémenter différentes versions du protocole TLS (Transport Layer Security). TLS est une norme du secteur conçue pour protéger la confidentialité des informations communiquées sur Internet.

Le protocole de négociation TLS est responsable de l’échange de clés nécessaire pour établir ou reprendre des sessions sécurisées entre deux applications communiquant via TCP. Pendant la phase de pré-connexion du processus de connexion, SQL Server et les applications clientes utilisent le protocole TLS pour configurer un canal sécurisé pour transmettre les informations d’identification.

Versions TLS en un clin d’œil

Le tableau suivant compare les versions TLS que vous pouvez rencontrer lors de la résolution de cette erreur :

Pour connaître l’état actuel de prise en charge des protocoles TLS sur Windows, consultez Protocoles dans TLS/SSL (SSP Schannel).

Identifier le scénario qui s’applique dans votre environnement

Les sections suivantes décrivent différents scénarios pouvant faire échouer la poignée de main. Si vous ne savez pas qui correspond à votre environnement, utilisez ces points de départ pour le limiter :

• Capturez une trace réseau sur le client et le serveur lors d’une connexion défaillante. Ensuite, inspectez les paquets Client Hello et Server Hello pour confirmer la version et la suite de chiffrement TLS négociées.
• Vérifiez le journal des erreurs de SQL Server pour l’entrée successfully loaded for encryption afin de confirmer quel certificat est utilisé. Vérifiez son algorithme d’empreinte numérique.
• Comparez les versions TLS et les suites de chiffrement activées sur le client et le serveur à l’aide de Get-TlsCipherSuite et des clés du Registre sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
• Vérifiez que le pilote client prend en charge TLS 1.2 ou version ultérieure. Les pilotes plus anciens, comme SQL Server Native Client, sont déconseillés et ne sont pas recommandés.

Aucun protocole TLS correspondant entre le client et le serveur

Ssl (Secure Sockets Layer) et les versions de TLS antérieures à TLS 1.2 présentent plusieurs vulnérabilités connues. Dans les versions modernes de Windows (Windows 11, Windows Server 2022 et versions ultérieures), TLS 1.0 et TLS 1.1 sont désactivés par défaut. Les administrateurs déploient souvent aussi des paramètres de Stratégie de groupe ou du Registre pour désactiver ces anciens protocoles dans des environnements plus anciens.

Des erreurs de connectivité se produisent lorsque votre application utilise un pilote ODBC (Open Database Connectivity), un fournisseur OLE DB, un composant .NET Framework ou une version SQL Server qui ne prend pas en charge TLS 1.2 ou version ultérieure. Le problème se produit parce que le serveur et le client ne peuvent pas trouver de protocole correspondant. Un protocole correspondant est nécessaire pour terminer l’établissement d’une liaison TLS.

Corriger l’incompatibilité de protocole entre le client et le serveur

Pour résoudre ce problème, utilisez l’une des méthodes suivantes :

• Mettez à niveau SQL Server ou vos fournisseurs clients vers une version prenant en charge TLS 1.2 (et, le cas échéant, TLS 1.3). Pour plus d’informations, consultez Prise en charge de TLS 1.2 pour Microsoft SQL Server.
• En guise de solution de contournement à court terme, demandez à vos administrateurs système d’activer temporairement TLS 1.0 ou TLS 1.1 sur le client et le serveur. Effectuez cette opération uniquement jusqu’à ce que les composants puissent être mis à niveau. Utilisez l’une des actions suivantes :
  • Utilisez l’onglet Suites de chiffrement dans l’outil Iis Crypto pour vérifier et modifier les paramètres TLS actuels.
  • Démarrez l’Éditeur du Registre, puis accédez aux clés de Registre spécifiques à Schannel sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Pour plus d’informations, consultez les erreurs TLS 1.2 Upgrade Workflow et SSL après la mise à niveau vers TLS 1.2.

Exemple : versions minimales du pilote client pour TLS 1.2

Utilisez des composants clients qui prennent en charge TLS 1.2 ou version ultérieure en mode natif. Les composants suivants sont des bases de référence sécurisées courantes :

• Microsoft ODBC Driver 17 ou 18 pour SQL Server.
• Microsoft OLE DB Driver 18 ou 19 pour SQL Server.
• .NET Framework 4.6.2 ou version ultérieure, ou toute version prise en charge de .NET (.NET 6 et versions ultérieures).
• Microsoft JDBC Driver 9.4 ou version ultérieure.

L’ancien SQL Server Native Client (SNAC) et le fournisseur SQL Server OLE DB livré avec Windows (SQLOLEDB) sont dépréciés. Remplacez-les par les composants de la liste précédente.

Protocoles TLS correspondants, mais pas de suites de chiffrement correspondantes

Ce scénario se produit lorsque vous ou un administrateur limite certains algorithmes sur le client ou le serveur pour une sécurité supplémentaire.

Vous pouvez examiner les versions du client et du serveur TLS et les suites de chiffrement dans les paquets Client Hello et Server Hello dans une trace réseau. Le paquet Client Hello publie toutes les suites de chiffrement client, et le paquet Server Hello retourne celui choisi par le serveur. S’il n’existe aucune suite correspondante, le serveur ferme la connexion au lieu d’envoyer un paquet Server Hello .

Corriger l’incompatibilité de suite de chiffrement

Pour vérifier le problème, suivez ces étapes :

1. Si aucune trace réseau n’est disponible, vérifiez la Functions valeur sous cette clé de Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002.

   Utilisez la commande PowerShell suivante pour répertorier les suites de chiffrement TLS configurées :

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

   Sur Windows 10, Windows 11, Windows Server 2016 et versions ultérieures, vous pouvez également exécuter pour répertorier Get-TlsCipherSuite les suites activées dans un formulaire plus lisible.

2. Utilisez l’onglet Suites de chiffrement dans l’outil De chiffrement IIS pour vérifier s’il existe des algorithmes correspondants. Si aucun algorithme correspondant n’est trouvé, contactez Support Microsoft.

Pour plus d’informations, consultez Flux de travail de mise à niveau vers TLS 1.2 et Les connexions Transport Layer Security (TLS) peuvent échouer ou expirer lors de la connexion ou d’une tentative de reprise.

TLS_DHE suites de chiffrement activées sur différentes versions de Windows

Ce problème peut se produire lorsque le client et le serveur s’exécutent sur différentes versions Windows (par exemple, Windows Server 2012 et Windows Server 2016 ou version ultérieure) et publient TLS_DHE_* des suites de chiffrement. Ces versions de Windows gèrent l’échange de clés Diffie-Hellman dans TLS différemment, ce qui peut entraîner l’échec de la négociation.

Supprimer TLS_DHE suites de chiffrement

Pour résoudre ce problème, supprimez toutes les suites de chiffrement qui commencent par TLS_DHE_ de la stratégie locale. Pour plus d’informations sur les erreurs qui se produisent lorsque des applications tentent de se connecter à SQL Server sous Windows, consultez Les applications rencontrent des erreurs indiquant que la connexion TLS a été fermée de force lors de la connexion à SQL Server sous Windows.

SQL Server certificat utilise un algorithme de hachage faible

SQL Server chiffre toujours les paquets réseau liés à la connexion. À cet effet, il utilise un certificat provisionné manuellement ou un certificat auto-signé. Si SQL Server trouve un certificat qui prend en charge la fonction d'authentification du serveur dans le magasin de certificats, il utilise ce certificat même s'il n'a pas été provisionné manuellement. Si le certificat utilise un algorithme de hachage faible (empreinte numérique) tel que MD5, SHA224 ou SHA512, il ne fonctionne pas avec TLS 1.2 et provoque l’erreur.

Remplacer ou reconfigurer des certificats par des algorithmes de hachage faibles

Pour résoudre le problème, procédez comme suit :

1. Dans Gestionnaire de configuration SQL Server, développez la configuration réseau SQL Server dans le volet Console.

2. Sélectionnez Protocoles pour <nom d’instance>.

3. Sélectionnez l’onglet Certificat , puis effectuez l’une des actions suivantes :

   • Si un certificat apparaît, sélectionnez Afficher pour vérifier l’algorithme d’empreinte numérique et vérifier s’il utilise un algorithme de hachage faible. Ensuite, sélectionnez Effacer et passez à l’étape 4.

   • Si aucun certificat n’apparaît, passez en revue le journal des erreurs SQL Server pour obtenir une entrée comme suit et notez la valeur de hachage ou d’empreinte numérique :

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

4. Supprimez l’authentification du serveur du certificat :

   1. Sélectionnez Démarrer>l’exécution, puis entrez MMC (Microsoft Management Console).
   2. Dans MMC, ajoutez le composant logiciel enfichable Certificats et sélectionnez Compte d’ordinateur.
   3. Développez Personnel>Certificats.
   4. Recherchez le certificat que SQL Server utilise par nom ou par empreinte numérique, puis ouvrez son volet Propriétés.
   5. Sous l’onglet Général , sélectionnez Activer uniquement les objectifs suivants et désactivez l’authentification du serveur.

5. Redémarrez le service SQL Server.

Correctif du zéro initial TLS_DHE non installé

Ce scénario se produit lorsque le client et le serveur négocient une TLS_DHE_* suite de chiffrement pour le protocole de négociation TLS, mais qu’une des deux parties ne dispose pas de la mise à jour Windows qui ajoute le correctif des zéros initiaux pour l’échange de clés Diffie-Hellman. Pour plus d’informations sur ce scénario, consultez Les applications rencontrent des erreurs de fermeture forcée de connexion TLS lors de la connexion de serveurs SQL dans Windows.

Expiration du délai du handshake TCP en trois étapes due à un manque de threads de travail IOCP

Sur les systèmes soumis à des charges de travail élevées exécutant SQL Server 2017 ou une version antérieure, vous pouvez voir des erreurs 10054 intermittentes dues à des échecs de la négociation TCP en trois temps, lesquels entraînent des rejets TCP. La cause racine est souvent un retard dans le traitement des TCPAcceptEx demandes. Le délai peut être dû à une pénurie d’écouteurs d’entrée/sortie (IOCP), qui gèrent l’acceptation des connexions entrantes. Lorsque les workers IOCP sont en nombre insuffisant ou occupés à traiter d’autres demandes, les demandes de connexion sont traitées tardivement, ce qui entraîne des échecs lors de l’établissement de la connexion et des rejets TCP. Vous pouvez également voir les délais d’expiration de connexion pendant l’établissement d’une liaison SSL ou pendant le traitement des demandes de connexion, ce qui implique des vérifications d’authentification.

Atténuer les pénuries de travailleurs du CIOP et les délais d’attente de négociation

Une pénurie de travailleurs IOCP et de ressources de travail SOS allouées aux opérations d’authentification et de chiffrement est la principale cause de ces délais d’attente de négociation tcp tridirectionnel et des délais d’expiration de connexion. SQL Server 2019 et versions ultérieures incluent plusieurs améliorations de performances dans ce domaine. Une amélioration notable est un pool de répartiteurs de connexion dédié, qui optimise l’allocation de ressources pour les tâches de connexion. Cette modification réduit les délais d’expiration et améliore les performances globales du système. Si vous êtes concerné par ce problème, planifiez une mise à niveau vers une version actuellement prise en charge SQL Server.

Autres scénarios d’échec de connexion TLS

Si le message d’erreur que vous rencontrez ne correspond à aucun des scénarios précédents, reportez-vous aux scénarios supplémentaires suivants :

• Sql Server local ne peut pas se connecter à un serveur lié lorsque le chiffrement RSA est utilisé
• Une erreur de connexion 10054 peut se produire après la mise à niveau de SQL Server
• Des erreurs de connexion intermittentes se produisent lors de l’ajout d’un nœud à l’environnement Always On dans SQL Server
• Des erreurs de connexion intermittentes se produisent lors de l’utilisation de l’utilitaire SQLCMD
• L’erreur SSL_PE_NO_CIPHER se produit sur le point de terminaison 5022 dans SQL Server
• L’erreur de connectivité 0x80004005 se produit lors d’échecs SSIS de l’Agent SQL Server
• Erreur « Impossible d’établir la connexion » après l’implémentation des stratégies de suite de chiffrement sur une machine SQL Server
• Erreur « Échec de la connexion au serveur lié » après la mise à jour de Windows Server
• SQL Server Agent ne parvient pas à démarrer lors de la connexion à SQL Server
• Erreur lors de la connexion d’une version supérieure de SQL Server à une version inférieure à l’aide de la fonctionnalité de serveur lié de SQL Server

Contenu connexe

• Résoudre les problèmes de connectivité dans SQL Server
• Erreur pour les packages SSIS sur les serveurs SQL configurés pour utiliser le chiffrement et la taille des paquets réseau
• Prérequis et liste de contrôle recommandés pour résoudre les problèmes de connectivité
• Protocoles dans TLS/SSL (SSP Schannel)

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.