Délai de journalisation Certificate Transparency : ce que révèlent 1.3M de certificats
En résumé : Nous avons analysé l'historique public Certificate Transparency (CT) d'environ 700 domaines à fort trafic et comparé le début de validité déclaré de chaque certificat (NotBefore) au moment où il est réellement apparu dans un registre CT. Sur 1.29 million de certificats journalisés entre 2013 et la mi-2026, 19.6% ont mis plus de deux jours complets à apparaître dans CT, et 15.0% ont mis plus d'une semaine. Nous avons ensuite scindé les données au 15 juin 2026, date à laquelle le Chrome Root Program a commencé à exiger que le certificat final émis, et pas seulement le pré-certificat, contienne un enregistrement de registre CT valide. Après cette date, la part des délais supérieurs à 48 heures chute à 1.7% et la part des délais supérieurs à une semaine tombe à 0.8%, sur la même population et avec la même méthode de mesure. Le certificat médian était déjà traité rapidement avant cette obligation. Ce qui a changé, c'est la queue de distribution, ces certificats qui restaient non journalisés pendant des jours, des semaines ou des mois. Chaque chiffre présenté ici provient d'une lecture passive d'un registre public. Aucun hôte n'a été contacté, aucun scan n'a été effectué. Voici exactement comment nous l'avons mesuré, quelles autorités de certification ont comblé l'écart le plus vite, et ce que cela prouve ou non.
Deux chiffres, une mise à jour de politique
Certificate Transparency a été conçu pour faire de l'émission de certificats un registre public, en ajout seul : chaque CA publiquement reconnue consigne les certificats qu'elle émet, afin que quiconque, propriétaire de domaine, navigateur, chercheur, puisse voir ce qui a été créé pour un nom donné. Le problème résidait dans le terme "à terme". Une CA est tenue de journaliser un pré-certificat et d'y intégrer ses horodatages signés avant d'émettre le certificat final depuis 2018, et un Maximum Merge Delay standard du secteur limite le délai dont dispose un registre pour fusionner un pré-certificat soumis, généralement autour de 24 heures. Mais jusqu'à cette année, il n'existait aucun délai équivalent pour la journalisation du certificat final lui-même. Un certificat pouvait être signé, daté et déjà utilisé en production alors que sa propre entrée dans le registre accusait un retard de plusieurs jours, plusieurs semaines ou, dans au moins un cas documenté de manière indépendante, plusieurs mois.
Observez attentivement la médiane : elle n'a presque pas bougé, passant de 1.0 heure avant l'obligation à 0.975 heure après. Il ne s'agit pas d'une erreur de données, mais de la forme réelle de la distribution. La plupart des certificats, chez la plupart des émetteurs, étaient déjà journalisés dans l'heure bien avant l'introduction de toute obligation. Ce que cette politique a visiblement comblé, c'est la queue de distribution : la minorité de certificats qui restaient invisibles pendant des jours ou des semaines sans aucun enregistrement public. Le délai moyen illustre cette réalité plus nettement, tombant d'environ 64 jours avant l'échéance à 6.7 heures après, car une moyenne est précisément tirée vers le haut par les valeurs aberrantes qu'une médiane masque.
Le mécanisme : une échéance pour les pré-certificats, et aucun délai pour le reste
La conception initiale de Certificate Transparency journalise un pré-certificat, un marqueur à extension critique (poison extension) qui permet à une CA de collecter des Signed Certificate Timestamps avant de signer le certificat réel. Plusieurs registres CT publics doivent accepter et intégrer ce pré-certificat dans la limite d'un Maximum Merge Delay, de l'ordre d'une journée, et les navigateurs imposent aux registres de le respecter depuis 2018. Cette partie du pipeline a toujours été ponctuelle, ce qui permettait au secteur d'affirmer globalement que "CT est obligatoire".
La faille venait de l'autre moitié : rien n'obligeait la CA à soumettre le certificat final émis à un registre selon un calendrier précis. Une CA pouvait obtenir ses SCT à partir du pré-certificat, les intégrer, émettre le certificat et le mettre en production, en toute conformité, pendant que l'entrée CT du certificat final restait en attente. Un cas documenté de manière indépendante mentionne un certificat wildcard émis par DigiCert pour une plateforme majeure, présentant un décalage d'environ trois mois entre son émission déclarée et son apparition dans CT (nous n'avons pas vérifié ce cas précis de manière indépendante ; considérez-le comme une anecdote illustrative et non de référence). Nos propres données révèlent la même tendance à l'échelle globale : avant l'obligation, une part significative de certificats de plusieurs grandes CA restait invisible plus d'une semaine sans enregistrement public, ce qui constitue précisément la brèche ciblée par la politique de Chrome de juin 2026 en exigeant que le certificat final lui-même contienne un enregistrement de registre valide.
Quelles autorités ont comblé l'écart, et dans quelle proportion
Nous nommons ici les autorités de certification, et non les domaines dont nous avons dénombré les certificats. Les pratiques de journalisation d'une CA relèvent de l'intérêt public, de la même manière qu'une de nos études précédentes s'intéressait à quelles CA les domaines autorisent à émettre pour eux. Pour chaque émetteur disposant d'un échantillon significatif de part et d'autre de l'échéance, voici la part de ses certificats journalisés plus de 48 heures après NotBefore, avant et après le 15 juin 2026 :
| Émetteur | Avant (n) | Avant | Après (n) | Après |
|---|---|---|---|---|
| DigiCert Inc | 160,949 | 27.9% | 290 | 6.2% |
| Amazon | 95,508 | 20.0% | 863 | 2.9% |
| Google Trust Services | 66,473 | 10.3% | 2,249 | 3.1% |
| Sectigo Limited | 24,430 | 0.02% | 60 | 0.0% |
| Let’s Encrypt | 532,280 | 0.06% | 5,523 | 0.0% |
Deux constats s'imposent. Premièrement, Let’s Encrypt et Sectigo étaient déjà proches de zéro avant l'entrée en vigueur de l'obligation, ce qui concorde avec leurs pipelines d'émission massifs et hautement automatisés où "émettre et journaliser" s'apparente à une opération atomique. Deuxièmement, les CA qui disposaient de la plus grande marge de progression, DigiCert, Amazon et Google Trust Services, ont toutes progressé de manière spectaculaire, réduisant leur taux de journalisation tardive d'un facteur quatre à sept environ. Nous n'avons pas pu établir de comparaison avant/après fiable pour chaque émetteur : GlobalSign, l'ancienne marque COMODO et ZeroSSL comptaient trop peu de certificats post-obligation dans notre échantillon pour être représentatifs (moins de quelques dizaines) ou aucun des domaines suivis ne s'est renouvelé chez eux depuis le 15 juin 2026. Il s'agit d'une limite de notre échantillon de domaines, et non d'une conclusion sur ces émetteurs.
Notre méthodologie de mesure
Un esprit critique doit pouvoir reproduire ces résultats de zéro. Voici donc l'intégralité de la méthode, sans filtre.
- La population. Environ 700 domaines issus du Tranco top 1,000, rassemblés au fil de plusieurs de nos récentes études sur le DNS passif. Pour chaque domaine, nous avons consulté l'intégralité de son historique Certificate Transparency sur crt.sh, qui renvoie chaque certificat journalisé pour ce domaine et ses sous-domaines depuis 2013.
- La métrique. Pour chaque certificat journalisé, nous avons comparé son champ
not_before(le début de validité déclaré du certificat) àentry_timestamp(le moment où crt.sh a enregistré cette entrée de journal). La différence correspond au délai que nous indiquons. Nous avons dédoublonné les entrées selon l'identifiant interne de crt.sh et écarté une poignée d'entrées présentant un écart invraisemblable (plus de cinq ans), considéré comme un artefact d'horloge ou de parsing plutôt que comme un comportement réel d'émission. - La segmentation. Nous avons réparti chaque certificat selon que son champ NotBefore se situait avant ou à compter du 15 juin 2026, date d'entrée en vigueur de l'exigence du Chrome Root Program imposant que le certificat final émis comporte un enregistrement CT valide. Nos données en cache s'étendent jusqu'au 24 juillet 2026. La fenêtre post-obligation couvre donc environ les six premières semaines d'application, et non une année entière. Ces chiffres post-obligation doivent être considérés comme un premier aperçu appelé à se consolider, et non comme une tendance définitive.
- Ce que nous n'avons pas fait. Nous n'avons jamais demandé de certificat, ne nous sommes connectés à aucun serveur web et n'avons effectué aucun scan. Lire un registre public CT est une simple consultation, pas un sondage actif, selon le principe qui régit chacune de nos missions.
- Ce que nous avons conservé. Des comptages agrégés, des médianes et des centiles, par émetteur et par période. Aucun nom de domaine ou de sous-domaine ne figure dans les résultats, et nous n'avons collecté aucune donnée personnelle. Les noms de domaine et les métadonnées publiques de certificats ne constituent pas des données personnelles.
Ce que cela ne prouve pas
Des limites assumées, car un chiffre sans ses nuances n'est que du marketing.
- La fenêtre post-obligation est courte. Six semaines de données suffisent pour observer la dynamique du changement, pas pour certifier sa pérennité. Une partie de l'amélioration pourrait refléter une conformité initiale rigoureuse qui tend à se relâcher avec le temps. Nous prévoyons de réévaluer ce point.
- Tous les émetteurs ne présentent pas une situation post-obligation représentative. Une poignée de grandes CA comptaient tout simplement trop peu de certificats post-obligation dans notre échantillon de 700 domaines pour présenter des chiffres rigoureux. Un échantillon de domaines plus large permettrait de combler ce manque.
- NotBefore n'est pas un indicateur parfait du moment où le certificat a réellement été signé. Une CA peut antidater légèrement NotBefore pour tolérer les dérives d'horloge. Cette pratique gonfle légèrement nos chiffres de délai, même pour une CA qui consigne rapidement ses données. Elle n'explique toutefois pas des écarts de plusieurs jours ou semaines.
- Il s'agit d'une mesure de délai, pas d'un constat d'émission frauduleuse ou incorrecte. Un certificat journalisé tardivement ne prouve pas qu'il a été émis de façon illégitime, seulement que la piste d'audit publique a pris du retard sur son utilisation. Le risque réside dans cette absence d'audit : tant qu'un certificat n'est pas journalisé, quiconque surveille CT pour son propre domaine ne peut pas le détecter.
- L'échantillon penche vers les domaines à fort trafic. Le top 1,000 de Tranco repose sur des organisations aux ressources importantes et sur de grands CDN. Le comportement d'émission pour la longue traîne des sites plus modestes, qui utilisent souvent les mêmes grandes CA mais via des automatisations différentes, pourrait être différent.
Pourquoi c'est important
Toute la valeur ajoutée de Certificate Transparency pour un propriétaire de domaine repose sur la capacité à surveiller le registre public pour son propre nom et à intercepter un certificat imprévu avant qu'il ne soit exploité à ses dépens. Cela ne fonctionne que si la journalisation intervient immédiatement après l'émission. Un certificat qui reste non consigné pendant un mois est un certificat actif, validé par tous les navigateurs et pourtant invisible pour quiconque surveille CT pendant toute cette période. La faille comblée par cette obligation n'a rien d'exotique. C'est la différence concrète entre "nous respectons techniquement Certificate Transparency" et "vous pouvez réellement voir ce que nous émettons, sans délai et à chaque fois". Les données démontrent que les émetteurs les plus rapides du secteur, dont Let’s Encrypt et Sectigo, traitaient déjà cela comme une étape atomique bien avant que la réglementation ne l'impose. Les autres rattrapent visiblement leur retard maintenant que le Chrome Root Program en a fait une obligation ferme et non une simple bonne pratique. C'est exactement le même constat que nous avions dressé en observant qui valide réellement les registres CT en production : les aspects de cet écosystème soumis à une obligation stricte évoluent rapidement, tandis que ceux qui ne sont que recommandés stagnent.
Délai de journalisation Certificate Transparency : questions fréquentes
Qu'est-ce que le délai de journalisation Certificate Transparency ?
L'écart entre le début de validité déclaré d'un certificat TLS (NotBefore) et le moment où il apparaît réellement dans un registre public CT. Un écart court signifie que la piste d'audit publique suit le rythme de l'émission. Un écart important indique qu'un certificat valide et utilisable a existé pendant un certain temps sans qu'aucune trace publique n'en subsiste.
Chrome exige-t-il la journalisation de tous les certificats dans CT ?
La politique du Chrome Root Program exige que le certificat final émis, et non seulement le pré-certificat, contienne un enregistrement de registre CT valide pour les certificats émis à compter du 15 juin 2026. Les certificats émis après cette date sans cet enregistrement ne sont pas reconnus par Chrome. La journalisation des pré-certificats était quant à elle déjà obligatoire depuis 2018.
Pourquoi un certificat pouvait-il être valide avant d'être journalisé ?
CT impose de journaliser un pré-certificat avant l'émission du certificat final, et les règles de Maximum Merge Delay (environ 24 heures) encadrent la durée de cette opération. Jusqu'à la politique de Chrome de juin 2026, aucun délai équivalent n'existait pour enregistrer le certificat final lui-même. Il pouvait ainsi être signé, daté et mis en production alors que sa propre entrée dans le registre prenait du retard, parfois de plusieurs mois.
Comment cela a-t-il été mesuré ?
De manière passive. Nous avons analysé l'historique public CT, via crt.sh, d'environ 700 domaines du top 1,000 de Tranco, en comparant le champ NotBefore de chaque certificat à l'horodatage de son entrée dans le registre. Aucun hôte n'a été contacté, résolu ou scanné. Le résultat porte sur 1.29 million d'entrées de registre entre 2013 et la mi-2026, réparties de part et d'autre de l'échéance réglementaire du 15 juin 2026.