Le 22 août 2026, l’infrastructure qui garantit la confiance sur le web change de visage. Deux textes bousculent la manière dont les certificats TLS sont surveillés : la Chrome Root Program Policy v1.8 de Google, appliquée depuis le 15 juin, et la Mozilla Root Store Policy v3.1, entrée en vigueur le 1er juillet. Les deux forcent les autorités de certification à journaliser chaque certificat public dans un log Certificate Transparency (CT), une structure de données bâtie sur un arbre de Merkle. Au même moment, une série de failles a touché neuf composants distincts de l’écosystème CT en 2026, du serveur open source Trillian aux bibliothèques sigstore-js, en passant par un contournement CAA chez Cloudflare et un certificat Azure recyclé chez la plateforme Coder. Plus les logs Merkle deviennent obligatoires, plus ils attirent l’œil des chercheurs en sécurité. Voici ce que ce double mouvement change pour les développeurs, les autorités de certification et les entreprises européennes.

Ce qui change le 15 juin et le 1er juillet 2026

Trois dates encadrent ce basculement. Le 16 avril 2026, DigiCert publie une alerte annonçant qu’à partir du 1er juin, l’autorité journalisera tous les certificats TLS publics qu’elle émet, canaris et certificats de test compris, dans au moins un log CT. La mesure couvre les certificats DV, OV, EV, ainsi que les QWAC européens et QWAC PSD2, sur l’ensemble des marques du groupe : DigiCert, GeoTrust, Thawte, RapidSSL et Encryption Everywhere. Le 15 juin, c’est au tour de Google de resserrer la vis avec la version 1.8 de sa Chrome Root Program Policy, qui exige que tous les précertificats et certificats finaux TLS soient journalisés dans au moins un log CT reconnu. Deux semaines plus tard, le 1er juillet, Mozilla applique sa propre Root Store Policy v3.1, qui relève les standards de gouvernance et de transparence pour toutes les autorités de certification approuvées par Firefox.

Ce n’est pas une simple formalité administrative. Ces trois décisions, prises à quelques semaines d’intervalle, ferment une fenêtre qui existait depuis les débuts de la Certificate Transparency en 2013 : celle des certificats émis sans journalisation systématique, notamment les certificats de test ou les canaris utilisés en interne par certaines autorités. Cette fenêtre servait parfois de zone grise pour des certificats jamais destinés à un usage public. Elle se referme cette année.

L’arbre de Merkle, brique invisible de la confiance sur le web

Un log Certificate Transparency n’est rien d’autre qu’un registre public, cryptographiquement vérifiable, de tous les certificats émis pour un domaine. Sa structure repose sur un arbre de Merkle : chaque nouvelle entrée est hachée, combinée aux hachages précédents, et le résultat produit une racine unique qui résume l’intégralité de l’historique. Modifier une seule entrée passée changerait cette racine, ce qui rend toute falsification détectable. Le projet officiel Certificate Transparency le résume ainsi : « Logs maintain a record of certificates. They use a special cryptographic mechanism, a Merkle tree, to allow public audits » (certificate.transparency.dev).

Le concept remonte à la RFC 6962, publiée en 2013 sous l’impulsion de Google après plusieurs incidents d’émission frauduleuse, dont l’affaire DigiNotar. Le texte fondateur décrit la structure en une phrase devenue une référence dans l’ingénierie PKI : « A log is a single, ever-growing, append-only Merkle Tree of such certificates » (RFC 6962). En 2018, Chrome a commencé à exiger la journalisation CT pour tout nouveau certificat public. Huit ans plus tard, les politiques 2026 de Chrome et Mozilla achèvent ce chantier en éliminant les dernières exceptions.

Chrome Root Program Policy v1.8 : la fin des exceptions

La version 1.8 du Chrome Root Program Policy ne se contente pas de reformuler une exigence existante. Elle étend la couverture CT à des catégories de certificats qui échappaient auparavant à la règle, en particulier certains certificats émis pour des tests internes ou des environnements de préproduction. Une analyse indépendante publiée par un cabinet de conseil en PKI décrit cette mise à jour du 15 juin comme un texte qui renforce les exigences de gouvernance de la Certificate Transparency et du PKI pour tous les types de certificats de confiance publique. Le même document évoque une transition vers une ère de « static CT », où les logs sont repensés pour être plus rapides et moins coûteux à exploiter (Chromium CT Policy Group).

