PKI, certificats et TLS : comment circule la confiance

Le cadenas qui vante une identité

Aux Arcades, le centre commercial qui sert de fil rouge à cette série, un nouveau gérant ouvre une boutique. Il affiche fièrement à sa vitrine une plaque gravée : « Bijouterie Aurum, locataire officiel ». Rien n'empêche pourtant un escroc de fabriquer la même plaque, de s'installer dans un local vide et d'encaisser des acomptes sur des bagues qui n'arriveront jamais.

Comment un client sait-il que la boutique est légitime ? Il fait confiance à un tiers : la direction du centre, qui tient le registre des baux et appose son tampon sur les contrats. Personne ne vérifie l'identité de chaque commerçant en personne. On délègue cette vérification à une autorité reconnue par tous.

Le web a exactement le même problème. Quand un navigateur se connecte à banque.example, le serveur lui présente une clé publique. Mais une clé publique n'est qu'un grand nombre. Rien dedans ne prouve qu'elle appartient à la banque plutôt qu'à un attaquant assis entre les deux.

Le problème de confiance dans la clé publique : comment être sûr qu'une clé publique appartient bien à l'entité qui la présente, et pas à un imposteur ?

C'est la question que résolvent la PKI (Public Key Infrastructure), les certificats et le protocole TLS. Cet article suit le chemin de la confiance, du registre des baux des Arcades jusqu'au handshake qui sécurise chaque page que tu charges.

Vue d'ensemble : les pièces du puzzle

Avant le détail, la carte du territoire. Quatre briques s'emboîtent pour transformer « voici ma clé » en « je te crois ».

• Le certificat. Une carte d'identité numérique qui lie une clé publique à un nom de domaine. Au format standard X.509.
• L'autorité de certification (CA). Le tiers de confiance qui vérifie l'identité et signe le certificat. La direction du centre commercial, en somme.
• La chaîne de confiance. La hiérarchie qui relie le certificat d'un serveur à une racine pré-installée dans ton système. Racine, intermédiaire, feuille.
• Le handshake TLS. La négociation au début de chaque connexion : le client valide le certificat, puis client et serveur dérivent une clé de session partagée.

À cela s'ajoutent deux mécanismes de contrôle a posteriori : la révocation (annuler un certificat compromis avant son expiration) et la Certificate Transparency (rendre publiques toutes les émissions de certificats pour repérer les abus).

Le tout s'appuie sur le chiffrement asymétrique, la paire clé publique / clé privée. On part du principe que cette base est acquise : ce qui suit explique comment on bâtit de la confiance par-dessus.

Le certificat : une carte d'identité signée

Reviens à la Bijouterie Aurum. Pour être crédible, le gérant n'affiche pas seulement sa plaque. Il présente un document tamponné par la direction : nom du commerce, numéro de local, durée du bail, signature de la direction. Le tampon est ce qui rend le document difficile à falsifier.

Un certificat numérique suit la même logique. C'est un fichier qui contient au minimum :

