Surveiller Certificate Transparency pour son domaine

Surveiller Certificate Transparency pour son domaine

Certificate Transparency (CT) retire aux autorités de certification une partie de leur opacité historique : un certificat public émis pour un domaine laisse une trace vérifiable. Ce mécanisme ne bloque pas une émission frauduleuse, mais il transforme une compromission silencieuse en événement détectable, à condition de surveiller les journaux au lieu de leur faire confiance par télépathie.

Explication de la marmotte

Cela ressemble à un registre public où chaque permis de construire est visible par tous. Si quelqu’un obtient un permis pour modifier une maison qui ne lui appartient pas, le propriétaire peut le voir rapidement et contester, plutôt que découvrir les travaux une fois le toit déjà démonté.

→ Lire l’explication complète de la marmotte

Certificate Transparency : la responsabilité des autorités de certification

Une autorité de certification, ou CA (Certificate Authority), peut signer un certificat pour un nom de domaine après avoir validé le contrôle de ce nom. Le navigateur fait alors confiance au certificat parce qu’il fait confiance à la CA racine présente dans son magasin de confiance. Cette délégation est nécessaire pour le Web public, mais elle concentre un pouvoir extravagant : une CA compromise, négligente ou malveillante peut émettre un certificat pour www.exemple.fr sans que son titulaire légitime participe à l’opération.

Avant CT, cette émission pouvait rester invisible jusqu’à son exploitation. Un attaquant capable d’intercepter le trafic réseau pouvait présenter ce certificat frauduleux, établir une connexion Transport Layer Security (TLS) valide du point de vue du navigateur, puis lire ou modifier les échanges. Le cadenas ne ment pas exactement : il dit seulement que la clé présentée est signée par une autorité reconnue. La nuance a déjà ruiné des journées autrement prometteuses.

CT impose une traçabilité publique aux certificats du Web public. La position à tenir est nette : tout domaine exposé sur Internet doit être surveillé dans les journaux CT, même lorsqu’une seule CA est autorisée contractuellement. Une restriction d’achat chez une CA ne limite pas la capacité technique des autres CA de l’écosystème à émettre pour le domaine. CT ne remplace donc ni la gouvernance PKI, ni le contrôle des validations de domaine, décrits dans PKI expliquée.

Le compromis central est direct :

• Gain : détection quasi immédiate d’une émission inattendue, audit public des certificats et pression opérationnelle sur les CA.
• Coût : les noms présents dans les certificats deviennent publiquement énumérables, y compris les sous-domaines imprudemment nommés admin-interne, vpn-prod ou fusion-secrete. CT est un excellent inventaire pour les défenseurs, et un excellent catalogue pour les attaquants.

Il faut donc séparer les noms internes des noms publics. Un certificat destiné à un service interne ne doit pas être signé par une CA publique. Utiliser une infrastructure de certification interne, avec une zone DNS (Domain Name System) non publique ou des noms réservés, évite d’exposer l’architecture dans CT. Publier un nom sensible puis regretter son indexation n’est pas une stratégie de discrétion, c’est un communiqué de presse avec une extension .pem.

Journaux CT, arbres de Merkle et preuves vérifiables

Un journal CT est un service append-only : il accepte de nouvelles entrées mais ne doit ni modifier ni supprimer les anciennes. Cette propriété est rendue vérifiable par un arbre de Merkle, une structure où chaque feuille contient le condensat cryptographique d’une entrée et où chaque nœud combine les condensats de ses enfants. Le sommet de l’arbre engage cryptographiquement tout son contenu.

Lorsqu’une CA soumet un certificat, ou plus souvent un pré-certificat, au journal, celui-ci renvoie un SCT (Signed Certificate Timestamp), soit une promesse signée d’intégrer l’objet avant une échéance définie. La CA incorpore ensuite ce SCT dans le certificat final, dans l’extension TLS du serveur ou dans l’extension de certificat OCSP (Online Certificate Status Protocol). Un navigateur appliquant une politique CT vérifie que les SCT proviennent de journaux acceptés et que leur nombre respecte la politique applicable.