Concrètement, un certificat qui ne présente pas de Signed Certificate Timestamp (SCT) valide, provenant d’un log reconnu par Chrome, déclenche une erreur de confiance dans le navigateur. Pour les autorités de certification, cela signifie zéro tolérance sur la couverture CT, y compris pour les volumes marginaux qu’elles pouvaient auparavant traiter hors journal.

Mozilla Root Store Policy v3.1 : la vérification SCT devient une étape obligatoire

Le texte de Mozilla, entré en vigueur le 1er juillet, ajoute une étape formelle baptisée « Step 3: Certificate Transparency Verification ». Elle impose de confirmer que chaque certificat émis après cette date porte des SCT valides, délivrés par des logs acceptés sous la nouvelle politique. Mozilla recommande des outils comme crt.sh ou le tableau de bord CT propre à chaque autorité pour effectuer cette vérification. Le blog sécurité de Mozilla précise également un jalon à plus long terme : « Beginning with audit periods starting on or after July 1, 2027, CA operators with root certificates enabled for TLS website authentication will be required to obtain a DCR » (Mozilla Security Blog, 29 juin 2026).

Un DCR, ou rapport de conformité daté, ajoute une couche d’audit externe à la simple journalisation CT. Les autorités de certification approuvées par Firefox savent donc déjà qu’une deuxième échéance les attend dans un an, cette fois centrée sur la preuve documentaire plutôt que sur la seule transparence cryptographique.

DateActeurMesure
16 avril 2026DigiCertAnnonce de la journalisation CT universelle pour toutes ses marques
1er juin 2026DigiCertEntrée en vigueur : tous les certificats publics, canaris compris, journalisés
15 juin 2026GoogleChrome Root Program Policy v1.8 : SCT obligatoire, sans exception
1er juillet 2026MozillaRoot Store Policy v3.1 : vérification SCT formalisée (étape 3)
1er juillet 2027MozillaObligation d’un rapport de conformité daté (DCR) pour les opérateurs de CA

Neuf failles en un an : la transparence elle-même sous pression

L’ironie de 2026, c’est que l’infrastructure censée garantir la confiance a elle-même accumulé les vulnérabilités. Entre janvier et août, au moins neuf CVE distinctes ont touché des composants de l’écosystème CT ou des mécanismes qui s’appuient sur lui : le serveur de log Trillian, la bibliothèque sigstore-js, une extension CAA détournable, une bibliothèque GnuTLS encore active, et un cas d’exploitation réelle chez la plateforme de développement Coder. Cette concentration d’incidents sur une infrastructure devenue obligatoire pour l’ensemble du web public mérite qu’on s’y attarde composant par composant.

ComposantCVE / référenceNatureCorrectif
Chainguard certificate-transparencyCVE-2026-32283Épuisement de ressources sans limiteVersion 1.3.3-r10
Trillian CT serverCVE-2026-25679, 26958, 27139, 271424 failles parmi 9 corrigées au totalVersion 1.3.2-r1
Trillian CT server (héritées)CVE-2025-61732, CVE-2025-68121Failles reportées, corrigées avec le lot 2026Version 1.3.2-r1
sigstore-jsCVE-2026-48816Horodatage du log falsifiable (bundle v0.2)Correctif signalé par Red Hat
CAA / ACMECVE-2026-14440Contournement de contrainte CAA (RFC 8657)Non enforcement end-to-end identifié
GnuTLSCVE-2025-32989Lecture heap hors limites sur l’extension SCTSuivi NVD actualisé au 21 août 2026
Coder (plateforme dev)CVE-2026-46354Contournement de signature PKCS#7, CVSS 9,1Analyse Orca Security

Trillian, le moteur open source derrière des dizaines de logs CT

Trillian sert de fondation logicielle à une bonne partie des logs CT publics utilisés par les autorités de certification et les grands fournisseurs cloud. Un bulletin de sécurité daté du 30 juillet 2026, actualisé le 14 août, recense neuf vulnérabilités corrigées dans la version 1.3.2-r1 du serveur, dont quatre CVE fraîchement attribuées (CVE-2026-25679, CVE-2026-26958, CVE-2026-27139 et CVE-2026-27142) et deux failles héritées de 2025. Deux avis de sécurité GitHub complètent la liste. Pour un composant qui traite chaque jour des millions d’insertions dans des arbres de Merkle, neuf correctifs en un seul cycle de version donnent une idée du niveau d’attention que ces logs reçoivent désormais de la part des chercheurs.

