Accueil / Identité
Certificats, autorités et Web PKI
Le bon nom, le bon chemin — reste à prouver que le serveur au bout est bien le bon. Cette garantie repose sur quelques centaines d'autorités de certification dont chacune peut techniquement émettre un certificat pour n'importe quel domaine du monde. Tout l'édifice consiste à rendre cet abus détectable.
Le modèle de confiance et sa faille
Votre navigateur et votre système d'exploitation embarquent une liste d'autorités de certification racines — le magasin de confiance. Toute chaîne de certificats qui remonte à l'une d'elles est acceptée. Ces magasins sont gérés par un petit nombre d'acteurs : Apple, Google, Microsoft, Mozilla, et les programmes de distribution Linux.
La faille structurelle
N'importe quelle autorité de confiance peut émettre un certificat pour n'importe quel domaine. Rien dans le protocole n'empêche une autorité située à l'autre bout du monde d'émettre un certificat valide pour votre banque. Cette propriété est intrinsèque au modèle : la sécurité de l'ensemble est celle de son maillon le plus faible.
Deux précédents
DigiNotar, 2011. Une autorité néerlandaise est compromise. Des centaines de certificats frauduleux sont émis, dont un pour un service de messagerie majeur, utilisé pour intercepter les communications d'utilisateurs iraniens. L'autorité est retirée de tous les magasins de confiance et fait faillite en quelques semaines.
Symantec, 2017-2018. Une série de manquements aux règles d'émission conduit les navigateurs à retirer progressivement la confiance accordée à l'une des plus grandes autorités du marché. Des centaines de milliers de sites doivent remplacer leurs certificats.
Ces deux affaires ont produit la réponse actuelle : puisqu'on ne peut pas empêcher une émission abusive, il faut la rendre impossible à dissimuler.
Qui écrit les règles
Le CA/Browser Forum réunit les autorités de certification et les éditeurs de navigateurs. Il publie les Baseline Requirements, que toute autorité doit respecter pour rester dans les magasins de confiance. Les décisions se prennent par vote sur des bulletins numérotés — un mécanisme volontairement public, dont les archives de discussion sont consultables.
Trois niveaux de validation
DV — validation de domaine : on prouve qu'on contrôle le nom. Automatisable, gratuit, majoritaire aujourd'hui.
OV — validation d'organisation : l'identité de l'entité est vérifiée en plus.
EV — validation étendue : vérification approfondie. Les navigateurs ne l'affichent plus distinctement depuis 2019, ce qui a considérablement réduit son intérêt commercial.
Le tournant de l'automatisation
Le protocole ACME, associé à des autorités gratuites, a fait passer le chiffrement du web d'une minorité de sites à la quasi-totalité en moins de dix ans. C'est probablement l'amélioration de sécurité la plus massive de la décennie, et elle a été obtenue en supprimant une friction administrative plutôt qu'en ajoutant un mécanisme cryptographique.
Rendre toute émission publique
La transparence des certificats — RFC 6962 — impose que tout certificat émis par une autorité publiquement reconnue soit inscrit dans des journaux publics, en ajout seulement et vérifiables cryptographiquement. Un certificat absent de ces journaux est refusé par les navigateurs.
Ce que cela change
- Détection. Le titulaire d'un domaine peut voir tout certificat émis pour son nom, y compris ceux qu'il n'a pas demandés.
- Responsabilité. Une autorité ne peut plus émettre discrètement : son émission est publique et horodatée pour toujours.
- Effet secondaire. Les journaux constituent aussi une cartographie publique des noms de sous-domaines — utile aux administrateurs comme aux attaquants pour la reconnaissance.
Comment s'en servir
Le service crt.sh permet d'interroger l'ensemble des journaux pour un domaine donné. Plusieurs services envoient une alerte par courriel à chaque nouvelle émission. Pour un domaine sensible, cette surveillance est le complément indispensable du verrouillage au registre : elle détecte le détournement au moment où l'attaquant obtient son certificat.
Un effet de bord de la réduction des durées de vie
Le passage à des certificats de 47 jours multipliera par huit le nombre d'émissions annuelles, donc le volume à inscrire dans les journaux. Plusieurs autorités ont publiquement signalé pendant les discussions du bulletin SC-081 que l'infrastructure des journaux et des outils de surveillance devra être repensée pour absorber cette charge.
Contrôler qui peut émettre pour vous
L'enregistrement CAA
Publié dans le DNS, il déclare quelles autorités ont le droit d'émettre pour votre domaine. Toute autorité respectant les règles du CA/Browser Forum doit le consulter avant d'émettre et refuser si elle n'y figure pas.
C'est un contrôle simple, gratuit, et qui réduit d'un coup la surface d'attaque de quelques centaines d'autorités à une ou deux.
Le lien avec DNSSEC, depuis mars 2026
Le CAA repose sur le DNS. Si le DNS peut être falsifié, le CAA peut être contourné. C'est pourquoi le bulletin SC-085v2 du CA/Browser Forum, entré en vigueur le 15 mars 2026, impose désormais aux autorités de certification de tenir compte de DNSSEC lors de la validation du contrôle d'un domaine.
Conséquence concrète : signer sa zone DNSSEC protège désormais aussi l'émission de ses certificats. Les deux systèmes, longtemps parallèles, se renforcent maintenant l'un l'autre.
DANE, l'autre approche
DANE, décrit par le RFC 6698, permet de publier directement dans le DNS l'empreinte du certificat attendu, signée par DNSSEC. Le navigateur n'a alors plus besoin de faire confiance à une autorité tierce. Les navigateurs web ne l'implémentent pas, mais DANE est largement utilisé pour sécuriser le transport du courrier électronique entre serveurs, où il constitue une protection réelle contre le déclassement de chiffrement.
Pourquoi la révocation ne fonctionne pas
Quand une clé privée est compromise, il faudrait pouvoir annuler le certificat correspondant avant sa date d'expiration. En pratique, ce mécanisme n'a jamais fonctionné correctement.
| Mécanisme | Principe | Pourquoi ça échoue |
|---|---|---|
| CRL | Liste des certificats révoqués, téléchargée périodiquement | Listes énormes, mises à jour lentes, souvent ignorées |
| OCSP | Interrogation en direct de l'autorité pour chaque certificat | Latence, fuite de l'historique de navigation vers l'autorité, échec silencieux si le service est injoignable |
| OCSP stapling | Le serveur joint lui-même une preuve de non-révocation récente | Correct sur le principe, mais déploiement partiel et configuration fragile |
| Listes intégrées | Le navigateur embarque une liste filtrée des révocations importantes | Fonctionne, mais couvre seulement une sélection |
Le problème de fond est le comportement en cas d'échec : si un navigateur refusait de charger une page dès qu'il ne peut pas vérifier la révocation, la moindre panne d'une autorité couperait des millions de sites. Tous ont donc choisi d'échouer en silence — ce qui rend la vérification largement décorative.
La conclusion tirée par l'industrie
Puisque la révocation ne marche pas, la seule fenêtre d'exposition réellement contrôlable est la durée de vie du certificat lui-même. C'est le raisonnement explicite derrière la réduction en cours. On ne répare pas la révocation : on rend les certificats si courts que la révocation devient secondaire.
De 398 à 47 jours
La réponse de l'industrie au problème de la révocation est brutale et déjà engagée.
En avril 2025, le CA/Browser Forum a adopté le bulletin SC-081v3, proposé par Apple, par vingt-neuf voix pour et aucune contre. Il fixe un calendrier de réduction de la durée de vie maximale des certificats TLS publiquement reconnus.
| À partir du | Durée maximale | Réutilisation de la validation de domaine | Renouvellements par an |
|---|---|---|---|
| jusqu'au 14/03/2026 | 398 jours | 398 jours | 1 |
| 15 mars 2026 | 200 jours | 200 jours | 2 |
| 15 mars 2027 | 100 jours | 100 jours | 4 |
| 15 mars 2029 | 47 jours | 10 jours | ~8 |
La première étape est déjà en vigueur. Plusieurs autorités ont commencé à émettre à 199 jours dès février 2026, en s'octroyant une marge de sécurité : dépasser la limite d'une seconde constitue une erreur d'émission et déclenche une obligation de révocation.
Ce que ça implique
- L'automatisation devient obligatoire. Un parc de cent certificats représentera environ huit cents renouvellements par an en 2029. Aucun processus manuel ne tient à cette cadence.
- Le risque se déplace vers l'inventaire. Le danger principal n'est plus le certificat qu'on oublie de renouveler, mais celui qu'on ignore posséder — installé il y a des années sur un équipement que plus personne ne surveille.
- La fenêtre de réaction se réduit. Avec des certificats courts, une panne de la chaîne d'automatisation devient une panne de service en quelques jours, pas en quelques mois.
- Le modèle économique change. Vendre un certificat à l'unité n'a plus de sens ; les autorités basculent vers des abonnements avec client ACME intégré.
À faire avant mars 2027
Établir l'inventaire complet des certificats publics de l'organisation, y compris ceux installés sur des équipements réseau, des imprimantes, des sondes et des appliances. Identifier ceux qui ne peuvent pas être automatisés. Traiter ceux-là en priorité : ce sont eux qui casseront.
Une exception importante
Ce calendrier ne concerne que les certificats publiquement reconnus par les navigateurs. Une infrastructure à clés publiques interne, dont la racine est distribuée par l'entreprise elle-même, n'est pas soumise à ces règles. Rien n'oblige à aligner les deux — mais les mêmes arguments de sécurité s'y appliquent.
La migration post-quantique
Un ordinateur quantique de taille suffisante casserait RSA et les courbes elliptiques utilisées aujourd'hui. Aucune machine de ce type n'existe, mais la menace est prise au sérieux pour une raison précise : le trafic chiffré capté aujourd'hui peut être conservé et déchiffré plus tard.
Où en est-on
- Échange de clés. Les navigateurs et serveurs majeurs négocient déjà des échanges hybrides, combinant une courbe elliptique classique et un mécanisme post-quantique standardisé par le NIST. Une part importante du trafic TLS mondial en bénéficie déjà.
- Signatures. C'est la partie difficile. Les signatures post-quantiques sont bien plus volumineuses, ce qui pèse sur la taille des chaînes de certificats et sur les journaux de transparence. La migration des autorités de certification n'a pas commencé à grande échelle.
- DNSSEC. Même problème, aggravé par les contraintes de taille des réponses DNS. C'est l'un des arguments avancés pour préparer d'abord un changement d'algorithme vers ECDSA, plus compact, avant d'envisager le post-quantique.
L'agilité cryptographique comme objectif réel
La leçon commune de la réduction des durées de vie et de la préparation post-quantique est la même : ce qui compte n'est pas l'algorithme choisi aujourd'hui, mais la capacité à en changer rapidement. Une organisation capable de renouveler tout son parc de certificats en quarante-huit heures est prête pour la suite, quelle qu'elle soit. Une organisation qui met six mois ne l'est pas.