La Certificate Transparency expliquée : ce que sont les logs CT et pourquoi ils comptent

La Certificate Transparency (CT) est un système de journalisation public et infalsifiable qui enregistre chaque certificat TLS de confiance publique au moment de son émission. Ainsi, n'importe qui, vous compris, peut vérifier si un certificat a été créé pour votre domaine à votre insu. Elle n'empêche pas une autorité de certification (CA) malveillante ou compromise d'émettre un certificat frauduleux, mais elle rend cette émission abusive visible presque immédiatement, au lieu de la laisser cachée pendant des mois.

Si vous n'avez jamais consulté les logs CT pour vos propres domaines, vous comptez entièrement sur votre CA pour se comporter correctement et ne jamais être piratée. CT vous offre un moyen indépendant de le vérifier.

Qu'est-ce que la Certificate Transparency, exactement ?

CT a d'abord été définie dans la RFC 6962 (2013), puis formalisée en tant que standard IETF dans la RFC 9162 (Certificate Transparency Version 2.0, 2021). Le principe de base : les CA soumettent chaque certificat, ou une version « précertificat » de celui-ci, à un ou plusieurs logs CT exploités de manière indépendante, avant ou au moment de l'émission.

Chaque log est un arbre de Merkle en ajout seul (append-only) et vérifiable cryptographiquement. Une fois une entrée ajoutée, elle ne peut être ni modifiée ni supprimée discrètement sans casser la preuve mathématique de l'arbre, et quiconque exploite un moniteur peut détecter cette falsification. C'est ce qui rend les logs CT dignes de confiance, alors même que n'importe qui peut y soumettre des certificats et que les opérateurs de logs ne sont pas eux-mêmes des CA.

Trois rôles font fonctionner le système :

• Les logs : des serveurs qui acceptent les soumissions et renvoient une preuve d'inclusion.
• Les moniteurs : des services (ou des scripts) qui surveillent les logs à la recherche de certificats correspondant aux domaines qui les intéressent.
• Les auditeurs : des clients (souvent intégrés aux navigateurs) qui vérifient que l'arbre de Merkle d'un log est cohérent en interne et n'a pas été altéré.

Qu'est-ce qu'un SCT et pourquoi est-ce important ?

Lorsqu'un log accepte un certificat, il renvoie un Signed Certificate Timestamp (SCT) : une promesse cryptographique que le certificat apparaîtra dans le log dans un délai maximal d'intégration (Maximum Merge Delay, MMD) défini, historiquement d'environ 24 heures. Le SCT peut être fourni de trois façons : intégré directement dans le certificat final, envoyé via une extension TLS pendant le handshake, ou agrafé via OCSP (stapling).

Les navigateurs modernes exigent un nombre minimal de SCT valides, provenant de logs gérés par des opérateurs différents et indépendants, avant de faire confiance à un certificat émis publiquement. Chrome impose la conformité CT à tous les certificats de confiance publique émis depuis le 30 avril 2018 : un certificat sans SCT conformes ne sera tout simplement pas reconnu, quel que soit son signataire.

NoteCT ne remplace pas la chaîne de confiance des certificats : elle la complète. Pour un rappel sur le fonctionnement réel de cette chaîne, consultez Les certificats SSL expliqués.

À quoi servent concrètement les logs CT

Pour quiconque gère une infrastructure, l'intérêt pratique ne réside pas dans la cryptographie, mais dans la visibilité. Les logs CT vous permettent de :

• Repérer des certificats non autorisés émis pour votre domaine ou vos sous-domaines par une CA que vous n'avez jamais utilisée.
• Débusquer des sous-domaines fantômes : une recherche CT révèle souvent des noms d'hôtes de préproduction, de test ou internes oubliés, qui ont discrètement reçu un certificat public.
• Auditer le comportement des CA après la divulgation d'un piratage ou d'un incident d'émission abusive, en recherchant dans les logs les certificats concernés liés à vos domaines.
• Détecter l'usage abusif de wildcards, lorsqu'un certificat wildcard pour votre domaine provient d'une source que vous ne reconnaissez pas.