Vérifier soi-même les SCT d’un certificat

Pour un développeur qui veut vérifier qu’un certificat de production porte bien un SCT valide avant les contrôles imposés par Mozilla, une simple commande OpenSSL suffit à inspecter l’extension embarquée dans le certificat.

openssl s_client -connect exemple.fr:443 -servername exemple.fr -showcerts 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -A2 "CT Precertificate SCTs"

La sortie liste les logs ayant signé le certificat, avec l’horodatage de chaque signature. En complément, l’outil crt.sh recommandé par Mozilla permet de croiser ces informations avec l’historique public du domaine et de repérer un certificat émis à l’insu de son propriétaire légitime.

sigstore-js : quand l’horodatage du log peut être manipulé

Le cas sigstore-js illustre un risque différent : celui où la logique de vérification, plutôt que le log lui-même, se trompe. Une fiche de sécurité Red Hat détaille la CVE-2026-48816, publiée le 1er juillet et actualisée le 16 août. Le problème vient de la manière dont sigstore-js dérive l’horodatage d’une entrée de log de transparence à partir du champ tlogEntries[].integratedTime, pour ensuite valider la fenêtre de validité d’un certificat et satisfaire un seuil temporel appelé timestampThreshold. Pour les bundles en version 0.2, une entrée peut ne contenir qu’une preuve d’inclusion, sans lier cryptographiquement cet horodatage. Un attaquant qui fournit un bundle non vérifié peut donc choisir arbitrairement l’horodatage et influencer la décision de validation temporelle.

Sigstore alimente une bonne partie des chaînes de signature utilisées dans la sécurité de la supply chain logicielle, notamment via Cosign et les workflows de release GitHub. Une faille sur l’horodatage du log de transparence touche donc, indirectement, la crédibilité de signatures censées prouver qu’un artefact logiciel n’a pas été altéré après sa publication.

CAA détourné : les limites d’une détection a posteriori

La CVE-2026-14440, publiée le 1er juillet et mise à jour le 25 juillet, rappelle une limite structurelle de la Certificate Transparency : elle détecte les émissions frauduleuses, elle ne les empêche pas. La faille permet à un attaquant qui contrôle un compte ACME référencé dans l’enregistrement CAA d’un domaine d’obtenir un certificat de confiance publique, dès lors qu’il parvient à satisfaire la validation de contrôle du domaine, malgré les contraintes prévues par la RFC 8657. Autrement dit, l’enregistrement CAA censé restreindre les autorités autorisées à émettre pour un domaine peut être vidé de son sens si la chaîne de validation n’applique pas ces contraintes de bout en bout.

Le cas particulier de Cloudflare Universal SSL

Une analyse de vulnérabilité, actualisée le 21 juillet 2026, souligne que le jeu d’enregistrements CAA géré automatiquement par le DNS autoritaire de Cloudflare Universal SSL peut se substituer aux enregistrements CAA configurés par le client. Les contraintes accounturi et validationmethods prévues par la RFC 8657 deviennent alors invisibles pour l’autorité de certification, donc non préservées de bout en bout. Le document insiste sur un point souvent mal compris par les équipes sécurité : la surveillance CT sert à détecter une émission abusive, elle ne remplace jamais l’application préventive des contraintes CAA.

Deux incidents qui montrent les usages détournés des logs CT

La CVE-2025-32989 touche GnuTLS et illustre la durée de vie longue de certaines failles PKI. NVD la date du 10 juillet 2025, mais l’entrée a encore été mise à jour le 21 août 2026, soit la veille de la rédaction de cet article. Le défaut provoque une lecture heap hors limites lors de l’analyse de l’extension SCT (identifiant OID 1.3.6.1.4.1.11129.2.4.2) d’un certificat X.509. Un certificat conçu avec une extension SCT malformée peut donc, en théorie, exposer des données sensibles au moment de son analyse par une bibliothèque vulnérable.

