Certificats et autorités de certification

Trois sceaux de taille croissante, reliés par un ruban ; chaque sceau imprime sa marque dans le suivant.

À gauche de la barre d'adresse se trouve un cadenas. Clique dessus et ton navigateur te dit que la connexion est sécurisée. Mais sécurisée avec qui ? Quelqu'un peut monter un site qui ressemble exactement à celui de ta banque, avec un chiffrement tout aussi bon. Ce que ton navigateur vérifie là en un dixième de seconde, c'est un certificat : une déclaration signée disant que la clé à l'autre bout appartient bien à ce nom-là. Ce chapitre démonte une telle déclaration, champ par champ.

Les mots dont tu as besoin

Certificat: Un petit fichier contenant : un nom, une clé publique, une période de validité, et la signature de quelqu'un d'autre. Ce n'est rien de plus.
Autorité de certification (CA): L'instance qui signe ce petit fichier. Elle vérifie d'abord que le nom est correct, puis y met sa signature. En anglais certificate authority.
X.509: Le format dans lequel un tel certificat est écrit. Une seule convention, la même partout dans le monde : sur les sites web, sur ta carte d'identité, dans les réglages wifi de ton école.
Subject et issuer: Les deux noms présents dans chaque certificat. Le subject est celui dont il est question ; l'issuer est celui qui l'a signé.
Certificat racine: Un certificat qui se signe lui-même : subject et issuer sont le même nom. Il n'y a personne au-dessus. Une bonne centaine d'entre eux sont intégrés d'office dans ton système d'exploitation et dans ton navigateur.
Révoquer: Déclarer un certificat invalide avant sa date de fin, par exemple parce que la clé privée a été volée. On dit aussi révocation.
DER et PEM: Deux emballages du même certificat. DER, ce sont les octets bruts ; PEM, ce sont ces mêmes octets en base64 (chapitre 1) avec une ligne -----BEGIN CERTIFICATE----- devant, pour que tu puisses le coller dans un e-mail.

Le trou que laisse une signature

Dans chapitre 7.1 tu as signé quelque chose toi-même, puis tu l'as vérifié. Ce que cette vérification t'a dit, c'est ceci : la personne qui a signé possédait la clé privée qui va avec cette clé publique. C'est tout. Il n'y avait pas de nom. Si je fabrique une paire de clés (chapitre 6) et que j'affirme qu'elle appartient à ta banque, toutes mes signatures sont parfaitement correctes — par rapport à ma clé.

Un certificat comble ce trou de la seule façon qui marche : quelqu'un d'autre le déclare, et signe cette déclaration. Un certificat n'est donc rien de nouveau. C'est le chapitre précédent, appliqué à une phrase qui parle elle-même d'une clé :

« La clé publique A1B2… appartient à www.mabanque.be, du 1er mars au 30 mai. »

— signé par : Let's Encrypt

Ce qu'il y a littéralement dedans

Un certificat X.509 se compose de trois parties : un bloc avec toutes les données, le nom du système de signature utilisé, et la signature elle-même. Ce bloc de données s'appelle tbsCertificate, de to be signed : c'est précisément le morceau sur lequel le hachage (chapitre 2) est calculé avant la signature. Modifie un seul octet et la signature ne colle plus.

Champ	Ce qu'il contient
`version`	Presque toujours v3. C'est la version qui autorise les extensions, et sans extensions aucun site moderne ne fonctionne.
`serialNumber`	Un numéro que l'émetteur n'utilise jamais deux fois. Il est aussi choisi de façon imprévisible, car ainsi un attaquant ne peut pas calculer à l'avance ce qui sera signé.
`issuer`	Le nom de celui qui signe. C'est le maillon vers le haut dans la chaîne.
`validity`	Deux moments : `notBefore` et `notAfter`. En dehors de cette fenêtre, le certificat ne vaut rien, même si la signature est correcte.
`subject`	De qui il s'agit : un nom de domaine, une entreprise, ou pour ta carte d'identité une personne.
`subjectPublicKeyInfo`	La clé publique elle-même, plus le système dont il s'agit : RSA de tant de bits, ou ECDSA sur la courbe P-256. C'est autour de ça que tourne tout le certificat.
`extensions`	Des champs supplémentaires séparés. Voir ci-dessous.
`signatureAlgorithm` `signatureValue`	Avec quoi on a signé, et la signature. Attention : c'est la signature de l'émetteur sur tout ce qui précède — pas quelque chose que le propriétaire aurait posé lui-même.

Les trois extensions qui comptent le plus en pratique :