C'est d'autant plus important pour les organisations multi-équipes et les agences qui gèrent de nombreux domaines chez différents registrars et clouds, où un développeur peut demander un certificat auprès d'un fournisseur non approuvé sans que personne ne s'en aperçoive.

Comment consulter les logs CT ?

Nul besoin d'exploiter votre propre moniteur de logs pour tirer parti de CT. Quelques options pratiques :

1. Interrogez les agrégateurs publics de logs CT (crt.sh et services similaires) pour votre domaine afin de voir chaque certificat jamais journalisé pour celui-ci.
2. Inspectez directement les SCT d'un certificat en production avec notre outil de vérification SSL : il affiche la chaîne de certificats et leur validité, pour confirmer ce qui est réellement servi en production.
3. Mettez en place une surveillance continue afin d'être alerté dès qu'un nouveau certificat apparaît pour votre domaine, plutôt que de vérifier manuellement de temps en temps.

Voici un exemple simplifié de résultat de recherche dans les logs CT pour un domaine :

Cette troisième ligne est exactement ce que vous cherchez : un certificat que vous n'avez pas demandé, émis par une CA que vous ne reconnaissez pas. Si vous voyez cela pour un domaine que vous contrôlez, révoquez-le et réémettez-en un immédiatement, puis cherchez à comprendre comment le demandeur a réussi à passer la validation de domaine.

TipSi vous gérez des certificats chez plusieurs fournisseurs, associez la consultation des logs CT à une surveillance active des expirations : consultez Gestion des certificats pour suivre les dates de renouvellement et l'état des chaînes depuis un tableau de bord unique, plutôt que depuis la console de chaque fournisseur.

La Certificate Transparency empêche-t-elle l'émission frauduleuse de certificats ?

Non, et c'est le point le plus souvent mal compris. CT est un mécanisme de détection, pas de prévention. Une CA malveillante ou compromise peut toujours émettre un certificat frauduleux ; CT garantit simplement que cette émission devient publiquement visible, généralement en 24 heures environ (le MMD), au lieu de rester cachée indéfiniment. La véritable couche de prévention, ce sont les enregistrements CAA, qui indiquent aux CA lesquelles d'entre elles sont autorisées à émettre des certificats pour votre domaine. Si vous ne les avez pas configurés, c'est un gain plus important et moins coûteux que la seule surveillance CT : consultez le guide des types d'enregistrements DNS pour la syntaxe CAA.

Utilisés ensemble, CAA réduit le risque d'émission abusive et la surveillance des logs CT repère tout ce qui passerait malgré tout entre les mailles du filet. Aucun des deux, seul, ne constitue une réponse complète.

Logs CT vs surveillance SSL classique

Il est utile de bien distinguer ce que chaque couche vous apprend réellement :

La recherche dans les logs CT est rétrospective et couvre l'ensemble du domaine ; les vérifications SSL en production sont ponctuelles et propres à un hôte. Il vous faut les deux. Côté surveillance, La surveillance de sites web expliquée montre comment s'articulent les contrôles de disponibilité et d'expiration SSL.

Bien démarrer avec la surveillance CT

Si vous gérez plus d'une poignée de domaines, une recherche manuelle sur crt.sh une fois par trimestre ne suffit pas : des certificats sont émis en permanence, et un certificat malveillant peut rester actif des mois avant que quelqu'un ne le remarque. L'approche réaliste consiste à savoir quelles CA vous utilisez réellement, à surveiller tout ce qui sort de cette liste, et à placer l'expiration des certificats et l'état des chaînes sous surveillance active, plutôt que de réagir après une panne.

Lancez dès maintenant une vérification rapide sur n'importe quel domaine avec l'outil de vérification SSL gratuit, ou centralisez le suivi des certificats de tous vos fournisseurs dans la gestion des certificats d'InfraNest, pour ne plus compter sur votre mémoire afin de repérer ce que les logs CT savent déjà.