Le navigateur ne télécharge généralement pas l’intégralité des journaux pendant chaque négociation TLS. Il vérifie la présence et la validité cryptographique des SCT. L’inclusion effective du certificat se contrôle ensuite avec une preuve d’inclusion, qui relie la feuille du certificat à une tête d’arbre signée, ou STH (Signed Tree Head). Une preuve de cohérence permet de vérifier qu’une nouvelle tête d’arbre prolonge la précédente sans réécrire l’historique.

Cette distinction compte : un SCT valide prouve l’acceptation par un journal, pas l’inclusion déjà observable au même instant. Un journal qui promet puis omet l’entrée doit être détecté par des moniteurs et des auditeurs. Le mécanisme dépend donc d’un écosystème de surveillance, pas d’une incantation append-only gravée sur une slide de conférence.

Pour les certificats publics utilisés par des navigateurs appliquant les politiques CT, notamment Chrome, l’absence de SCT conforme rend le certificat inutilisable. Les politiques exactes varient selon les navigateurs et évoluent. Une architecture ne doit pas réduire cette réalité à « CT est obligatoire partout » : il faut tester les clients réellement supportés et suivre les politiques des magasins de confiance concernés. TLS expliqué détaille ce que le navigateur valide pendant la connexion, au-delà de CT.

Surface d’attaque : ce que CT détecte et ce qu’il laisse passer

CT détecte l’existence d’une émission publique. Il ne détermine pas si cette émission est légitime. Un certificat de renouvellement automatisé, un certificat de secours oublié, un certificat émis par un prestataire autorisé mais non déclaré dans l’inventaire et un certificat hostile ont exactement la même apparence initiale : un nouveau nom, un nouvel émetteur, une nouvelle clé.

Une alerte CT doit donc être corrélée avec un référentiel d’émissions attendues : domaine, sous-domaines autorisés, CA autorisées, empreintes de clés publiques attendues, environnement propriétaire, fenêtre de validité et ticket de changement. Sans cette liste, la supervision produit une collection de surprises administratives. C’est vivant, mais pas dans le bon sens.

CT ne garantit pas les points suivants :

• Il n’empêche pas une CA de signer un certificat frauduleux. Il rend cette signature visible après soumission.
• Il ne révoque pas le certificat détecté. La révocation exige une demande à la CA, puis dépend de la vérification de statut par les clients.
• Il ne coupe pas les sessions TLS déjà établies. La révocation d’un certificat ne remonte pas le temps.
• Il ne couvre pas les certificats privés, les autorités internes ou les certificats auto-signés.
• Il ne protège pas contre la compromission de la clé privée légitime. Un attaquant disposant de cette clé peut exploiter le certificat parfaitement enregistré.
• Il ne garantit pas qu’un humain lira l’alerte ni qu’une procédure d’incident existe. La cryptographie ne remplace pas l’astreinte, elle la rend seulement mieux informée.

La contre-mesure contre une émission frauduleuse combine CT, journalisation DNS, protection du compte chez les registrars, validation de domaine par DNS avec délégation minimale, contrôle des comptes de CA et capacité de révocation documentée. Lorsque la clé privée du certificat est hébergée dans un HSM (Hardware Security Module), CT ne protège pas ce HSM mais réduit l’intérêt d’obtenir un certificat concurrent. Ce sont deux contrôles différents, pas une solution miracle en deux boîtes et trois logos.

Surveillance CT d’un domaine avec crt.sh

crt.sh agrège et expose des entrées CT publiques. Il sert bien à l’inventaire et à l’alerte initiale, mais il ne doit pas devenir l’unique source de surveillance : une dépendance unique à un service tiers transforme la détection en vœu pieux avec une interface web. Interroger plusieurs sources ou consommer directement des flux de journaux réduit ce risque.

