Certificats TLS/SSL | Le Guide de la Confiance Numérique

Introduction

Lorsque vous voyez un cadenas dans la barre d'adresse de votre navigateur, vous observez un certificat TLS en action. Sécurité de la couche de transport (TLS) est le protocole qui chiffre les communications entre votre navigateur et un serveur web, et les certificats TLS sont les certificats numériques qui le rendent possible.

Vous pouvez encore entendre des personnes parler de "certificats SSL." Couche de sockets sécurisée (SSL) était le protocole original développé par Netscape au milieu des années 1990. SSL 3.0, publié en 1996, était la dernière version avant que le protocole ne soit renommé et redessiné en TLS 1.0 en 1999. Aujourd'hui, toutes les versions de SSL sont obsolètes et considérées comme non sécurisées. TLS 1.2 (2008) et TLS 1.3 (2018) sont les versions en cours d'utilisation. Le terme "certificat SSL" persiste dans le marketing et les conversations, mais la technologie qui le sous-tend est TLS. Tout au long de ce guide, nous utilisons "certificat TLS" pour être précis.

Les certificats TLS remplissent deux fonctions essentielles : ils authentifient le serveur (prouvant que vous vous connectez au vrai site web et non à un imposteur) et ils activent le chiffrement (garantissant que les données échangées entre votre navigateur et le serveur ne peuvent être lues ou altérées par quiconque sur le réseau).

Comment TLS Fonctionne

Chaque connexion HTTPS commence par un handshake TLS, un échange rapide qui se produit en millisecondes avant que toute donnée d'application ne soit transmise. Voici une vue simplifiée du handshake TLS 1.3 :

1

Client Hello

Le navigateur envoie un message "Client Hello" au serveur, indiquant les versions TLS et les suites de chiffrement qu’il prend en charge, ainsi qu’une valeur générée aléatoirement. Dans TLS 1.3, le client envoie également son partage de clé dans ce premier message, réduisant la poignée de main à un seul aller‑retour.

2

Server Hello & Certificat

Le serveur répond avec la suite de chiffrement choisie, sa propre valeur aléatoire, son partage de clé, et, de façon critique, son certificat TLS. Le certificat contient la clé publique du serveur's et est signé par une autorité de confiance Autorité de certification.

3

Validation du certificat

Le navigateur vérifie le certificat : l'Autorité de certification (CA) est-elle fiable ? Le certificat a-t-il expiré ? A-t-il été révoqué ? Le nom de domaine du certificat correspond-il à l'URL ? Si une vérification échoue, le navigateur affiche un avertissement de sécurité et la connexion est interrompue.

4

Échange de clés & Session chiffrée

En utilisant les parts de clés échangées dans les messages hello, les deux parties dérivent les mêmes clés de session via un échange Diffie-Hellman. Ces clés symétriques chiffrent toutes les communications ultérieures. Les clés privées ne sont jamais transmises ; seules les parts de clés nécessaires pour dériver les clés de session.

L'ensemble de la poignée de main se termine en un seul aller-retour avec TLS 1.3 (contre deux avec TLS 1.2). Une fois la poignée de main terminée, toutes les données circulent chiffrées. Si quelqu'un intercepte le trafic, il ne voit que du texte chiffré.

Validation Niveaux

Tous les certificats TLS ne sont pas créés égaux. L'Autorité de certification qui délivre le certificat effectue un niveau de vérification différent selon le type demandé. Il existe trois niveaux de validation standard :

Validation de domaine (DV)

