Journaux Certificate Transparency : vos sous-domaines sont publics
Découvrez comment les journaux CT révèlent vos sous-domaines via crt.sh, crt.name, subfinder et amass, et comment surveiller vos domaines.
Long Nguyen
Développeur fullstack · Ingénieur IA · Chercheur
Ce que sont réellement les journaux Certificate Transparency
Tout certificat TLS approuvé publiquement et délivré aujourd’hui doit être publié dans un journal Certificate Transparency (CT) avant que les navigateurs l’acceptent sans avertissement. Chrome applique cette règle depuis 2018 ; les plateformes Apple l’appliquent également. Ces journaux sont des arbres de Merkle en ajout uniquement, gérés par des entreprises comme Let's Encrypt (Sunlight), Google (Argon), Cloudflare (Raio), DigiCert et Sectigo. Une autorité de certification ne peut pas délivrer discrètement un certificat pour staging.yourcompany.com et le soustraire aux archives publiques : le Signed Certificate Timestamp exigé par les navigateurs prouve que le certificat figure déjà dans l’un de ces journaux.
Le CT a été conçu pour détecter les certificats mal délivrés ou frauduleux, pas pour constituer un répertoire de sous-domaines. Mais il entraîne un effet secondaire permanent : le champ SAN (Subject Alternative Name) de chaque certificat est public, et il répertorie tous les noms d’hôte couverts par le certificat. Un certificat wildcard pour *.yourcompany.com ou un certificat SAN couvrant cinq outils internes inscrit ces cinq noms d’hôte dans les archives pour toujours, qu’ils apparaissent ou non dans le DNS public, un sitemap ou les résultats de Google.
C’est ce que beaucoup de personnes sous-estiment. Retirer un sous-domaine des transferts de zone DNS ou du site public ne le retire pas des journaux CT : s’il a un jour utilisé HTTPS, il y est enregistré. Environnements de développement, interfaces d’administration, API internes, points de terminaison d’intégrations tierces : si quelqu’un a demandé un certificat pour eux, ils sont présents.
Comment interroger manuellement les journaux CT pour un domaine
crt.sh, géré par Sectigo, est l’interface vers laquelle la plupart des utilisateurs se tournent en premier. Une requête dans le navigateur ressemble à https://crt.sh/?q=%.example.com et le service propose également un endpoint JSON pour l’automatisation :
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -uCette commande en une ligne est le moyen le plus rapide d’obtenir une liste brute de sous-domaines depuis la ligne de commande : aucune inscription, aucune clé API, aucun brute force DNS. crt.name couvre le même périmètre, mais avec une conception orientée API : GET https://crt.name/v1/search?apex=example.com renvoie une liste à plat de tous les sous-domaines présents dans son index. Celui-ci est constitué en analysant les champs SAN des entrées des journaux CT Static et historiques RFC 6962 au fil de leur arrivée, puis en complétant les anciens noms à partir de journaux rejoués, de Common Crawl et de sources de fichiers de zone. Pour l’automatisation, l’avantage par rapport à crt.sh est clair : pas de HTML à analyser et pas de surprise liée aux limites de débit sur une simple requête GET.
Lancez l’une ou l’autre requête sur un domaine important et vous remarquerez immédiatement une chose : la liste inclut des certificats délivrés il y a dix ans pour des services qui n’existent plus. Les journaux CT sont en ajout uniquement : rien n’est jamais supprimé. Une requête renvoie donc un historique, et pas seulement les éléments actuellement actifs. C’est utile pour la reconnaissance, et parfois embarrassant pour le propriétaire du domaine.
crt.sh, crt.name, subfinder ou amass : lequel choisir ?
Ces outils ne sont pas vraiment concurrents : ils se situent à différents endroits de l’axe rapidité-couverture, et une mission réelle en utilise généralement plusieurs.
| Outil | Son point fort | Source des données | Quand l’utiliser |
|---|---|---|---|
| crt.sh | Recherche manuelle rapide dans un navigateur | Journaux CT uniquement, analysés et indexés par Sectigo | Vérification ponctuelle d’un seul domaine |
| crt.name | Scripts et requêtes en masse | Journaux CT (en direct et rejoués), ainsi que Common Crawl, CZDS, Chaos et les listes de blocage DNS | Chaînes automatisées, sans clé API |
| subfinder | Large couverture rapide grâce à de nombreuses sources passives interrogées simultanément | Agrège crt.sh, Censys, Cert Spotter et des dizaines d’autres sources | Première passe sur une nouvelle cible |
| amass | Couverture maximale, y compris avec des techniques actives | Journaux CT, brute force DNS, scraping et intégrations API | Lorsque l’inventaire d’actifs doit être aussi complet que possible |
| Censys / Cert Spotter | Enrichissement et surveillance des certificats en temps réel | Journaux CT et données d’analyse des IP et services | Surveillance continue de vos certificats ou analyse plus approfondie d’une cible |
Pour une vérification rapide d’un domaine, crt.sh ou crt.name suffit. Pour cartographier réellement une surface d’attaque — comme avant de vérifier la capacité d’un agent à agir ou de réaliser un audit de sécurité — commencez par subfinder pour aller vite, puis utilisez amass si la cible est suffisamment vaste pour que des sous-domaines manqués posent problème.
À quoi cette liste sert-elle réellement ?
Une liste de sous-domaines ne constitue pas à elle seule une faille. Elle modifie surtout le point de départ de l’attaquant : au lieu de devoir deviner votre infrastructure, il dispose d’un inventaire basé sur les noms et peut passer directement à un travail ciblé.
- Trouver d’abord les cibles les plus vulnérables. Les sous-domaines
admin.,staging.,internal-api.etvpn.font souvent tourner des logiciels plus anciens, une authentification moins robuste ou des configurations par défaut, car « personne ne connaît l’URL » constituait leur seul modèle de sécurité. - Prendre le contrôle d’un sous-domaine. Si un sous-domaine enregistré dans un journal CT pointe encore via CNAME vers un service cloud désaffecté (un ancien bucket S3, une application Heroku supprimée ou un service SaaS tiers expiré), un attaquant peut souvent revendiquer cette ressource et diffuser du contenu depuis votre sous-domaine — avec l’historique de vos certificats et la confiance accordée à votre domaine.
- Créer un hameçonnage crédible. Une liste de noms d’hôte qui semblent appartenir à vos systèmes internes rend une fausse page de connexion ou un e-mail de spear phishing bien plus convaincant qu’une supposition générique.
- Prioriser les analyses de vulnérabilités. Chaque nom d’hôte découvert constitue un point d’entrée supplémentaire à identifier et sonder : les journaux CT transforment une reconnaissance passive en liste de cibles, sans envoyer le moindre paquet vers votre infrastructure.
Transformer cette même technique en outil de défense
Vous ne pouvez pas empêcher l’enregistrement de vos certificats, et vous ne devriez pas le vouloir : c’est le CT qui permet de détecter en premier lieu un certificat frauduleusement délivré pour votre domaine. La bonne approche consiste à surveiller le même flux que celui interrogé par les attaquants, afin de repérer les nouveaux sous-domaines et certificats avant eux.
- Établissez une base de référence de vos sous-domaines actuels. Lancez une requête crt.sh ou crt.name sur chaque domaine apex que vous possédez et considérez le résultat comme votre véritable inventaire d’actifs, plutôt que de vous fier à celui de votre wiki interne.
- Recherchez les enregistrements DNS orphelins. Pour chaque sous-domaine apparaissant dans CT mais qui n’est plus utilisé, vérifiez si son enregistrement DNS pointe encore quelque part : un CNAME oublié vers un service déprovisionné est une prise de contrôle qui ne demande qu’à se produire.
- Mettez en place une surveillance récurrente. Cert Spotter et plusieurs agrégateurs de journaux CT permettent de recevoir des alertes lors de l’émission de nouveaux certificats pour un domaine. Une requête
crt.shoucrt.nameplanifiée dans une tâche cron fonctionne également si vous souhaitez éviter toute dépendance à un tiers. - Décommissionnez proprement. Lorsque vous retirez un sous-domaine, supprimez son enregistrement DNS, et pas uniquement l’application qui se trouve derrière. Le certificat restera de toute façon dans les journaux CT, mais un enregistrement DNS supprimé qui ne pointe nulle part constitue une impasse pour l’attaquant, et non une porte ouverte.
C’est cette même base de reconnaissance passive que nous mettons en place avant de renforcer l’infrastructure exposée d’un client. En associant la découverte via les journaux CT au travail sur le DNS et les robots d’exploration présenté dans notre service de développement logiciel sur mesure et de renforcement de la sécurité, nous détectons les sous-domaines orphelins avant qu’ils ne deviennent un point d’entrée.
FAQ
Questions fréquentes
Qu’est-ce que le Certificate Transparency et pourquoi expose-t-il les sous-domaines ?
Le Certificate Transparency est une exigence appliquée par les navigateurs : tout certificat TLS approuvé publiquement doit être publié dans un journal public en ajout uniquement avant d’être accepté sans avertissement. Comme le champ SAN d’un certificat répertorie chaque nom d’hôte couvert, l’enregistrement du certificat rend également ces noms publics, y compris les sous-domaines qui n’étaient référencés nulle part ailleurs.
Puis-je refuser l’enregistrement dans les journaux Certificate Transparency ?
Non. Chrome et les plateformes Apple rejettent les certificats dépourvus d’un Signed Certificate Timestamp valide. Tout certificat approuvé publiquement doit donc être enregistré. Le seul moyen d’éviter l’exposition CT pour un nom d’hôte est de ne jamais lui délivrer de certificat TLS approuvé publiquement, ce qui implique d’utiliser une autorité de certification privée et d’accepter les avertissements du navigateur qui en découlent.
Quelle est la différence entre crt.sh et crt.name ?
crt.sh est l’interface web historique gérée par Sectigo, idéale pour une recherche manuelle rapide et proposant également un endpoint JSON. crt.name a été conçu d’abord pour les scripts et les requêtes en masse : il indexe les entrées CT en direct ainsi que les journaux historiques rejoués, Common Crawl et les sources de fichiers de zone DNS dans un index unique de sous-domaines, sans clé API obligatoire.
L’utilisation d’outils d’énumération comme subfinder et amass est-elle légale ?
Interroger les journaux publics Certificate Transparency est légal : ces données sont publiques par conception. Tout dépend de l’usage que vous faites des sous-domaines trouvés. Les utiliser pour cartographier votre propre surface d’attaque ou avec une autorisation explicite dans le cadre d’une mission de sécurité est une pratique courante ; les utiliser pour attaquer des systèmes sans autorisation ne l’est pas.
Comment surveiller les journaux Certificate Transparency de mon domaine ?
Planifiez une requête vers crt.sh ou crt.name pour chaque domaine apex que vous possédez, ou utilisez un service de surveillance comme Cert Spotter, qui envoie des alertes lors de l’émission de nouveaux certificats. L’objectif est de détecter un certificat nouveau ou frauduleux pour votre domaine en quelques heures, et non plusieurs mois plus tard.
Qu’est-ce qu’un sous-domaine orphelin et pourquoi représente-t-il un risque de sécurité ?
Un sous-domaine orphelin est un sous-domaine dont l’enregistrement DNS pointe encore vers une ressource cloud — un bucket S3, une application Heroku ou un endpoint SaaS tiers — qui n’existe plus ou a été déprovisionnée. Un attaquant qui découvre ce sous-domaine dans les journaux CT peut souvent revendiquer la ressource abandonnée et diffuser son propre contenu depuis un nom d’hôte de votre domaine, en profitant de la confiance qui lui est accordée.