La recherche doit couvrir le domaine racine et les sous-domaines. Le caractère % dans la requête %.exemple.fr recherche les noms descendants ; la réponse contient souvent des doublons, car un même certificat peut être journalisé plusieurs fois ou comporter plusieurs noms. Il faut dédupliquer sur l’empreinte SHA-256 (Secure Hash Algorithm 256 bits) du certificat, ou à défaut sur le numéro de série associé à l’émetteur.

# Rechercher les certificats contenant exemple.fr ou un sous-domaine.
# jq est requis ; remplacer exemple.fr par le domaine surveillé.
curl --fail --silent \
  'https://crt.sh/?q=%25.exemple.fr&output=json' |
jq -r '
  .[]
  | {
      id,
      issuer_name,
      not_before,
      not_after,
      serial_number,
      name_value
    }
  | @json
'

Cette commande est reproductible, mais elle n’est pas un système d’alerte. En exploitation, il faut conserver l’état des identifiants déjà vus, interroger à cadence définie, normaliser les noms en minuscules, éclater name_value sur les retours à la ligne et rejeter les noms hors périmètre. Les certificats avec caractères internationaux exigent aussi une normalisation IDNA (Internationalized Domain Names in Applications), faute de quoi un nom encodé peut contourner un filtre naïf.

L’alerte doit contenir au minimum le nom observé, l’émetteur, le numéro de série, les dates de validité, l’identifiant CT et le lien vers le certificat. Ajouter la clé publique ou son empreinte permet de distinguer un renouvellement légitime d’une émission utilisant une clé inconnue. Déclencher une alerte sur chaque renouvellement attendu est acceptable pendant la mise en place, pas durablement : une liste d’autorisations déclarative vaut mieux qu’une boîte de réception transformée en compost.

Exploitation : inventaire, réponse et continuité de surveillance

Les prérequis sont modestes mais non négociables : une liste versionnée des domaines publics, un référentiel des CA autorisées, un canal d’alerte surveillé, une identité de service pour l’outil de supervision et une procédure de réponse. La supervision CT n’a pas besoin de secret cryptographique pour consulter les journaux publics. Elle peut toutefois dépendre de clés d’API si un fournisseur commercial est utilisé ; ces clés doivent être stockées dans le gestionnaire de secrets existant, avec rotation et droits minimaux.

La règle opérationnelle est de créer une attente avant toute émission. Un pipeline de délivrance de certificat doit enregistrer le domaine, l’émetteur prévu, la clé publique attendue si elle est stable, l’environnement et la durée de vie. Pour les certificats automatisés via EST (Enrollment over Secure Transport), cette déclaration doit faire partie du flux d’émission, pas d’un tableur séparé qui découvrira l’avenir après coup. La mécanique d’enrôlement est couverte dans EST expliqué.

À la détection d’un certificat inconnu, l’ordre de traitement est le suivant :

1. Vérifier que le nom appartient bien au périmètre et récupérer le certificat complet.
2. Comparer l’émetteur, la clé publique, la demande de certificat et les changements autorisés.
3. Examiner les journaux DNS et les comptes de CA pour identifier une validation de domaine inattendue.
4. Demander la révocation à l’émetteur si l’émission est frauduleuse.
5. Réémettre les certificats légitimes si une clé ou un mécanisme de validation est suspecté.
6. Rechercher l’usage du certificat dans les journaux de proxy, les sondes réseau et les traces de clients, sans supposer que l’absence de trace prouve l’absence d’exploitation.

La sauvegarde porte sur la configuration de surveillance, l’état de déduplication, les listes d’autorisations et les procédures de réponse. Les journaux CT eux-mêmes sont publics et répliqués par conception, mais l’état local explique quelles alertes ont été acquittées et pourquoi. Perdre cet état ne casse pas CT ; cela recrée une avalanche d’alertes, ce qui reste une forme très traditionnelle de déni de service administratif.