Extension	À quoi ça sert
`subjectAltName` (SAN)	Les noms de domaine pour lesquels ce certificat vaut. Les navigateurs regardent ici, et uniquement ici. Un seul certificat peut en couvrir des dizaines.
`keyUsage`	Ce que tu as le droit de faire avec la clé : poser des signatures, signer d'autres certificats, signer des listes de révocation. Une clé qui n'a droit qu'à `digitalSignature` ne peut pas délivrer de certificats.
`basicConstraints`	S'il y a `CA=JA`, ce détenteur peut délivrer lui-même des certificats. S'il y a `CA=NEE`, c'est un terminus. Ce seul petit champ fait la différence entre un site web ordinaire et une instance qui a le droit de signer pour le monde entier.

Un certain nombre d'extensions sont marquées critiques. Cela veut dire : qui ne comprend pas cette extension doit refuser le certificat. Ainsi on peut ajouter quelque chose plus tard sans qu'un vieux logiciel passe discrètement à côté.

La chaîne : du site web à la racine

Let's Encrypt ne signe pas directement avec la clé qui se trouve dans ton navigateur. Il y a un maillon entre les deux :

Certificat final — subject : un nom de domaine, par exemple www.enigmalab.be. Issuer : un certificat intermédiaire. Valable quelques mois.
Certificat intermédiaire — par exemple subject R11, issuer ISRG Root X1. Valable du 13 mars 2024 au 12 mars 2027. Quels certificats intermédiaires existent au juste, ça change ; parfois il y en a deux l'un sous l'autre.
Certificat racine — subject et issuer : ISRG Root X1. Valable du 4 juin 2015 au 4 juin 2035. Ce certificat est déjà dans ton ordinateur avant que tu ne l'allumes pour la première fois.

Chaque étape, ton navigateur la vérifie avec la clé publique de l'étape du dessus. À la racine, ça s'arrête : cette signature est celle de la racine elle-même, donc là plus rien ne prouve quoi que ce soit. Tu la crois parce que Microsoft, Apple, Google ou Mozilla ont décidé de la livrer avec. Ça, ce ne sont plus des maths, c'est la décision d'une entreprise.

Combien de ces racines fais-tu confiance sans le savoir ? Dans la liste que Mozilla a publiée le 13 août 2026, il y en a 121. Chacune de ces 121 peut fabriquer un certificat valide pour n'importe quel site web au monde. La chaîne est aussi solide que la plus faible des racines.

Pourquoi cette étape intermédiaire ? Parce que la clé privée de la racine est hors ligne, dans un coffre, dans un appareil qui ne la laisse pas sortir. Celle du certificat intermédiaire, elle, est bien en ligne et signe à longueur de journée. Si elle est volée, on révoque le certificat intermédiaire et on en fait un nouveau. La racine — et donc chaque appareil du monde — n'a pas besoin d'être touchée.

Regarde toi-même dans un certificat

Tout se passe dans ton navigateur. Rien n'est envoyé au serveur.

Dans le champ se trouve déjà un vrai certificat : R11, le certificat intermédiaire de Let's Encrypt. Clique sur Analyse ce certificat.
Regarde subject et issuer. Ils diffèrent : ce certificat est signé par ISRG Root X1.
Clique sur Certificat racine. Maintenant subject et issuer sont le même nom — et ce nom est exactement l'issuer de tout à l'heure. Ça, c'est un maillon de la chaîne, vu de tes propres yeux.
Dans les extensions, regarde basicConstraints. Chez les deux il y a CA=JA : ces deux-là peuvent signer.
Change une seule lettre dans le texte base64 et clique à nouveau. Les longueurs dans le format ne collent alors plus et tu reçois une erreur — pas un demi-résultat.
Tu veux voir un subjectAltName ? Clique sur le cadenas dans ta barre d'adresse, exporte le certificat de ce site ou d'un autre, ouvre le fichier dans un éditeur de texte et colle-le ici.

Certificat sous forme PEM

Qui sont ces autorités, et que vérifient-elles ?

Une CA ne vend pas du chiffrement. Elle vend une vérification. Tout dépend du sérieux de cette vérification, et ça varie énormément.

Ce qui est vérifié	Comment	Ce que ça t'apporte donc
Un nom de domaine, chez Let's Encrypt	La CA te donne un nombre aléatoire. Toi, tu le mets sur `http://tondomaine/.well-known/acme-challenge/…` ou dans un enregistrement DNS. La CA va le chercher depuis plusieurs endroits du monde en même temps.	Que c'est toi le patron de ce domaine. Pas qui tu es. Dans le certificat il y a donc littéralement « validé par domaine ».
Une personne, pour ta carte d'identité	Tu t'es présenté à la maison communale avec tes papiers, un fonctionnaire a vu ton visage, et l'État savait déjà qui tu étais.	Ton vrai nom et ton numéro de registre national. C'est pour ça que ce certificat vaut juridiquement quelque chose — voir chapitre 8.2.