• le nom du sujet (par exemple banque.example),
• sa clé publique,
• l'identité de l'émetteur (la CA qui a signé),
• une période de validité (date de début et d'expiration),
• la signature numérique de la CA, calculée sur tout le reste.

Cette signature est le point clé. La CA hache le contenu du certificat et chiffre l'empreinte avec sa propre clé privée. N'importe qui possédant la clé publique de la CA peut vérifier la signature. Si elle est valide, c'est la preuve que la CA a bien attesté ce lien entre le nom et la clé, et que le contenu n'a pas été modifié depuis.

Le format de ces certificats est normalisé : X.509, décrit pour le web par la RFC 5280. C'est ce standard qui définit les champs, l'encodage et les extensions (comme la liste des noms de domaine couverts).

Un certificat ne chiffre rien par lui-même. Il fait une seule chose : attester, via une signature, qu'une clé publique appartient bien à une identité donnée.

Tous les certificats ne se valent pas

Le niveau de vérification effectué par la CA avant d'émettre varie. Trois grandes familles cohabitent.

Un certificat DV prouve que tu parles bien au serveur qui contrôle ce domaine. Il ne dit rien sur l'honnêteté de l'organisation derrière. C'est une distinction importante : le cadenas du navigateur atteste de l'authenticité du canal, pas de la moralité du site.

C'est ce niveau DV, automatisé et gratuit, qu'a popularisé Let's Encrypt, via le protocole ACME qui délivre et renouvelle les certificats sans intervention humaine.

La chaîne de confiance : une hiérarchie d'accréditation

Aux Arcades, la direction ne signe pas elle-même chaque bail. Elle délègue à des gestionnaires d'étage, qui eux signent les contrats des boutiques. Quand un client veut vérifier la Bijouterie Aurum, il remonte la chaîne : le bail est signé par le gestionnaire de l'étage 2, lui-même accrédité par la direction générale, dont l'autorité ne se discute pas. La confiance se propage de haut en bas.

La PKI fonctionne pareil, sur trois niveaux.

• La racine (Root CA). Au sommet. Son certificat est auto-signé : elle se signe elle-même. Sa légitimité ne vient pas d'une signature, mais du fait qu'elle est pré-installée dans ton système d'exploitation et ton navigateur, dans ce qu'on appelle le magasin de confiance. La clé privée de la racine est gardée hors ligne, dans un module matériel verrouillé.
• L'intermédiaire (Intermediate CA). Signée par la racine. C'est elle qui émet les certificats au quotidien. Ce niveau intermédiaire existe précisément pour ne jamais exposer la clé racine : si un intermédiaire est compromis, on le révoque sans toucher à la racine.
• La feuille (Leaf). Le certificat du serveur que tu visites. Signé par un intermédiaire.

Quand ton navigateur reçoit le certificat de banque.example, il vérifie sa signature avec la clé publique de l'intermédiaire, puis vérifie la signature de l'intermédiaire avec la clé publique de la racine. Si la racine figure dans le magasin de confiance, la chaîne est valide. Si un seul maillon casse, ou si la racine est inconnue, le navigateur affiche un avertissement.

La confiance ne se vérifie jamais en interrogeant le site lui-même. Elle se valide en remontant une chaîne de signatures jusqu'à une racine déjà présente sur ta machine.

Qui décide quelles racines méritent leur place dans le magasin ? Des programmes CA exigeants, dont le plus documenté est le programme CA de Mozilla, qui impose audits, règles d'émission et droit de retrait. Une CA qui ne respecte pas ces règles peut être éjectée du magasin, ce qui revient à invalider d'un coup tous ses certificats.

Le handshake TLS, en bref

Le certificat et la chaîne établissent à qui on parle. Reste à établir comment parler de façon confidentielle. C'est le rôle du handshake TLS, la poignée de main qui ouvre chaque connexion https://.

Le protocole actuel est TLS 1.3, défini par la RFC 8446. Il a simplifié et accéléré la négociation par rapport aux versions précédentes. Voici les grandes étapes, volontairement résumées.

Décortiqué simplement :

1. Le client annonce les algorithmes qu'il supporte et envoie sa part d'un échange de clés.
2. Le serveur répond avec sa propre part et présente son certificat, signé.
3. Le client valide la chaîne de confiance du certificat. C'est ici que tout le mécanisme précédent entre en jeu. Si la validation échoue, la connexion est interrompue.
4. Les deux parties dérivent, chacune de leur côté, une clé de session symétrique commune, sans jamais la transmettre en clair.
5. Toute la suite de la communication est chiffrée avec cette clé de session, rapide et symétrique.

L'asymétrique (les certificats, les signatures) sert à s'authentifier et à se mettre d'accord sur un secret. Le symétrique prend ensuite le relais pour le débit. Cette combinaison est le cœur de la performance de TLS.

Révocation : retirer un badge volé

Un certificat a une date d'expiration, mais que se passe-t-il si la clé privée d'un serveur est volée avant cette date ? Aux Arcades, quand un employé perd son badge d'accès aux réserves, on ne réimprime pas tous les badges du centre. On inscrit le numéro volé sur une liste noire que les lecteurs consultent. Le badge existe toujours, mais il est désormais refusé.

La PKI dispose de deux mécanismes équivalents pour invalider un certificat avant son terme.

Une variante, l'OCSP stapling, permet au serveur d'attacher lui-même une preuve de statut fraîche et signée par la CA pendant le handshake, ce qui évite au client d'interroger la CA. En pratique, la révocation reste le maillon historiquement faible de la PKI : un client qui ne parvient pas à joindre le répondeur OCSP accepte souvent quand même la connexion, ce qui en limite la portée.

La révocation répond à une question simple : un certificat encore valide en apparence a-t-il été déclaré compromis depuis son émission ?

DigiNotar : quand le tiers de confiance s'effondre

Toute cette architecture repose sur une hypothèse : les CA sont dignes de confiance. Que se passe-t-il quand cette hypothèse tombe ? L'histoire en a fourni un cas d'école.

En 2011, l'autorité de certification néerlandaise DigiNotar a été piratée. Les attaquants ont pris le contrôle de son infrastructure d'émission et ont généré des certificats frauduleux pour des domaines qu'ils ne contrôlaient pas, dont un certificat valide pour *.google.com. Ce certificat, signé par une CA présente dans les magasins de confiance, était techniquement accepté par les navigateurs comme authentique.

Il a été utilisé pour intercepter le trafic d'internautes, principalement en Iran, via des attaques de l'homme du milieu : les victimes croyaient parler à Google de façon chiffrée, alors qu'un tiers lisait tout. L'analyse technique de l'incident a été menée par Fox-IT dans le rapport « Black Tulip », dont l'agence européenne ENISA a documenté les conclusions et les conséquences sur l'écosystème de confiance.

La réponse a été radicale. Les éditeurs de navigateurs et de systèmes ont retiré DigiNotar de leurs magasins de confiance. Du jour au lendemain, tous les certificats émis par cette CA sont devenus invalides. L'entreprise a fait faillite peu après.

Une seule CA compromise suffit à mettre en défaut l'ensemble du modèle. C'est une défaillance systémique : la confiance accordée à une racine se propage à tout ce qu'elle signe, y compris ce qui est frauduleux.

DigiNotar a montré que la robustesse de la cryptographie ne sert à rien si le maillon humain et organisationnel, la CA, peut être renversé. Il fallait un mécanisme pour détecter les émissions illégitimes, même par une CA techniquement « de confiance ».

Certificate Transparency : rendre les émissions publiques

La leçon de DigiNotar est qu'une émission frauduleuse peut passer inaperçue parce que personne, hors de la CA, ne voit ce qu'elle signe. La parade s'appelle Certificate Transparency (CT), spécifiée par la RFC 6962.

L'idée est simple. Chaque certificat émis doit être inscrit dans des journaux publics, append-only et vérifiables cryptographiquement. N'importe qui peut consulter ces journaux. Un propriétaire de domaine peut donc surveiller les certificats émis pour son nom et repérer immédiatement une émission qu'il n'a pas demandée.

Reviens une dernière fois aux Arcades. Imagine que chaque bail signé soit obligatoirement publié dans un registre public affiché à l'entrée du centre, impossible à modifier après coup. Si la direction signait en douce un faux bail pour la Bijouterie Aurum, le vrai gérant le verrait apparaître au registre et donnerait l'alerte. La fraude reste possible, mais elle devient visible, donc détectable.

Concrètement, les navigateurs modernes refusent les certificats qui ne sont pas accompagnés d'une preuve d'inscription dans des journaux CT. La transparence est devenue une condition de la confiance, pas une option.

CT ne remplace pas les CA et n'empêche pas une compromission. Il change la donne d'une autre façon : il rend les abus observables par tous, ce qui transforme une trahison silencieuse en incident public et rapidement traçable.

Points clés

• Un certificat X.509 lie une clé publique à une identité ; sa valeur tient à la signature d'une autorité de certification, pas au document lui-même.
• La confiance se valide en remontant une chaîne (feuille, intermédiaire, racine) jusqu'à une racine pré-installée dans le magasin de confiance de ton système.
• Le handshake TLS 1.3 authentifie le serveur via son certificat, puis dérive une clé de session symétrique pour chiffrer les échanges efficacement.
• La révocation (CRL, OCSP) invalide un certificat compromis avant son expiration, mais reste un maillon imparfait du modèle.
• Le cas DigiNotar (2011) a prouvé qu'une seule CA compromise est une défaillance systémique ; la Certificate Transparency y répond en rendant chaque émission publique et auditable.

Dans la série

Palier 2 : Verrouiller les accès. Domaine : Cryptographie.

• Précédent : Chiffrement symétrique, asymétrique et hachage
• Suivant : Authentification, MFA et SSO
• Vue d'ensemble : Par où commencer dans Les Arcades

Pour aller plus loin

• RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 5280, Internet X.509 Public Key Infrastructure Certificate
• RFC 6962, Certificate Transparency
• Let's Encrypt, comment fonctionne le protocole ACME
• Programme CA de Mozilla
• Qu'est-ce que le DevSecOps ?, pour replacer la gestion des certificats dans une chaîne logicielle sécurisée