Partager via

TLS et les certificats numériques

  • Article

Cet article contient des informations détaillées sur le protocole TLS (Transport Layer Security) et les certificats numériques.

TLS (Transport Layer Security)

Les protocoles TLS et SSL se trouvent entre la couche Protocole d’application et la couche TCP/IP, où ils peuvent sécuriser et envoyer des données d’application à la couche de transport. Les protocoles TLS/SSL utilisent des algorithmes d’une suite de chiffrement pour créer des clés et chiffrer des informations. Le client et le serveur négocient la version du protocole et la suite de chiffrement à utiliser pour le chiffrement pendant la phase de connexion initiale (préconnexion) de l’établissement de la connexion. La version de TLS la plus élevée prise en charge est toujours choisie dans la négociation TLS. Pour vérifier les versions des protocoles TLS prises en charge par les différentes versions des systèmes d’exploitation Windows, consultez Protocoles dans TLS/SSL (SSP Schannel). Plusieurs vulnérabilités connues ont été signalées pour SSL et pour les versions antérieures de TLS. Nous vous recommandons d’effectuer une mise à niveau vers TLS 1.2 pour une communication sécurisée.

SQL Server peut utiliser TLS pour chiffrer des données transmises sur un réseau entre une instance de SQL Server et une application cliente. TLS utilise un certificat pour implémenter le chiffrement.

L’activation du chiffrement TLS améliore la sécurité des données transmises sur des réseaux entre des instances de SQL Server et des applications. Cependant, quand tout le trafic entre SQL Server et une application cliente est chiffré en utilisant TLS, le traitement supplémentaire suivant est nécessaire :

  • Un aller-retour réseau supplémentaire est requis au moment de la connexion.
  • Les paquets envoyés de l’application à l’instance de SQL Server doivent être chiffrés par la pile TLS du client et déchiffrés par la pile TLS du serveur.
  • Les paquets envoyés de l’instance SQL Server à l’application doivent être chiffrés par la pile TLS du serveur et déchiffrés par la pile TLS du client.

Important

À compter de SQL Server 2016 (13.x), le protocole SSL (Secure Sockets Layer) n’est plus disponible. Utilisez TLS à la place (TLS 1.2 est recommandé). Pour plus d’informations, consultez KB3135244 - Prise en charge de TLS 1.2 pour Microsoft SQL Server. SQL Server 2022 introduit la prise en charge de TLS 1.3. Pour plus d’informations, consultez Prise en charge de TLS 1.3. S’il n’existe aucun protocole correspondant entre le client et l’ordinateur serveur, vous pouvez recevoir l’erreur décrite dans Une connexion existante a été fermée de force par l’hôte distant.

Vue d’ensemble des certificats numériques

Les certificats numériques sont des fichiers électroniques qui fonctionnent comme un mot de passe en ligne pour vérifier l'identité d'un utilisateur ou d'un ordinateur. Ils sont utilisés pour créer le canal chiffré utilisé pour les communications des clients. Un certificat est une déclaration numérique émise par une autorité de certification qui garantit l’identité du détenteur du certificat et permet aux parties de communiquer de façon sécurisée en utilisant un chiffrement.

Les certificats numériques fournissent les services suivants :

  • Chiffrement : ils aident à protéger les données échangées contre le vol ou la falsification.
  • Authentification : ils vérifient le fait que leurs détenteurs (des personnes, des sites web et même des ressources réseau comme des routeurs) sont réellement qui ou ce qu’ils prétendent être. En règle générale, l’authentification est unidirectionnelle, où la source vérifie l’identité de la cible, mais l’authentification TLS mutuelle est également possible.

Un certificat contient une clé publique et joint cette clé publique à l'identité d'une personne, d'un ordinateur ou d'un service qui détient la clé privée correspondante. Les clés publiques et les clés privées sont utilisées par le client et le serveur pour chiffrer les données avant leur transmission. Pour les utilisateurs, les ordinateurs et les services Windows, la confiance envers l’autorité de certification est établie quand le certificat racine est défini dans le magasin de certificats racines de confiance et que le certificat contient un chemin de certification valide. Un certificat est considéré comme valide s’il n’a pas été révoqué (il ne figure pas dans la liste de révocation des certificats de l’autorité de certification) ou s’il n’a pas expiré.

Les trois principaux types de certificats numériques sont décrits dans le tableau suivant :

Type Description Avantages Inconvénients
Certificat auto-signé Le certificat est signé par l’application qui l’a créé ou il est créé en utilisant New-SelfSignedCertificate. Coût (gratuit) - Le certificat n’est pas approuvé automatiquement par les ordinateurs clients et les appareils mobiles. Le certificat doit être ajouté manuellement au magasin de certificats racines de confiance sur tous les ordinateurs et les appareils clients, mais certains appareils mobiles n’autorisent pas les modifications apportées au magasin de certificats racines de confiance.