Le type le plus simple et le plus rapide. L’Autorité de certification ne vérifie que le demandeur contrôle le domaine, généralement via un enregistrement DNS, un défi HTTP ou un courriel à une adresse prédéfinie. Les certificats DV peuvent être délivrés en quelques minutes et sont souvent gratuits (p. ex., Let's Encrypt). Ils fournissent chiffrement mais ne vérifient pas l'organisation derrière le domaine. DV convient aux blogs, sites personnels et services internes où l'identité organisationnelle n'est pas une préoccupation.

Validation d'organisation (OV)

En plus du contrôle de domaine, la CA vérifie l'existence légale et l'identité de l'organisation qui demande le certificat. Cela implique la vérification des documents d'enregistrement de l'entreprise, la vérification de l'adresse physique de l'organisation, et la confirmation de l'autorité du demandeur à agir au nom de l'organisation. Les certificats OV prennent d'un à trois jours pour être émis et incluent le nom de l'organisation dans les détails du certificat. Ils sont appropriés pour les sites web d'entreprise et les plateformes de commerce électronique où les clients peuvent vouloir vérifier qui exploite le site.

Validation étendue (EV)

Le niveau le plus rigoureux. Les certificats EV nécessitent une vérification approfondie de l'existence juridique, physique et opérationnelle de l'organisation, y compris la confirmation des personnes spécifiques autorisant la demande. Le processus peut prendre jusqu'à une semaine. Les certificats EV déclenchaient autrefois une barre d'adresse verte dans les navigateurs, mais la plupart des navigateurs ont supprimé cet indicateur visuel. Malgré cela, les certificats EV restent pertinents pour les institutions financières, les portails gouvernementaux et les organisations où le plus haut niveau d'identité vérifiée est requis par la politique ou la réglementation.

Les trois niveaux de validation offrent le même niveau de chiffrement. La différence réside dans la quantité de vérification d'identité que le CA effectue. Choisir le bon niveau dépend de votre cas d'utilisation, des exigences réglementaires et de l'importance de l'identité organisationnelle pour vos utilisateurs.

Générique & Multi-domaine Certificats

Les organisations ont souvent besoin d'un seul certificat pour couvrir plusieurs domaines ou sous‑domaines. Deux mécanismes répondent à ce besoin :

Certificats génériques

Un certificat générique sécurise un domaine et tous ses sous‑domaines à un niveau. Par exemple, un certificat pour *.example.com couvre www.example.com, api.example.com, et mail.example.com. Il ne couvre pas les sous‑domaines à plusieurs niveaux comme staging.api.example.com. Les certificats génériques simplifient la gestion mais nécessitent une manipulation prudente : si la clé privée est compromise, tous les sous‑domaines sont affectés.

Certificats SAN / multi-domaines

Les certificats Subject Alternative Name (SAN) peuvent inclure plusieurs noms de domaine distincts dans un seul certificat. Par exemple, un certificat pourrait couvrir example.com, example.org, et shop.example.net. Les certificats SAN sont courants dans les environnements cloud et les déploiements CDN où un serveur unique héberge de nombreux domaines différents.

Quand utiliser lequel

Utiliser certificats génériques lorsque vous avez de nombreux sous-domaines sous un même domaine et que vous souhaitez une gestion simplifiée. Utiliser certificats SAN lorsque vous devez sécuriser des domaines non liés ou un mélange de domaines et de sous-domaines. Certains certificats combinent les deux, en utilisant des entrées génériques au sein d’une liste SAN.

Considérations de sécurité

Les certificats génériques et SAN augmentent le rayon d'explosion d'une compromission de clé privée. Si la clé est divulguée, chaque domaine du certificat est en danger. Les organisations doivent peser la commodité contre le risque, utiliser une protection forte des clés et envisager des certificats à durée de vie plus courte pour limiter l'exposition.

Certificat TLS Cycle de vie

Un certificat TLS n’est pas un objet statique. Il suit un cycle de vie bien défini, et chaque étape nécessite une attention pour éviter les lacunes de sécurité ou des pannes.

Demande & Émission

Une paire de clés est générée, une demande de signature de certificat (CSR) est créée, et l'Autorité de certification (CA) valide l'identité du demandeur. Une fois validée, la CA délivre et signe le certificat. Pour les certificats DV avec ACME automatisation, ce processus complet peut se dérouler en quelques secondes sans intervention humaine.

Déploiement & Installation

Le certificat est installé sur le serveur web, le répartiteur de charge, le CDN ou le proxy inverse. Les erreurs de configuration à ce stade, telles que les certificats intermédiaires manquants, les chemins de fichiers de clé incorrects ou les suites de chiffrement mal configurées, sont une cause principale des échecs TLS.

Surveillance & Renouvellement

Tout au long de sa période de validité, le certificat doit être surveillé pour les expirations à venir, la révocation et la conformité aux politiques organisationnelles. Le renouvellement doit commencer bien avant la date d'expiration. Avec les protocoles d'automatisation comme ACME, le renouvellement peut être entièrement automatisé.

Révocation & Remplacement

Si une clé privée est compromise, qu'un employé part ou qu'un domaine change de propriétaire, le certificat doit être révoqué immédiatement et remplacé. L'Autorité de certification publie la révocation via CRL ou OCSP, et les clients sont censés vérifier cela avant de faire confiance au certificat.

La poussée vers des durées plus courtes Durées de vie

La période de validité maximale des certificats TLS se réduit régulièrement, et cette tendance s'accélère. Comprendre pourquoi et ce que cela implique pour les opérations est essentiel pour toute organisation gérant des certificats TLS.

Chronologie

En 2012, les certificats pouvaient être valides jusqu'à 5 ans. En 2018, le maximum est tombé à 2 ans. En 2020, Apple a unilatéralement réduit le maximum à 398 jours pour les certificats approuvés par Safari, et le Forum CA/Navigateur a suivi le même mouvement. En 2025, le Forum a voté de réduire davantage les durées de vie : 200 jours d'ici mars 2026, 100 jours d'ici mars 2027, et 47 jours d'ici mars 2029. Les périodes de réutilisation de validation de domaine diminueront également, atteignant seulement 10 jours d'ici 2029.

Pourquoi le plus court est meilleur

Des durées de vie plus courtes réduisent la fenêtre d'exposition si une clé est compromise, car un attaquant détenant une clé privée volée ne peut l'utiliser que jusqu'à l'expiration du certificat. Elles obligent également à une validation de domaine plus fréquente, garantissant que les détenteurs de certificats contrôlent réellement les domaines de leurs certificats. De plus, des durées de vie plus courtes réduisent la dépendance aux mécanismes de révocation (CRL/OCSP), qui présentent des problèmes de fiabilité connus.

Le défi opérationnel

À une durée de vie de 47 jours, un seul certificat nécessite environ huit renouvellements par an. Pour une organisation gérant des milliers de certificats, cela signifie des dizaines de milliers d'opérations de renouvellement chaque année. Les processus manuels (tableurs, rappels de calendrier, demandes basées sur tickets) ne peuvent tout simplement pas suivre. L'automatisation n'est plus optionnelle ; elle est une condition préalable à l'exploitation du TLS à grande échelle.

Organisations qui n'ont pas encore adopté la gestion automatisée des certificats devraient commencer à planifier dès maintenant. Les calendriers de transition sont déjà définis, et l'impact opérationnel augmente à chaque réduction de la période de validité.

PKI

CLM

Cas d’utilisation

Secteurs

Conformité

Apprendre

Outils & analyses

Événements & Communauté

TLS/SSL Certificats

Faits rapides