Les métriques à suivre sont le délai entre émission et détection, le taux d’alertes sans propriétaire identifié, le nombre de CA observées hors liste autorisée et l’âge des autorisations temporaires. Une autorisation temporaire sans date de fin est une exception devenue meuble de bureau : personne ne sait qui l’a posée, tout le monde évite de la toucher.

🐝 Ce qui arrive si on s’en passe

Sans surveillance des journaux CT, l’émission reste publique : elle est lisible par quiconque interroge les agrégateurs, mais pas par le titulaire du domaine. L’asymétrie est totale, l’attaquant énumère les sous-domaines publiés et le défenseur découvre le certificat au mieux à son expiration, au pire jamais. Le délai entre émission et détection devient égal à la durée de validité, soit plusieurs mois pendant lesquels une interception reste indiscernable d’un trafic normal. La chronologie d’un incident devient irreconstituable : sans horodatage CT collecté, impossible de dater la validation de domaine détournée, donc de délimiter la fenêtre d’exposition ou de justifier une demande de révocation auprès de l’émetteur. S’ajoutent les certificats oubliés, émis par un prestataire et jamais inventoriés, qui restent valides et opposables sans propriétaire identifié.

🦫 Explication de la marmotte 🍫

Les sites web utilisent des certificats pour prouver qu’ils contrôlent un nom et pour chiffrer les échanges avec les visiteurs. Une autorité de certification est un organisme auquel les navigateurs font confiance pour délivrer ces certificats. Le problème est qu’une autorité piratée ou malhonnête pourrait créer un certificat pour le site d’une autre organisation.

Certificate Transparency oblige les certificats publics à être inscrits dans des registres accessibles à tous. Lorsqu’un certificat est demandé, le registre fournit une preuve signée indiquant qu’il va l’ajouter. Cette preuve est placée dans le certificat ou transmise pendant la connexion au site. Les navigateurs qui appliquent cette règle refusent les certificats publics qui n’ont pas les preuves attendues.

Les registres organisent leurs entrées pour rendre les suppressions et modifications détectables. Des contrôleurs peuvent vérifier qu’un certificat promis apparaît bien ensuite, et que l’historique n’a pas été réécrit.

Le propriétaire d’un domaine doit donc interroger ces registres régulièrement. Si un certificat inconnu apparaît, il faut vérifier s’il correspond à un renouvellement autorisé. Sinon, il faut demander son annulation à l’autorité qui l’a délivré, rechercher comment le contrôle du domaine a été détourné et vérifier si le certificat a servi à intercepter des connexions. Le registre révèle l’émission, mais il n’empêche pas à lui seul le piratage ni l’utilisation d’une clé privée déjà volée.

À lire aussi

• Certificats SSH et risques de l’agent forwardingSécuriser Secure Shell avec clés, certificats, agent forwarding, révocation et exploitation des accès.
• Construire une autorité de certification privée interneConcevoir, sécuriser et exploiter une autorité de certification privée pour les services internes.
• Cycle de vie d'une autorité de certification intermédiaireÉmettre, renouveler et révoquer en cascade une autorité de certification intermédiaire, avec les extensions, les échéances et les pièges d'exploitation qui font tomber une PKI entière.
• Gestion du cycle de vie des certificats à grande échelleMettre en place une gestion complète du cycle de vie des certificats pour découvrir, renouveler, déployer et superviser des milliers de certificats.

Pages voisines

La citent

• Hachage dans les systèmes: intégrité, arbres et preuves
• Relier une clé à une identité: certificats et PKI
• DNSSEC : chaîne de confiance, validation et exploitation des clés
• OSINT défensif : mesurer et réduire l'exposition publique

Surveiller Certificate Transparency pour son domaine

Elle cite

• Sécuriser la validation de domaine HTTP-01 et DNS-01
• Comprendre TLS : mécanismes, garanties et limites
• PKI expliquee
• Pourquoi un certificat diffère selon le navigateur
• Architecture de journalisation d’audit immuable centralisée
• EST : enrôler des certificats X.509 par transport sécurisé