- Certains services ne fonctionnent pas avec des certificats auto-signés.

- Il est difficile d’établir une infrastructure pour la gestion du cycle de vie des certificats. Par exemple, les certificats auto-signés ne peuvent pas être révoqués.
Certificat délivré par une autorité de certification interne Le certificat est émis par une infrastructure à clé publique (PKI) dans votre organisation. Les services de certificats Active Directory (AD CS) en sont un exemple. Pour plus d’informations, consultez la vue d’ensemble des services de certificats Active Directory. - Permet aux organisations d’émettre leurs propres certificats.

- Moins coûteux que les certificats d’une autorité de certification commerciale.		 - Complexité accrue du déploiement et de la maintenance de l’infrastructure à clé publique.

- Le certificat n’est pas approuvé automatiquement par les ordinateurs clients et les appareils mobiles. Le certificat doit être ajouté manuellement au magasin de certificats racines de confiance sur tous les ordinateurs et les appareils clients, mais certains appareils mobiles n’autorisent pas les modifications apportées au magasin de certificats racines de confiance.
Certificat émis par une autorité de certification commerciale Le certificat est acheté auprès d’une autorité de certification commerciale approuvée. Le déploiement de certificats est simplifié, car tous les clients, appareils et serveurs approuvent automatiquement les certificats. Coût. Vous devez anticiper pour réduire au minimum le nombre de certificats nécessaires.

Pour prouver que le détenteur du certificat est bien celui qu’il prétend être, le certificat doit identifier avec précision le détenteur du certificat auprès des autres clients, appareils ou serveurs. Les trois méthodes de base pour ce faire sont décrites dans le tableau suivant :

Méthode Description Avantages Inconvénients
Correspondance de l’objet du certificat Le champ Objet du certificat contient le nom commun (CN) de l’hôte. Par exemple, le certificat émis pour www.contoso.com peut être utilisé pour le site web https://www.contoso.com. - Compatible avec tous les clients, appareils et services.

- Compartimentation. La révocation du certificat pour un hôte n’affecte pas les autres hôtes.		 - Nombre de certificats nécessaires. Vous pouvez utiliser le certificat seulement pour l’hôte spécifié. Par exemple, vous ne pouvez pas utiliser le certificat www.contoso.com pour ftp.contoso.com, même si les services sont installés sur le même serveur.

- Complexité. Sur un serveur web, chaque certificat nécessite sa propre liaison d’adresse IP.
Correspondance du nom de l’objet du certificat (SAN) En plus du champ Objet, le champ Autre nom de l’objet du certificat contient une liste de plusieurs noms d’hôtes. Par exemple :
www.contoso.com
ftp.contoso.com
ftp.eu.fabirkam.net		 - Commodité. Vous pouvez utiliser le même certificat pour plusieurs hôtes dans plusieurs domaines distincts.

- La plupart des clients, appareils et services prennent en charge les certificats SAN.

- Audit et sécurité. Vous savez exactement quels hôtes ont la capacité d’utiliser le certificat SAN.		 - Davantage de planification nécessaire. Vous devez fournir la liste des hôtes quand vous créez le certificat.

- Manque de compartimentation. Vous ne pouvez pas révoquer les certificats sélectivement pour certains des hôtes spécifiés sans affecter tous les hôtes du certificat.
Correspondance de certificat générique Le champ Objet du certificat contient le nom commun sous la forme du caractère générique (*), plus un domaine ou sous-domaine unique. Par exemple, *.contoso.com ou *.eu.contoso.com. Le certificat générique *.contoso.com peut être utilisé pour :
www.contoso.com
ftp.contoso.com
mail.contoso.com		 Flexibilité. Vous n’avez pas besoin de fournir la liste des hôtes quand vous demandez le certificat, et vous pouvez utiliser le certificat sur un nombre quelconque d’hôtes dont vous pourriez avoir besoin à l’avenir. - Vous ne pouvez pas utiliser de certificats génériques avec d’autres domaines de premier niveau. Par exemple, vous ne pouvez pas utiliser le certificat générique *.contoso.com pour des hôtes *.contoso.net.

- Vous pouvez utiliser des certificats génériques seulement pour les noms d’hôte au niveau du caractère générique. Par exemple, vous ne pouvez pas utiliser le certificat *.contoso.com pour www.eu.contoso.com. Autre exemple : vous ne pouvez pas utiliser le certificat *.eu.contoso.com pour www.uk.eu.contoso.com.

- Les clients, appareils, applications ou services plus anciens peuvent ne pas prendre en charge les certificats génériques.

- Les caractères génériques ne sont pas disponibles avec les certificats de validation étendue.

- Un audit et un contrôle minutieux sont nécessaires. Si le certificat générique est compromis, il affecte chaque hôte dans le domaine spécifié.

Contenu connexe