Corriger l'erreur de cryptage SQL Server - Solution en un clic

Lisez l'erreur : il s'agit d'un problème de confiance, pas d'un problème de réseau.

Votre réseau fonctionne bien et le serveur fonctionne. La connexion a atteint SQL Server, le serveur a proposé un canal crypté pour la connexion et votre PC l'a refusé car le certificat prouvant l'identité du serveur n'est signé par personne de confiance en votre PC. L'erreur complète affichée par SSMS est :

Par défaut, SQL Server protège la connexion avec un certificat auto-signé qu'il crée lui-même. Un certificat auto-signé crypte le trafic, mais il ne peut pas prouver que le serveur est réellement votre serveur, donc les clients qui exigent un cryptage vérifié le rejettent. Chaque correctif honnête est l'une des deux choses suivantes : faire en sorte que le client accepte ce serveur particulier en connaissance de cause (étapes 2 et 3) ou donner au serveur un certificat auquel les clients font confiance (étape 4).

Le correctif client rapide dans SSMS - Certificat de serveur de confiance

C'est l'itinéraire rapide montré dans la vidéo. Cela ne change rien sur le serveur ; il indique à cette connexion d'accepter le certificat du serveur sans vérifier qui l'a signé. Dans la fenêtre SSMS Se connecter au serveur, cliquez sur Options pour ouvrir les onglets supplémentaires, accédez à l'onglet Propriétés de connexion, définissez le chiffrement sur Obligatoire (ou laissez-le tel qu'il est proposé), cochez Certificat de serveur de confiance et cliquez sur Connecter. La connexion s'effectue immédiatement.

Le même correctif dans une chaîne de connexion d'application

Si une application échoue au lieu de SSMS, le même commutateur réside dans sa chaîne de connexion. Ajoutez explicitement les deux paramètres : Encrypt=True active le canal protégé et TrustServerCertificate=True est l'orthographe de la chaîne de connexion de la case à cocher SSMS :

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Utilisez votre propre nom de serveur, base de données et connexion à la place des exemples de valeurs. Le compromis est exactement le même que celui de la case à cocher de l'étape 2, avec un danger supplémentaire : intégré à la configuration d'une application livrée, la vérification ignorée s'applique à chaque utilisateur, de manière invisible et permanente. Conservez-le dans les configurations de développement et de préparation, et en production, traitez-le comme du temps emprunté jusqu'à ce que le certificat de serveur de l'étape 4 soit en place.

La bonne solution : donnez au serveur un vrai certificat

La réparation permanente s'effectue une seule fois, sur le serveur, puis chaque client se connecte strictement sans case à cocher ni avertissement. Obtenez d'abord un certificat pour le nom DNS complet du serveur (par exemple sql01.company.local) auprès de votre autorité de certification interne ou d'une autorité de certification publique, avec utilisation de l'authentification du serveur. Importez-le, avec sa clé privée, dans le magasin de certificats Ordinateur local sur la machine SQL Server. Cliquez ensuite avec le bouton droit sur le certificat, choisissez Toutes les tâches → Gérer les clés privées et accordez au compte de service SQL Server l'autorisation Lecture sur la clé privée. Ouvrez le Gestionnaire de configuration SQL Server, développez Configuration réseau SQL Server, cliquez avec le bouton droit sur Protocoles pour MSSQLSERVER, choisissez Propriétés et sélectionnez le certificat dans l'onglet Certificat. Dans l'onglet Drapeaux, vous pouvez également définir ForceEncryption sur Oui afin que chaque client doive chiffrer. Redémarrez le service SQL Server : la modification n'a aucun effet jusqu'à ce que vous le fassiez.

Vérifiez le correctif de manière stricte

Une connexion qui réussit discrètement s’avère moins qu’on ne le pense, car certaines combinaisons de paramètres se connectent sans réelle protection. Prouvez les deux moitiés. Tout d'abord, reconnectez-vous à partir d'un client de la manière stricte : connectez-vous en utilisant le nom DNS du serveur - le nom contenu dans le certificat - définissez le cryptage sur Obligatoire et laissez Certificat de serveur de confiance décoché. La connexion devrait réussir sans avertissement. Ensuite, dans cette même session, demandez au serveur si la connexion est réellement chiffrée en exécutant cette requête dans SSMS :

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option affichant TRUE est la note de passage. FALSE avec une connexion fonctionnelle signifie que la connexion a réussi en abandonnant la protection et que le travail n'est pas terminé. Ce test de réussite est la véritable ligne d'arrivée : tout client correctement configuré, y compris les futures versions de SSMS, se connecte désormais avec une validation complète et sans paramètres spéciaux.