Chiffrement et validation de certificat dans Microsoft.Data.SqlClient

Télécharger ADO.NET

Utilisez la sécurité de la couche de transport (TLS) pour chiffrer le trafic entre votre application et SQL Server. Gardez activée la validation des certificats du serveur pour vérifier l’identité du serveur. Le chiffrement sans validation d’identité ne protège pas contre un adversaire au milieu qui se fait passer pour le serveur.

Microsoft. Data.SqlClient est par défaut sur Encrypt=Mandatory et TrustServerCertificate=false. Encrypt=true est un synonyme de Mandatory. Pour une connexion distante, demandez explicitement ces paramètres et fournissez un certificat serveur que le client peut valider :

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Remplacez les espaces réservés et utilisez une méthode d’authentification prise en charge par votre environnement serveur et application. Pour Azure SQL ou la base de données SQL dans Microsoft Fabric, voir authentification Microsoft Entra.

Choisir un mode de chiffrement

Encrypt contrôle si le client nécessite un chiffrement. Un serveur peut également nécessiter un chiffrement. Ce tableau décrit le comportement actuel sans épinglage de certificat :

Réglage du client Configuration requise du serveur Validation de certificat Résultats
Encrypt=Optional ou false Ça ne force pas le chiffrement. Aucun, peu importe .TrustServerCertificate Seuls les paquets de connexion sont chiffrés. Le trafic ultérieur n’est pas chiffré.
Encrypt=Optional;TrustServerCertificate=false Ça force le chiffrement. Chaîne de confiance, validité et nom du serveur. Tout le trafic est chiffré. Les certificats invalides font échouer la connexion.
Encrypt=Optional;TrustServerCertificate=true Ça force le chiffrement. Contourné. Tout le trafic est chiffré, mais l’identité du serveur n’est pas vérifiée.
Encrypt=Mandatory;TrustServerCertificate=false L’un ou l’autre réglage. Chaîne de confiance, validité et nom du serveur. Tout le trafic est chiffré. Les certificats invalides font échouer la connexion.
Encrypt=Mandatory;TrustServerCertificate=true L’un ou l’autre paramètre. Contourné. Tout le trafic est chiffré, mais l’identité du serveur n’est pas vérifiée.
Encrypt=Strict Prend en charge le flux de données tabulaire (TDS) 8.0. Obligatoire. TrustServerCertificate Impossible de l’éviter. TLS commence avant les messages TDS. Un serveur non supporté ou un certificat invalide fait échouer la connexion.

Utilisez Mandatory pour des connexions chiffrées vers des serveurs qui ne supportent pas TDS 8.0. Utilisez Strict lorsque votre terminaison prend en charge TDS 8.0, y compris SQL Server 2022 (16.x) et versions ultérieures. TDS 8.0 prend en charge TLS 1.2 et TLS 1.3 ; il ne nécessite pas TLS 1.3. La version TLS négociée dépend également de la configuration du client, du serveur et du système d’exploitation.

Optional Ce n’est pas un remède aux erreurs de certificat. Il peut laisser les données des applications non chiffrées lorsque le serveur ne nécessite pas de chiffrement.

Configurez un certificat serveur vérifiable

Pour la validation normale des certificats :

  1. Provisionner un certificat qui répond aux exigences du certificat SQL Server.
  2. Incluez le nom utilisé par les clients pour se connecter dans le nom alternatif (SAN) de l’objet du certificat.
  3. Faites en sorte que l’autorité de certification émettrice et tous les certificats intermédiaires requis soient fiables sur chaque hôte client ou conteneur.
  4. Configurez SQL Server pour utiliser le certificat, et conservez TrustServerCertificate=false dans les clients.
  5. Renouvellement du certificat de régime avant l’expiration, y compris tout changement de nom ou d’autorité émettrice.

Un certificat d’une autorité de certification publique ou d’entreprise peut satisfaire à ces exigences. Un certificat d’entreprise n’est pas automatiquement fiable à l’intérieur d’un conteneur Linux ou sur un ordinateur développeur séparé.

Connectez-vous via un alias

Si la connexion utilise un alias du Domain Name System (DNS) qui n’est pas dans le certificat, envisagez d’abord d’émettre un certificat incluant cet alias. Sinon, on peut définir HostNameInCertificate le nom attendu dans le certificat :

