Certificate Transparency côté développeur : SCT et alertes

En bref. Certificate Transparency (CT, RFC 6962) impose aux AC de soumettre chaque certificat TLS de confiance publique à des journaux publics en ajout seul (append-only). Chaque journal renvoie une promesse signée d’inclure le certificat, le SCT, et l’AC intègre les SCT dans le certificat. Chrome, Safari et Firefox rejettent les certificats de confiance publique qui ne portent pas assez de SCT issus d’assez de journaux indépendants. Pour vous, cela a deux conséquences. N’importe qui peut voir tous les certificats émis pour vos domaines, via Cert Spotter, crt.sh ou votre propre moniteur. Et vous devriez surveiller ces journaux, car un certificat que vous n’avez pas demandé est le signe le plus précoce d’une prise de contrôle DNS, d’un compte compromis ou d’une AC défaillante.

Comment fonctionne CT

Un journal CT est un arbre de Merkle, la même structure de hachage en ajout seul qu’utilisent Git et Bitcoin. N’importe qui peut le télécharger, vérifier qu’aucune entrée n’est jamais supprimée ni modifiée, et obtenir une preuve courte qu’un certificat donné y figure. Avec CT, l’émission se déroule ainsi :

1. L’AC construit un précertificat : le contenu du certificat final, plus une extension critique « poison » (OID 1.3.6.1.4.1.11129.2.4.3), qui empêche de l’utiliser comme un vrai certificat.
2. Elle soumet le précertificat à plusieurs journaux. Chaque journal renvoie un Signed Certificate Timestamp (SCT) : une signature portant sur l’entrée et un horodatage, qui promet l’inclusion dans le délai maximal d’intégration du journal (Maximum Merge Delay, MMD).
3. L’AC émet le certificat final avec les SCT intégrés dans une extension X.509 (OID 1.3.6.1.4.1.11129.2.4.2).
4. Les navigateurs vérifient les signatures des SCT à l’aide de leur liste de journaux de confiance et les décomptent selon leur politique.
5. Les moniteurs lisent les journaux et signalent les certificats émis pour les noms qu’ils surveillent. Les auditeurs vérifient que les journaux restent cohérents et tiennent leurs promesses.

Dans la plupart des cas, le précertificat et le certificat final sont tous deux journalisés, c’est pourquoi les outils de recherche affichent souvent chaque certificat deux fois.

Les SCT d’un vrai certificat

openssl x509 -text décode les SCT intégrés. Voici le certificat que servait letsencrypt.org le 20 octobre 2026 :

subject=CN=letsencrypt.org
issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:
                                B0:F8:FC:5E:87:55:26:0F:15:D1:2E:72:BB:45:4B:14
                    Timestamp : Sep  4 15:33:02.377 2026 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:D0:2E:25:A4:9D:7F:C8:18:D6:7B:5E:...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 46:AF:86:3D:3B:3E:E5:9F:A5:77:DE:A8:24:5D:36:B0:
                                D9:ED:22:A2:23:F4:61:77:41:22:94:52:EE:95:50:5F
                    Timestamp : Sep  4 15:33:02.552 2026 GMT
                    Extensions: 00:00:05:00:24:DF:DB:0C
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:31:2F:83:D6:42:65:26:0D:58:D7:DD:C3:...

L’ID de journal est le condensat SHA-256 de la clé publique du journal. La recherche des deux ID dans la liste de journaux de Chrome (log_list.json, version du 19 octobre 2026) donne :

Deux journaux de deux opérateurs différents, le minimum pour un certificat de 90 jours. L’extension du second SCT n’est pas du bruit. Les journaux conformes à static-ct-api placent dans le SCT la position de l’entrée dans le journal : type d’extension 0 (leaf_index), longueur 5, et un index de 40 bits, ici 618 650 380. Un moniteur peut récupérer cette entrée directement au lieu de la chercher.

Le décodeur de SCT fait cette recherche pour vous. Il affiche le nom de chaque journal, son état dans les listes de Chrome et d’Apple, et indique si l’ensemble satisfait la politique de chaque navigateur. Le décodeur de certificats affiche l’extension SCT avec le reste du certificat.