Le second cas va plus loin dans la démonstration d’un usage détourné. Un billet publié par Orca Security le 21 mai 2026, actualisé le 22 août, détaille la CVE-2026-46354, une faille critique (score CVSS 9,1) dans Coder, une plateforme open source de développement à distance. L’attaque consiste à forger une enveloppe PKCS#7 associant un certificat Azure IMDS légitime, publiquement disponible via les logs Certificate Transparency, à un contenu contrôlé par l’attaquant. Envoyée vers un point d’entrée non authentifié de Coder, cette enveloppe trompe la plateforme et lui fait délivrer un jeton de session valide, ouvrant l’accès à des clés SSH Git et des identifiants OAuth. L’épisode montre qu’un certificat parfaitement légitime, retrouvé justement parce qu’il est journalisé publiquement, peut devenir une brique d’attaque entre des mains habiles.

RSA reprend l’avantage sur ECDSA : ce que révèlent 8,7 milliards de certificats

Les logs CT ne servent pas seulement à traquer les abus. Journalisant l’écrasante majorité des certificats TLS publics, ils forment aussi le plus grand corpus statistique disponible sur les choix cryptographiques réels du web. Une analyse publiée en mars 2026, portant sur 8,7 milliards de certificats extraits de ces logs, montre qu’en juillet 2026 la répartition entre algorithmes de clé s’est inversée par rapport aux années précédentes : RSA représente 50,30 % des certificats actifs contre 49,70 % pour ECDSA, un écart de 0,6 point qui redonne la tête à RSA après plusieurs années de progression d’ECDSA.

Cette bascule coïncide avec la montée des exigences de conformité européennes sur la longueur des clés RSA, portées par l’ANSSI et l’ENISA, qui poussent certaines organisations vers des configurations RSA plus robustes plutôt que vers une migration ECDSA jugée plus complexe à opérer à grande échelle. Elle rappelle aussi que la transition vers la cryptographie post-quantique, elle-même bâtie sur des schémas de signature à base de hachage proches dans l’esprit des arbres de Merkle utilisés par CT, s’ajoute à une équation déjà partagée entre RSA et ECDSA plutôt que de la remplacer d’un coup.

Ce que 2026 change pour les entreprises et développeurs européens

Pour une entreprise française ou européenne qui gère ses propres certificats, ce calendrier a des conséquences concrètes. Un certificat qui échoue à présenter un SCT valide après le 15 juin déclenche une alerte de confiance dans Chrome, ce qui peut bloquer l’accès à un site ou une API pour une partie du trafic. Les équipes qui exploitent des certificats internes générés par des outils comme Let’s Encrypt, Certbot ou une autorité privée doivent vérifier que leur chaîne de délivrance journalise bien chaque émission, y compris pour les environnements de test exposés publiquement.

Le contexte réglementaire européen amplifie l’enjeu. Le Cyber Resilience Act impose déjà un suivi de la chaîne d’approvisionnement logicielle, et NIS2 étend les obligations de gestion des risques cyber à des milliers d’entités supplémentaires. Une infrastructure PKI mal surveillée, incapable de démontrer qu’un certificat suspect a été détecté via CT, devient un point faible facile à identifier lors d’un audit de conformité. À l’inverse, les équipes qui surveillent activement les logs CT de leurs propres domaines, via crt.sh ou un service équivalent, gagnent une longueur d’avance pour repérer une émission frauduleuse avant qu’elle ne serve à une attaque de phishing ou d’usurpation de domaine.

Ce qu’en disent les textes de référence

Faute de porte-parole individuel sur ce dossier très technique, les textes de référence eux-mêmes tracent la trajectoire de ce chantier de dix ans. Le projet Certificate Transparency rappelle le principe fondateur : « Logs maintain a record of certificates. They use a special cryptographic mechanism, a Merkle tree, to allow public audits » (Certificate Transparency, documentation officielle).

La RFC 6962, texte fondateur de 2013, formalise la structure technique en une phrase toujours citée : « A log is a single, ever-growing, append-only Merkle Tree of such certificates » (RFC 6962).

Sur l’évolution en cours vers une intégration plus profonde de la transparence dans le processus même d’émission, une discussion publique du groupe de politique CT de Chromium note que « Merkle Tree Certificates integrates CT into the certificate issuance process, rather than bolting it on after the fact » (Chromium CT Policy Group).

Sur les exigences imposées aux logs eux-mêmes, la politique CT de Mozilla précise que « Admissible logs MUST include all NSS roots that have the websites trust bit enabled, and log operators MUST maintain reliable uptime, timely merging, and compliance with CT operational requirements » (Mozilla CT Log Policy).