La première vérification ne coûte rien et dure trente secondes ; la seconde coûte un déplacement à la maison communale. Elles sont toutes les deux utiles, mais elles prouvent quelque chose de complètement différent. Un cadenas dans ton navigateur ne dit donc pas que l'entreprise derrière est honnête — seulement que le nom dans la barre d'adresse est le bon.

Ce qui arrive quand l'une d'elles échoue

DigiNotar était une autorité de certification néerlandaise de Beverwijk. Elle signait entre autres pour les pouvoirs publics néerlandais : DigiD, le service avec lequel les Néerlandais se connectent au fisc, en dépendait.

Le 19 juillet 2011, l'entreprise a remarqué que ses systèmes avaient été piratés. Elle s'est tue. Le 10 juillet, un faux certificat pour *.google.com avait déjà été délivré. Fin août, un utilisateur en Iran est tombé sur un avertissement de Chrome : ce navigateur savait quels certificats appartenaient à Google, et celui-ci n'en était pas un. C'est là que ça a éclaté. Il s'est avéré qu'au moins 531 faux certificats avaient été fabriqués. Avec le certificat Google, le courrier d'environ 300 000 utilisateurs iraniens de Gmail avait été lu — dans un pays où cela peut coûter leur liberté à des gens.

Les fabricants de navigateurs ont alors jeté tous les certificats DigiNotar hors de leur liste. Du coup, l'entreprise ne valait plus rien : une CA que plus personne ne croit ne vend plus rien. Le 20 septembre 2011, moins d'un mois après la découverte, DigiNotar a été déclarée en faillite.

Une CA qui échoue ne casse pas ses propres clients mais tout le monde. C'est le prix d'un système où 121 racines ont toutes tous les droits. Depuis lors, les CA doivent inscrire chaque certificat délivré dans des journaux publics — la Certificate Transparency — pour que Google puisse voir qu'il existe quelque part un certificat pour google.com que Google n'a pas commandé. Tu vois ces preuves de journalisation dans la démo, sur un certificat d'un vrai site web.

Révoquer : invalide avant la date de fin

Une clé privée peut fuiter. Le détenteur peut cesser d'exister. Le certificat doit alors être invalide immédiatement, et pas seulement à notAfter. C'est plus compliqué qu'il n'y paraît, car le certificat lui-même ne change pas — il est sur le disque de l'attaquant et a l'air encore parfait. Il faut donc que quelque chose vienne s'ajouter pour dire : ne crois plus ceci.

Méthode	Comment	Problème
CRL certificate revocation list	La CA publie une liste des numéros de série révoqués. Ton navigateur va chercher cette liste et regarde si ton numéro de série y figure.	La liste est grande et est en retard sur la réalité.
OCSP online certificate status protocol	Ton navigateur le demande en direct à la CA, par certificat : est-ce encore valable ?	Tu racontes ainsi à la CA quels sites tu visites. Et si la CA ne répond pas, les navigateurs continuent quand même — sinon la moitié du web serait à l'arrêt.

C'est la deuxième objection qui l'a emporté. Let's Encrypt a retiré les adresses OCSP de ses certificats le 7 mai 2025 et a complètement arrêté le service le 6 août 2025, en invoquant la vie privée. Tu le retrouves dans la démo : sur un certificat d'un vrai site web, il y a bien un cRLDistributionPoints, pas d'adresse OCSP.

La vraie solution s'est révélée plus simple : faire des certificats si éphémères que la révocation n'a presque plus d'importance. Un certificat qui expire tout seul après quelques mois, c'est une clé volée qui se périme toute seule. C'est pourquoi un serveur renouvelle aujourd'hui son certificat automatiquement, bien avant l'échéance, sans qu'aucun humain n'intervienne.

Voici les maths : la confiance comme graphe orienté

Dessine chaque certificat comme une flèche : de l'issuer vers le subject. Ce que tu obtiens est un graphe orienté — des points avec des flèches entre eux — et la question « puis-je croire ce site web ? » devient la question « existe-t-il un chemin d'un point auquel je fais déjà confiance vers ce point-ci ? ». C'est exactement le genre de question dont traite la théorie des graphes, le même domaine qui calcule comment ton planificateur d'itinéraire trouve le chemin le plus court.

Du coup, on voit tout de suite où ça a dérapé chez DigiNotar. Dans ce graphe, il y a 121 points où un chemin peut commencer, et depuis chacun de ces points, chaque autre point est atteignable. Un seul point de départ compromis suffit pour fabriquer un chemin vers n'importe quel nom. Les maths ne te disent pas ici comment sécuriser quelque chose, mais à quel point la forme de ton système est vulnérable — et c'est tout aussi utile.