Les SCT peuvent parvenir au navigateur de trois façons :

• Intégrés au certificat, comme ci-dessus. C’est ce que font presque toutes les AC, et cela ne vous demande rien.
• Dans l’extension TLS signed_certificate_timestamp. Le serveur envoie des SCT qu’il a obtenus lui-même. Peu de serveurs la prennent en charge.
• Dans une réponse OCSP agrafée. Chrome ne les acceptait que « dans les versions antérieures à la version 148 », et comme Let’s Encrypt et d’autres abandonnent OCSP, cette voie disparaît peu à peu (voir OCSP et CRL en 2026).

Ce qu’exigent les navigateurs

Les trois grands moteurs imposent CT aux certificats émis par les AC de leurs programmes publics de certificats racines.

Sources : la politique CT de Chrome, la politique CT d’Apple (avril 2025) et la page CT de Mozilla. Selon MDN, Firefox impose CT sur ordinateur depuis la version 135 (février 2025) et sur Android depuis la version 145 (novembre 2025). La préférence security.pki.certificate_transparency.mode indique le mode : 2 signifie que CT est imposé.

Deux conséquences pratiques :

• Les navigateurs cessent d’imposer CT si leur liste de journaux est trop ancienne. Chrome n’impose CT que tant que sa liste de journaux la plus récente date de moins de 70 jours, et la liste de Firefox expire au bout de 10 semaines. Une machine qui n’a pas été mise à jour depuis des mois n’impose pas du tout CT : ne l’utilisez donc pas pour tester des échecs CT.
• Les AC privées sont exemptées. Selon les notes de Chrome pour les entreprises, CT « ne s’applique qu’aux AC de confiance publique ». Les certificats issus d’une racine que vous avez installée vous-même n’ont besoin d’aucun SCT, et les journaux ne les accepteraient de toute façon pas.

Les journaux eux-mêmes

La liste de journaux de Chrome du 19 octobre 2026 compte 21 journaux RFC 6962 utilisables, plus 2 en lecture seule et 3 retirés. Elle recense aussi 22 journaux static-ct-api utilisables et 37 qualifiés. Onze opérateurs exploitent des journaux utilisables ou qualifiés : Cloudflare, DigiCert, Geomys, GoDaddy, Google, HARICA, IPng Networks, Let’s Encrypt, Microsec, Sectigo et TrustAsia. Les journaux sont partitionnés par période. Un journal nommé 2026h2 n’accepte que les certificats qui expirent au second semestre 2026 : la taille de chaque journal reste ainsi bornée, et il peut être retiré une fois ses certificats expirés.

Les deux types de journaux acceptent les soumissions via les mêmes points de terminaison RFC 6962 (add-chain, add-pre-chain). Ils diffèrent par la façon dont les moniteurs les lisent. Un journal RFC 6962 répond à des appels d’API dynamiques :

{"tree_size":2980148930,"timestamp":1792499093002,"sha256_root_hash":"wr3F5apMl2E7wQHqbAA1yKsqaZbAzBXTT8WTAeRAy8M=","tree_head_signature":"BAMARzBFAiEAsC3Pr7fsPwy0vchrMDIXka7HxrZANu5tcXclDCUqqSYCIGJ64SaIT0tjM5hCGfycNGPfu6FP8q8RvW14Q4SoyvVU"}

Cela représente près de trois milliards d’entrées dans une seule partition semestrielle. Un journal static-ct-api, dit « en tuiles » (tiled), publie sa tête d’arbre signée sous forme de checkpoint en texte brut, et ses entrées sous forme de tuiles immuables de 256 entrées que les CDN peuvent mettre en cache :

tuscolo2026h2.sunlight.geomys.org
1007870339
aRhh7dPjYarH0itUM1LD+XJw7CW41z1+9tSnf3AizuY=

