Partager via

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

  • Article

S'applique à : SQL Server

Note

Avant de commencer à résoudre un problème, nous vous recommandons de consulter les prérequis et de parcourir la liste de vérification.

Cet article détaille différents scénarios et fournit des résolutions pour les erreurs suivantes :

  • 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 le serveur, mais une erreur s'est ensuite produite pendant la 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.

Quand l’erreur s’affiche-t-elle ?

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). Ce protocole 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 afin d’établir un canal sécurisé pour la transmission des informations d’identification.

Les scénarios suivants détaillent les erreurs qui se produisent lorsque la négociation ne peut pas être terminée :

Scénario 1 : Aucun protocole TLS correspondant n’existe entre le client et le serveur

Ssl (Secure Socket Layer) et les versions de TLS antérieures à TLS 1.2 présentent plusieurs vulnérabilités connues. Vous êtes encouragé à effectuer une mise à niveau vers TLS 1.2 et à désactiver les versions antérieures dans la mesure du possible. En conséquence, les administrateurs système peuvent envoyer des mises à jour via une stratégie de groupe ou d’autres mécanismes pour désactiver ces versions TLS non sécurisées sur différents ordinateurs au sein de votre environnement.

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

Résolution

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

  • Mettez à niveau votre serveur SQL Server ou vos fournisseurs clients vers une version prenant en charge TLS 1.2. Pour plus d’informations, consultez Prise en charge de TLS 1.2 pour Microsoft SQL Server.
  • Demandez à vos administrateurs système d’activer temporairement TLS 1.0 ou TLS 1.1 sur le client et les ordinateurs serveur en effectuant l’une des actions suivantes :

Scénario 2 : Correspondance des protocoles TLS sur le client et le serveur, mais pas de suites de chiffrement TLS correspondantes

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

Les versions du client et du serveur TLS, les suites de chiffrement peuvent être facilement examinées dans les paquets Client Hello et Server Hello dans une trace réseau. Le paquet Client Hello publie toutes les suites de chiffrement client, tandis que le paquet Server Hello spécifie l’un d’entre eux. S’il n’existe aucune suite correspondante, le serveur ferme la connexion au lieu de répondre au paquet Server Hello .

Résolution

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

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

    Utilisez la commande PowerShell suivante pour rechercher les fonctions TLS.

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

  2. Utilisez l’onglet Suites de chiffrements 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 Les connexions TLS 1.2 Upgrade Workflow and Transport Layer Security (TLS) peuvent échouer ou expiration lors de la connexion ou de la tentative de reprise.

Scénario 3 : Les chiffrements TLS_DHE peuvent être activés

Ce problème se produit lorsque le client ou le serveur est hébergé sur Windows 2012, 2016 et versions ultérieures. Malgré les deux versions du système d’exploitation possédant le même chiffrement (TLS_DHE*), Windows 2012 et 2016+ gèrent les clés de chiffrement au sein du protocole TLS différemment. Cela peut entraîner des erreurs de communication.

Résolution

Pour résoudre ce problème, supprimez tous les chiffrements commençant par « TLS_DHE* » de la stratégie locale. Pour plus d’informations sur les erreurs qui se produisent lorsque les applications tentent de se connecter à SQL Server dans Windows, consultez Applications qui rencontrent des erreurs de connexion TLS fermées de force lors de la connexion de SQL Server dans Windows.

Scénario 4 : SQL Server utilise un certificat signé par un algorithme de hachage faible, tel que MD5, SHA224 ou SHA512

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 le certificat. SQL Server utilise ce certificat même s’il n’a pas été provisionné manuellement. Si ces certificats utilisent un algorithme de hachage faible (algorithme d’empreinte numérique) tel que MD5, SHA224 ou SHA512, ils ne fonctionnent pas avec TLS 1.2 et provoquent l’erreur mentionnée précédemment.

Note

Les certificats auto-signés ne sont pas affectés par ce problème.

Résolution

Pour résoudre ce 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 <le nom> de l’instance.
  3. Sélectionnez l’onglet Certificat et suivez l’étape appropriée :
    • Si un certificat s’affiche, sélectionnez Affichage pour examiner l’algorithme d’empreinte numérique pour vérifier s’il utilise un algorithme de hachage faible. Ensuite, sélectionnez Effacer et passez à l’étape 4.
    • Si un certificat n’est pas affiché, passez en revue le journal des erreurs SQL Server pour une entrée semblable à ce qui 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) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Procédez comme suit pour supprimer l’authentification du serveur :
    1. Sélectionnez Démarrer>Exécuter, puis tapez MMC. (MMC également appelé Microsoft Management Console.)
    2. Dans MMC, ouvrez les certificats et sélectionnez Compte d’ordinateur dans l’écran du composant logiciel enfichable Certificats .
    3. Développez Personnel>Certificats.
    4. Recherchez le certificat que SQL Server utilise par son nom ou en examinant la valeur de l’empreinte numérique de différents certificats dans le magasin de certificats et ouvrez son volet Propriétés .
    5. Dans l’onglet Général, sélectionnez N’activer que les rôles suivants et désélectionnez Authentification du serveur.
  5. Redémarrez le service SQL Server.

Scénario 5 : Le client et le serveur utilisent TLS_DHE suite de chiffrement pour l’établissement d’une liaison TLS, mais l’un des systèmes n’a pas de correctifs non significatifs pour le TLS_DHE installé

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.

Note

Si cet article n’a pas résolu votre problème, vous pouvez vérifier si les articles sur les problèmes de connectivité courants peuvent vous aider.

Scénario 6 : Délai d’expiration de l’établissement d’une liaison tcp tridirectionnel (ÉCHEC SYN, Rejet TCP) en raison d’une pénurie de travailleurs DU CIOP

Dans les systèmes avec des charges de travail élevées sur SQL Server 2017 et versions antérieures, vous pouvez observer une erreur intermittente 10054 provoquée par des échecs d’établissement d’une liaison TCP tridirectionnel, ce qui entraîne des rejets TCP. La cause racine de ce problème peut être dans le délai de traitement des TCPAcceptEx demandes. Ce délai peut être dû à une pénurie d’écouteurs IOCP (port d’entrée/sortie) chargés de gérer l’acceptation des connexions entrantes. Le nombre insuffisant de travailleurs du CIOP et la maintenance d’autres demandes entraînent un traitement différé des demandes de connexion, ce qui entraîne finalement des échecs de négociation et des rejets TCP. Vous pouvez également observer les délais d’expiration de connexion pendant la négociation SSL de démarrage (le cas échéant) ou le traitement des demandes de connexion, qui impliquent des vérifications d’authentification.

Résolution

Une pénurie de travailleurs IOCP et de ressources de travail SOS allouées à la gestion des opérations d’authentification et de chiffrement est la principale cause des délais d’attente de négociation TCP tridirectionnel et des délais d’expiration de connexion supplémentaires. SQL Server 2019 inclut plusieurs améliorations des performances dans ce domaine. Une amélioration notable est l’implémentation d’un pool de répartiteur de connexion dédié. Cela optimise l’allocation de ressources pour les tâches liées à la connexion, ce qui réduit l’occurrence de délais d’attente et améliore les performances globales du système.

Autres scénarios où les connexions TLS échouent

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 :

Voir aussi

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.