Les erreurs SSL sont signalées après la mise à niveau vers TLS 1.2
Cet article fournit des informations sur les erreurs SSL (Secure Sockets Layer) que vous pouvez rencontrer après la mise à niveau vers TLS 1.2 dans SQL Server. Il répertorie également les méthodes par lesquelles vous pouvez récupérer les données manuellement. Vous pouvez également exécuter l’outil SQLCHECK et passer en revue les informations contenues dans le fichier journal SQLCHECK .
Symptômes
Considérez le scénario suivant dans lequel vous pouvez rencontrer les problèmes suivants après la mise à niveau du protocole TLS vers TLS 1.2.
Microsoft SQL Server utilise un certificat signé par un algorithme de hachage faible. Ces certificats incluent MD5, SHA224 et SHA512.
Les mises à niveau TLS 1.2 ont été appliquées uniquement au client ou au serveur, mais pas aux deux.
TLS 1.0 est désactivé.
Il n’existe aucun algorithme de chiffrement correspondant entre le client et le serveur.
Dans ce scénario, vous rencontrez les problèmes suivants une fois la mise à niveau terminée :
Les problèmes qui affectent le certificat de serveur affectent également les connexions locales et les connexions à partir d’ordinateurs clients. Pour plus d’informations, consultez Chiffrement des connexions à SQL Server.
L’application peut générer l’un des messages d’erreur suivants :
Canaux nommés
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 - Aucun processus à l’autre extrémité du canal) Microsoft SQL Server, Erreur : 233.
TCP
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 - La connexion a été fermée de force par l’hôte distant 10054) Microsoft SQL Server, Erreur : 233.
Si vous disposez d’une capture réseau, il peut ressembler à la capture d’écran suivante qui montre que le serveur répond au Client Hello
paquet en fermant la connexion.
Résolution
Pour résoudre ces erreurs, suivez ces étapes :
Ouvrez Gestionnaire de configuration SQL Server, cliquez avec le bouton droit sur Protocoles pour <InstanceName>, puis sélectionnez Propriétés.
Sélectionnez l’onglet Certificat et vérifiez quel certificat est utilisé.
Si un certificat existe, sélectionnez Afficher pour l’examiner, puis sélectionnez Effacer. Ensuite, passez à l’étape 4.
Si aucun certificat n’existe, examinez le fichier journal des erreurs SQL Server pour obtenir le code de hachage. Vous pouvez voir l’une des entrées suivantes :
2023-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption.
ou2023-05-19 04:58:56.42 spid11s A self-generated certificate was successfully loaded for encryption.
Si le certificat est généré automatiquement, passez à l’étape 2.
Ouvrez le magasin de certificats d’ordinateur dans la console MMC (Microsoft Management Console).
Accédez à Certificats personnels.
Développez la colonne Objectifs prévus et double-cliquez sur des certificats activés pour l’authentification du serveur.
Vérifiez si l’empreinte numérique correspond à l’empreinte numérique dans le fichier journal des erreurs. Si ce n’est pas le cas, essayez un autre certificat.
Vérifiez l’algorithme de hachage signature. S’il s’agit de MD5, SHA224 ou SHA512, il ne prend pas en charge TLS 1.2. S’il s’agit de l’un des algorithmes faibles, désactivez l’authentification du serveur afin que SQL Server ne puisse pas l’utiliser.
Si le certificat est explicitement spécifié dans Gestionnaire de configuration SQL Server, sélectionnez Effacer pour le supprimer.
Recherchez le certificat dans MMC.
Dans MMC, cliquez avec le bouton droit sur le certificat, puis sélectionnez Propriétés.
Sous l’onglet Général , désactivez complètement ou désactive sélectivement l’authentification du serveur.
Enregistrez les modifications.
Redémarrez SQL Server.
Le journal des erreurs doit maintenant indiquer qu’un certificat auto-généré est utilisé. Si le problème est résolu, SQL Server peut s’exécuter correctement à l’aide du certificat auto-signé. Si vous souhaitez un verisign ou un autre certificat, vous devez demander au fournisseur de certificats de s’assurer qu’un hachage fort est utilisé pour TLS 1.2. Si le problème n’est pas résolu, revenez à l’étape 2.
Vérifier les protocoles TLS activés et désactivés
Pour vérifier les protocoles TLS activés et désactivés, procédez comme suit :
Vérifiez l’arrière-plan et le flux de travail de mise à niveau de base si vous ne l’avez pas déjà fait.
Le client et le serveur doivent être mis à niveau pour appliquer TLS 1.2. Si nécessaire, vous pouvez mettre à niveau le serveur, mais laisser TLS 1.0 activé afin que les clients non mis à niveau puissent se connecter.
Vérifiez le registre SSL ou TLS à l’aide de REGEDIT.
Vous trouverez les versions SSL ou TLS activées et désactivées sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Il existe des sous-clés client et serveur pour chaque version de SSL ou TLS, et les valeurs Activé et Désactivé sont les suivantes :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
Note
Toute valeur non nulle est traitée comme TRUE. Toutefois, 1 est généralement préféré au lieu de FFFFFFFF (ou -1).
Vérifiez qu’il n’existe aucun paramètre incompatible.
Par exemple, TLS 1.0 est désactivé et TLS 1.2 est activé sur le serveur. Cela est dû au fait que ces paramètres peuvent ne pas correspondre aux paramètres sur le client ou que le pilote client n’est peut-être pas mis à jour.
Vous pouvez tester cette situation en définissant
Enabled=0
TLS 1.2 (et en réactivant TLS 1.0 s’il est désactivé).Redémarrez SQL Server pour vérifier si le problème est lié à TLS 1.2 ou s’il s’agit d’un problème général.
Aucune suite de chiffrement correspondante
Vous pouvez examiner les versions du client et du serveur TLS et les suites de chiffrement dans les paquets et Server Hello
les Client Hello
paquets. Le Client Hello
paquet publie toutes les suites de chiffrement client, et le Server Hello
paquet spécifie une suite de chiffrement. En l’absence de suites correspondantes, le serveur ferme la connexion au lieu de répondre en envoyant le Server Hello
paquet.
Si aucune trace réseau n’est disponible, vous pouvez vérifier la valeur de la fonction sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002
Si vous ne voyez aucun algorithme correspondant, contactez Support Microsoft. Pour aider l’ingénieur du support technique, capturez les traces réseau ou les traces BID, comme spécifié dans Advanced SSL Data Capture.