— tuscolo2026h2.sunlight.geomys.org W+DWDWi4dqCfFx8da0IS4+jwHKVL6ETEHGQCHn5y8rKflUhLRtLHQ3c6...
— grease.invalid Aui1jDc8Y7Uve7seHd/Pg1p+wHSUmw0+MTNyEKEAAbHaE5bY3Gi/MUZ3zBuk+NxUyhJL...
— tuscolo2026h2.sunlight.geomys.org 7BiSLwAAAaFZRnbMBAMARzBFAiA++3wWdtsK2H8l3IxZh6H/OQml...

Les premières lignes sont l’origine, la taille de l’arbre et le condensat racine. Les lignes qui commencent par « — » sont des signatures. Notez que l’URL de surveillance (skylight) diffère de l’URL de soumission (sunlight). Les deux figurent dans la liste de journaux.

Trouver vos certificats

Deux services publics de recherche couvrent pratiquement tous les journaux.

API Cert Spotter (SSLMate). Le point de terminaison issuances liste les certificats non expirés d’un domaine. Il fonctionne sans clé pour un nombre limité de requêtes par heure. Pour un usage en production, SSLMate vous demande de vous inscrire pour obtenir une clé. Voici les certificats émis pour ecdsa.com :

curl -s "https://api.certspotter.com/v1/issuances?domain=ecdsa.com&include_subdomains=true&expand=dns_names&expand=issuer"

{
  "id": "16609031524",
  "tbs_sha256": "8c6f1f0bef5434da2012d5f29eab13f00bcec659f17832c07872ff600f61ecf5",
  "cert_sha256": "1396447e3454a081fe4e48dc1d5de18b7e3cf857ec1d7ff3c987d091c9024b04",
  "dns_names": [
    "ecdsa.com"
  ],
  "pubkey_sha256": "9a1fa381dad4630b83cf3a1a1a7a3da7f04577db8a41933dd9bac49dabfa8c29",
  "issuer": {
    "friendly_name": "Let's Encrypt",
    "pubkey_sha256": "2e8307068b6db620e4a39d068b5dee5d6ef5788cbb2c0b6d23ead84fcc17178c",
    "name": "C=US, O=Let's Encrypt, CN=YR1"
  },
  "not_before": "2026-08-19T14:52:58Z",
  "not_after": "2026-11-17T14:52:57Z",
  "revoked": false
}

En résumé, la réponse contenait cinq émissions :

16609031524 2026-08-19 2026-11-17 Let's Encrypt ecdsa.com
16609045002 2026-08-19 2026-11-17 Let's Encrypt ecdsa.com,www.ecdsa.com
17525925247 2026-10-01 2026-12-30 Let's Encrypt *.ecdsa.com,ecdsa.com
17875915585 2026-10-19 2027-01-17 Let's Encrypt ecdsa.com,www.ecdsa.com
17878726033 2026-10-20 2027-01-18 Let's Encrypt ecdsa.com

Les résultats arrivent dans l’ordre où SSLMate les a découverts. Pour paginer, passez le dernier id en paramètre after=. Un tableau vide est accompagné d’un en-tête Retry-After, ce qui permet d’utiliser le point de terminaison comme un flux à interroger périodiquement. Notez ce que permet le champ pubkey_sha256. En le comparant aux clés de vos serveurs, vous savez quels certificats sont réellement déployés et lesquels ont été émis sans jamais servir.

