Certificate Transparency

Certificate Transparency est un cadre ouvert composé de journaux, de moniteurs et d'auditeurs qui rend quasi impossible l'émission d'un certificat par une autorité de certification à l'insu du propriétaire du domaine. Il s'agit de l'un des mécanismes de responsabilité les plus importants de la PKI moderne.

Vue d'ensemble

En 2011, une autorité de certification néerlandaise nommée DigiNotar a été compromise. Les attaquants ont émis des certificats frauduleux pour des domaines majeurs, dont *.google.com, et s'en sont servis pour intercepter les communications de centaines de milliers de personnes. La compromission est restée indétectée pendant des semaines, faute d'un registre public et auditable indiquant quels certificats avaient été émis, et par qui.

L'incident DigiNotar (ainsi que d'autres événements similaires impliquant Comodo et d'autres CA) a révélé une faiblesse fondamentale de l'écosystème PKI : le modèle de confiance supposait que chaque CA se comporterait correctement en permanence, mais n'offrait aucun mécanisme pour vérifier cette hypothèse. Les propriétaires de domaines n'avaient aucun moyen pratique de savoir si une CA malveillante ou compromise avait émis un certificat pour leur domaine.

Certificate Transparency (CT) a été créé par les ingénieurs de Google Ben Laurie et Adam Langley pour résoudre ce problème. Défini dans la RFC 6962 (puis mis à jour par la RFC 9162), CT introduit un système de journaux publiquement auditables et en ajout seul qui enregistrent chaque certificat émis par une CA participante. L'idée est simple mais puissante : si chaque certificat doit être journalisé avant d'être approuvé, alors toute émission frauduleuse ou erronée devient visible pour quiconque souhaite la chercher.

Étapes clés

Serveurs de journaux

Lorsqu'une CA émet un certificat, elle soumet ce certificat (ou un précertificat) à un ou plusieurs serveurs de journaux CT. Ces journaux fonctionnent en ajout seul, ce qui signifie que des entrées peuvent y être ajoutées mais jamais modifiées ni supprimées. Le serveur de journal renvoie un Signed Certificate Timestamp (SCT), c'est-à-dire une promesse cryptographique que le certificat apparaîtra dans le journal dans un délai défini (le Maximum Merge Delay, généralement 24 heures).

Moniteurs

Les moniteurs sont des services qui surveillent les journaux CT à la recherche de nouvelles entrées. Les propriétaires de domaines (ou les équipes de sécurité qui agissent en leur nom) utilisent des moniteurs pour détecter les certificats émis pour leurs domaines. Si un certificat apparaît sans que le propriétaire du domaine ne l'ait demandé, c'est un signal fort de compromission ou d'émission erronée de la CA. Des services comme la recherche Certificate Transparency de Google, crt.sh et les plateformes CLM commerciales jouent tous le rôle de moniteurs.

Auditeurs

Les auditeurs vérifient l'intégrité des journaux eux-mêmes. Ils contrôlent que les journaux se comportent correctement : que les entrées ne sont pas supprimées, que la structure de l'arbre de Merkle est cohérente, et que les SCT correspondent à de réelles entrées de journal. Les navigateurs peuvent agir comme auditeurs en vérifiant que les SCT présentés correspondent aux enregistrements des journaux.

Composants clés

Google Chrome

Chrome a été le premier navigateur à exiger CT et applique la politique la plus stricte. Depuis avril 2018, tous les certificats nouvellement émis et publiquement approuvés doivent être accompagnés de SCT provenant d'au moins deux journaux CT indépendants. Les certificats sans SCT valides sont considérés comme non approuvés et déclenchent un avertissement plein écran.

Apple Safari

Apple exige la conformité CT pour tous les certificats TLS émis après le 15 octobre 2018. Safari requiert des SCT provenant d'au moins deux journaux, et l'un de ces journaux doit avoir été dans un état « qualifié » au moment de l'émission du certificat. Apple maintient sa propre liste de journaux CT approuvés.

Mozilla Firefox

Firefox n'a historiquement pas appliqué les exigences CT au niveau du navigateur, s'appuyant plutôt sur la conformité volontaire des CA. Cependant, Mozilla a signalé un intérêt croissant pour l'application de CT à travers les politiques de son programme racine, et une application pratique est attendue dans la lignée de Chrome et d'Apple.

Méthodes de transmission des SCT

Les SCT peuvent être transmis aux navigateurs de trois manières : intégrés directement dans le certificat (l'approche la plus courante), via une extension TLS pendant la poignée de main, ou via l'agrafage OCSP. Chaque méthode présente des compromis en matière de complexité de déploiement et de configuration serveur.

Evertrust & Certificate Transparency

Surveillance des journaux CT — Evertrust CLM intègre les données des journaux Certificate Transparency pour détecter les certificats émis pour vos domaines, que vous les ayez demandés ou non. Vous bénéficiez ainsi d'une visibilité immédiate sur toute émission non autorisée ou inattendue.

Inventaire complet — Les données CT sont combinées au scan réseau et à la découverte par connecteurs pour constituer un inventaire unifié couvrant à la fois les certificats publics et privés. Aucun angle mort, aucun certificat fantôme caché hors de votre champ de vision.

Alertes sur les anomalies — Lorsqu'un certificat apparaît dans les journaux CT pour l'un de vos domaines sans correspondre à votre inventaire connu, Evertrust déclenche une alerte afin que votre équipe de sécurité puisse enquêter et réagir avant qu'un dommage ne survienne.

Application des politiques — Evertrust vous aide à définir et à appliquer des politiques garantissant que tous les certificats publics sont conformes à CT, réduisant ainsi le risque d'échecs de confiance navigateur sur l'ensemble de votre infrastructure.

PKI

CLM

Cas d'usage

Secteurs

Conformité

Apprendre

Outils & Analyses

Événements & Communauté