Server=tcp:sql-alias.contoso.com,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=sql-server.contoso.com;MultiSubnetFailover=true;

HostNameInCertificate change le nom que SqlClient attend lors de la validation du certificat. Il ne change pas la destination réseau ni ne contourne les vérifications de chaîne de confiance et d’expiration. Laissez-le non configuré lorsque le nom du serveur correspond déjà au certificat.

Épinglez un certificat serveur spécifique

ServerCertificate fournit un fichier de certificat local pour une comparaison exacte avec le certificat du serveur. Les formats pris en charge sont Privacy-Enhanced Mail (PEM) et Distinguished Encoding Rules (DER), y compris .cer les fichiers de certificats. Utilisez-le avec Encrypt=Mandatory ou Encrypt=Strict, et gardez TrustServerCertificate=false.

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=Strict;TrustServerCertificate=false;ServerCertificate=C:\certificates\sql-server.cer;MultiSubnetFailover=true;

Distribuez le certificat attendu via un canal de confiance et protégez le fichier contre tout remplacement. Une correspondance exacte du certificat constitue une alternative à la validation normale de la chaîne et du nom, et non une vérification supplémentaire venant s’y ajouter. Les octets du certificat doivent correspondre ; le même nom du sujet ou la seule clé publique ne suffisent pas. Un fichier PIN manquant, illisible, invalide ou mal correspondant échoue à valider.

Épingler le déploiement client à la rotation des certificats. Mettez à jour le code PIN lorsque le certificat du serveur change, y compris le renouvellement. N’obtenez pas de code PIN en acceptant un certificat non vérifié du réseau.

SqlClient n’expose pas de rappel public pour une validation arbitraire du certificat serveur TLS. AccessTokenCallback contrôle l’acquisition des jetons d’authentification, pas la validation TLS.

Certificats de développement et dépannage

Utilisez un certificat de développement de confiance avec le bon nom de serveur. Si vous utilisez TrustServerCertificate=true temporairement avec Encrypt=true dans un environnement de développement isolé, la connexion est chiffrée mais le client n’authentifie pas le certificat serveur.

Attention

Ne déployez pas TrustServerCertificate=true comme correctif en production pour corriger des erreurs de certificat. Il désactive la validation de l’identité du serveur avec Mandatory et n’a aucun effet avec Strict.

Failure Vérifier
La chaîne de certificats n’est pas digne de confiance. Installez le certificat racine de confiance et les certificats intermédiaires appropriés sur le client. Vérifiez le certificat que SQL Server présente réellement.
Le nom du certificat ne correspond pas. Comparez Server avec le certificat SAN. Corrigez le nom, le certificat ou la dérogation HostNameInCertificate intentionnelle.
Le certificat est expiré. Renouvelez le certificat serveur et vérifiez l’horloge du client.
Le certificat épinglé ne correspond pas ou ne peut pas être chargé. Vérifiez le chemin du fichier, les permissions, le format et le certificat déployé. Mettez à jour le code PIN via votre processus de distribution de confiance.
Le chiffrement strict ne peut pas se connecter. Confirmez que le point de terminaison supporte TDS 8.0 et que sa configuration TLS est compatible avec le client.

Pour la configuration côté serveur, voir Aperçu des certificats.

Changement de comportement du chiffrement et de la validation de certificat

Ces notes de compatibilité expliquent les changements de comportement lors de la mise à jour d’applications plus anciennes. Les nouvelles applications doivent utiliser les paramètres actuels décrits dans cet article.

Sortie du pilote Activer
1.0 Encrypt=false est la valeur par défaut. Lorsque le client ne demande pas de chiffrement, le chiffrement forcé par le serveur ne déclenche pas la validation du certificat.
2.0 Le chiffrement imposé par le serveur respecte TrustServerCertificate même lorsque Encrypt=false.
4,0 Le chiffrement devient activé par défaut. Les mises à jour peuvent révéler des erreurs de configuration de certificats auparavant inconnues.
5.0 Ajoute Optional, Mandatory, Strict, et HostNameInCertificate.
5,1 Ajoute ServerCertificate pour l’épinglage de certificats.
7.0.3 Corrige la validation du pinning de certificat du réseau administré afin qu’elle échoue en mode fermé lorsque des fichiers sont manquants, non valides ou non concordants, même lorsque la validation normale de la plateforme réussit.

Contenu connexe

  • Dernière mise à jour :