crt.sh (Sectigo) propose une interface web et une sortie JSON (https://crt.sh/?q=example.com&output=json). Il est gratuit et couvre un historique très long, certificats expirés compris. C’est aussi un service partagé très sollicité. Nos quatre requêtes JSON du 20 octobre 2026 ont toutes renvoyé 502 Bad Gateway. Considérez-le comme un service d’appoint, pas comme une dépendance de votre surveillance.

L’outil d’historique CT montre les certificats d’un domaine au fil du temps, avec l’émetteur, la validité et les noms de chacun.

Surveiller vos domaines

La recherche répond à la question « qu’est-ce qui existe ? ». La surveillance répond à « qu’est-ce qui est nouveau ? » et vous alerte dans les minutes ou les heures qui suivent l’émission. Les options :

• Un moniteur hébergé. Le service Cert Spotter hébergé par SSLMate et les tableaux de bord de plusieurs AC envoient un e-mail ou un webhook pour chaque nouveau certificat émis sur vos domaines.
• Le certspotter open source (v0.25.0, septembre 2026) lit lui-même les journaux. Vous indiquez les noms dans ~/.certspotter/watchlist (un point initial couvre tous les sous-domaines, par exemple .example.com), et il vous envoie un e-mail ou exécute les scripts de ~/.certspotter/hooks.d à chaque correspondance. Depuis la v0.24, il fournit aussi certspotter-authorize, qui marque les certificats attendus afin que seuls les certificats inattendus déclenchent une alerte.
• L’API de recherche comme flux. Interrogez régulièrement le point de terminaison issuances de Cert Spotter avec after= et comparez chaque nouveau certificat avec ce que votre automatisation a émis.

Ce qui doit déclencher une alerte :

1. Un émetteur que vous n’utilisez pas. Comparez avec vos enregistrements CAA. Un certificat émis par une AC que votre CAA interdit constitue un incident de l’AC et doit être signalé à cette AC.
2. Des noms que vous ne reconnaissez pas, en particulier des sous-domaines oubliés. Un certificat pour old-campaign.example.com peut signifier qu’un enregistrement DNS orphelin a été détourné.
3. Une clé publique que vous n’avez pas générée pour un nom que gère votre automatisation.
4. Des certificats wildcard si votre politique n’en utilise pas.

Avec les certificats de 47 jours, les émissions légitimes deviennent fréquentes. Sans certspotter-authorize ni comparaison avec l’historique de votre client ACME, la fatigue des alertes vous fera ignorer le seul certificat qui compte.

CT et noms privés

Tout le contenu d’un certificat de confiance publique est publié : chaque nom de la liste SAN, pour toujours. Des noms d’hôtes internes comme jenkins.corp.example.com ou staging-payments.example.com deviennent publics dès que vous obtenez un certificat public pour eux, et quiconque lit les journaux les voit, y compris ceux qui recherchent des cibles. Les options, tirées des notes de Chrome pour les entreprises et de la pratique courante :

• Utilisez une AC privée pour les noms internes. CT ne s’applique pas, et rien n’est publié.
• Utilisez un certificat wildcard (*.corp.example.com) quand un certificat public est inévitable. Il révèle la zone, mais pas chaque hôte.
• Ne comptez pas sur une demande faite à une AC publique de ne pas journaliser le certificat. Il serait alors rejeté par tous les navigateurs qui imposent CT.

Erreurs courantes

• Croire qu’un SCT prouve l’inclusion. Un SCT est une promesse d’inclure l’entrée dans le délai MMD. Les auditeurs et les moniteurs vérifient que les journaux la tiennent.
• Compter les doublons. Les entrées du précertificat et du certificat d’une même émission apparaissent sur deux lignes dans la plupart des outils de recherche. Elles partagent l’émetteur et le numéro de série : dédoublonnez donc sur cette paire avant de compter les certificats.
• Chercher des informations de révocation dans CT. Un certificat révoqué reste à jamais dans le journal. La révocation est un système distinct.
• Tester l’application de CT avec un ancien navigateur. L’application de CT se désactive d’elle-même quand la liste de journaux du navigateur est périmée.
• Surveiller via un seul service gratuit. crt.sh connaît des pannes. Utilisez une deuxième source ou votre propre moniteur.

Sources

• RFC 6962 : Certificate Transparency (précertificats, SCT, API des journaux). La RFC 9162 définit CT 2.0, que les navigateurs n’utilisent pas.
• static-ct-api : l’API de lecture des journaux en tuiles et l’extension leaf_index.
• Politique CT de Chrome, liste de journaux de Chrome, CT pour les entreprises.
• Politique Certificate Transparency d’Apple et liste de journaux.
• MDN : Certificate Transparency, la page Certificate Transparency de Mozilla et les notes de version de Firefox 135.
• SSLMate, API Cert Spotter et certspotter sur GitHub.

Les sorties de commandes ont été produites le 20 octobre 2026 avec OpenSSL 3.5.7 et curl 8.14.1 dans node:24.22.0-trixie.