Et sur le jalon 2027 qui suivra celui de 2026, le blog sécurité de Mozilla est explicite : « Beginning with audit periods starting on or after July 1, 2027, CA operators with root certificates enabled for TLS website authentication will be required to obtain a DCR » (Mozilla Security Blog).

Cinq prédictions pour la suite

  • Le static CT deviendra la norme d’ici fin 2027. Les logs redessinés pour être moins coûteux à exploiter, déjà évoqués par le Chromium CT Policy Group, remplaceront progressivement l’architecture historique de RFC 6962 sur les logs les plus fréquentés.
  • D’autres CVE viseront Trillian et ses dérivés. Un composant qui vient de recevoir neuf correctifs en un seul cycle attire mécaniquement l’attention des chercheurs qui savent qu’un audit récent laisse parfois passer des variantes proches.
  • Safari suivra Chrome et Firefox sur l’obligation SCT stricte. Apple a historiquement aligné ses exigences CT sur celles de Chrome avec un décalage de plusieurs mois, un scénario probable d’ici la fin 2026 ou début 2027.
  • La supply chain logicielle empruntera davantage aux logs de type Merkle. Après la faille sigstore-js, les projets de signature d’artefacts renforceront la liaison cryptographique entre horodatage et preuve d’inclusion plutôt que de se contenter d’un horodatage déclaratif.
  • Le rapport RSA/ECDSA continuera d’osciller sous l’effet des politiques européennes. Tant que l’ANSSI et l’ENISA n’auront pas tranché définitivement sur les tailles de clé recommandées, les logs CT continueront d’enregistrer un partage quasi égal entre les deux familles d’algorithmes.

Questions fréquentes

Qu’est-ce qu’un Merkle tree dans le contexte de la Certificate Transparency ?

C’est une structure de données où chaque certificat journalisé est haché puis combiné aux hachages précédents pour produire une racine unique. Toute modification d’une entrée ancienne changerait cette racine, ce qui rend la falsification détectable par quiconque vérifie le log.

Pourquoi Chrome et Mozilla imposent-ils la CT en 2026 alors que le concept date de 2013 ?

Parce que des exceptions subsistaient, notamment pour des certificats de test ou des canaris internes émis par certaines autorités. Les politiques 2026 ferment ces dernières marges, en particulier via la Chrome Root Program Policy v1.8 et la Mozilla Root Store Policy v3.1.

Un certificat sans SCT valide bloque-t-il vraiment l’accès à un site ?

Oui, dans Chrome et dans Firefox après application des nouvelles politiques, un certificat sans preuve de journalisation CT reconnue déclenche une erreur de confiance qui empêche la navigation normale vers le site concerné.

La Certificate Transparency empêche-t-elle l’émission de faux certificats ?

Non. Comme le montre la CVE-2026-14440 sur le contournement CAA, la CT détecte une émission frauduleuse après coup, elle ne l’empêche pas en amont. La prévention repose sur d’autres contrôles, notamment l’application stricte des contraintes CAA définies par la RFC 8657.

Qu’est-ce qu’un DCR imposé par Mozilla à partir de juillet 2027 ?

Un rapport de conformité daté, une preuve d’audit externe que les opérateurs d’autorités de certification devront fournir en complément de la journalisation CT classique, pour tout certificat racine habilité à l’authentification de sites web TLS.

Comment un développeur peut-il vérifier la couverture CT de son propre domaine ?

Via l’outil crt.sh, recommandé par Mozilla, ou par une commande OpenSSL qui extrait l’extension SCT du certificat servi en production, comme illustré plus haut dans cet article.

La faille sigstore-js remet-elle en cause la sécurité de la supply chain logicielle en général ?

Elle affaiblit un mécanisme précis, la validation temporelle basée sur l’horodatage du log de transparence, sans invalider l’ensemble de l’architecture sigstore. Red Hat a documenté le problème sur les bundles en version 0.2 et recommande une mise à jour des bibliothèques concernées.

RSA est-il redevenu plus utilisé qu’ECDSA sur l’ensemble du web en 2026 ?

Selon une analyse portant sur 8,7 milliards de certificats journalisés dans les logs CT, RSA représentait 50,30 % des certificats actifs en juillet 2026 contre 49,70 % pour ECDSA, un écart faible mais qui marque un renversement après plusieurs années de progression d’ECDSA.