Certificate Transparency : ce que les journaux de certificats révèlent du SBF 120, et comment
pivoter dessus

Vous avez verrouillé example.com, son www et son api. Trois actifs, patchés, monitorés, propres. Puis un matin, dans le flux des certificats fraîchement émis, un nom apparaît : grafana.staging.example.com. Personne ne l'avait inventorié. Le certificat, lui, l'a publié à la terre entière, signé, horodaté, et pour toujours.

Le Certificate Transparency (CT) fait de chaque certificat TLS une balise publique. Combien de balises une grande entreprise française laisse-t-elle derrière elle, et combien portent un nom d'environnement de développement ou de recette ? J'ai fait le compte le 6 octobre 2026 pour le SBF 120, en agrégats seulement. Les chiffres viennent d'abord ; viennent ensuite les techniques de pivot qui servent l'inventaire de surface d'attaque externe côté défense et l'élargissement de scope côté bug bounty.

Le journal public où finissent tous vos certificats

Le Certificate Transparency est né d'un problème concret : une autorité de certification compromise pouvait émettre un certificat valide pour google.com sans que Google ne le sache. La parade, standardisée dans la RFC 6962, oblige les autorités à publier chaque certificat émis dans des journaux publics, en ajout seul, vérifiables cryptographiquement. Depuis 2018, Chrome refuse un certificat qui ne présente pas de preuve d'inscription (un SCT, Signed Certificate Timestamp).

L'effet de bord est énorme : tout certificat TLS publiquement validé est, par construction, public et permanent. Chaque fois qu'un de vos services, ou un prestataire en votre nom, demande un certificat (un certbot qui tourne, une instance qui démarre, un SaaS qui provisionne un sous-domaine), il grave le nom d'hôte correspondant dans le journal, y compris les noms que vous n'avez publiés nulle part. Trois portes d'entrée pour le consulter : crt.sh, Censys, qui indexe aussi les hôtes qui présentent ces certificats, et le flux temps réel de CertStream.

Ce que Certificate Transparency révèle du SBF 120

La méthode

Le panel est la composition Euronext du SBF 120 au 6 octobre 2026 : 120 émetteurs, dont 1 exclu faute de site de groupe identifiable, soit 119 sociétés. Pour chacune, un seul domaine, celui du site officiel. La source est la base PostgreSQL publique de crt.sh, interrogée en lecture seule, une société à la fois, avec deux secondes de pause entre deux requêtes :

• Fenêtre : certificats dont la date de début de validité tombe dans les 24 mois précédant la collecte (du 6 octobre 2024 au 6 octobre 2026, 18 h 27 UTC).
• Noms : entrées dNSName du champ SAN égales au domaine ou se terminant par .domaine, en minuscules, comptées une fois. Un wildcard est un nom qui commence par *..
• Lexique : un nom est compté s'il contient dev, test, staging, preprod ou recette comme segment, éventuellement suivi de chiffres et délimité par un point ou un tiret. "latest" ne compte pas, "dev2-api" compte.
• Agrégation côté serveur : la requête SQL renvoie des compteurs, jamais un nom d'hôte. Aucun nom d'hôte n'a été stocké ; seuls des compteurs par domaine sont conservés, et ils ne sont pas publiés.

Les 119 sociétés ont été mesurées, sans échec. Un détail de méthode vaut d'être retenu par quiconque fait de la recon : la sortie JSON du site crt.sh a été testée puis écartée, parce que pour un grand domaine elle renvoyait un historique tronqué qui s'arrêtait en 2023, alors que des certificats valides plus récents existaient. Elle aurait sous-compté précisément les plus grands parcs.

Les résultats, en médianes

Une société médiane du SBF 120 a donc laissé 139 noms d'hôtes dans les journaux en deux ans, sur son seul domaine principal, et à peu près un sur huit désigne un environnement de développement, de test ou de recette. La dispersion est énorme : de 3 noms pour la plus discrète à 11 162 pour la plus fournie, et 16 sociétés dépassent le millier. C'est la raison pour laquelle les médianes passent devant tout le reste. En additionnant les 68 247 noms du panel, on obtiendrait 24,8 % de noms du lexique et 11,3 % de wildcards : ces parts globales sont tirées par quelques très gros parcs (le plus fourni pèse à lui seul 16 % des noms) et ne décrivent pas une société typique.

Le wildcard, souvent présenté comme la façon de ne pas publier ses sous-domaines, reste minoritaire : 98 sociétés sur 119 en utilisent au moins un, mais en médiane les wildcards ne représentent que 2,6 % des noms. Le reste est écrit en clair, nom par nom. Et 20 sociétés sur 119 seulement publient un enregistrement CAA, qui restreint la liste des autorités autorisées à émettre pour leur domaine.

Pourquoi compter des sociétés et pas des certificats ? Parce qu'une part de certificats est pondérée par la fréquence de renouvellement. Sur 24 mois, un nom couvert par une autorité à certificats de 90 jours (Let's Encrypt, Google Trust Services) produit deux à quatre fois plus de certificats qu'un nom couvert par une autorité commerciale, dont la durée maximale était de 398 jours jusqu'au 15 mars 2026 et de 200 jours depuis. Une part de certificats ferait donc croire que les autorités gratuites couvrent bien plus de noms qu'en réalité.

Le chiffre à retenir est ailleurs : 117 sociétés sur 119 ont au moins un certificat Let's Encrypt sur leur domaine principal. Ce n'est pas un défaut, l'autorité est parfaitement fiable. Mais une émission par ACME se déclenche en une commande, sans bon de commande ni validation par l'équipe qui gère la PKI : c'est exactement le canal par lequel une équipe projet ou un prestataire met un service en ligne sans passer par l'inventaire. C'est aussi un canal par lequel naissent le shadow IT et les actifs exposés que personne ne gère, sans que chaque certificat Let's Encrypt en soit un : CDN et plateformes SaaS émettent eux aussi ces certificats pour le compte de leurs clients. Dans tous les cas, le journal CT en garde la trace.

Refaire le compte sur votre domaine

La base de crt.sh accepte les connexions en lecture avec l'utilisateur guest. La requête ci-dessous est une version simplifiée de celle de l'étude : mêmes filtres, mêmes définitions, sur un seul domaine. Sur un grand parc, comptez quelques secondes, parfois un délai dépassé quand la base est chargée.

psql -h crt.sh -p 5432 -U guest certwatch <<'SQL'
WITH f AS MATERIALIZED (
  SELECT lower(cai.NAME_VALUE) AS nm
  FROM certificate_and_identities cai
  WHERE plainto_tsquery('certwatch', 'example.fr') @@ identities(cai.CERTIFICATE)
    AND cai.NAME_TYPE = 'san:dNSName'
    AND (lower(cai.NAME_VALUE) = 'example.fr'
         OR lower(cai.NAME_VALUE) LIKE '%.example.fr')
    AND x509_notBefore(cai.CERTIFICATE) >= now() - interval '24 months'
)
SELECT count(DISTINCT nm)                                   AS noms,
       count(DISTINCT nm) FILTER (WHERE nm LIKE '*.%')      AS wildcards,
       count(DISTINCT nm) FILTER (WHERE nm ~
         '(^|[.-])(dev|test|staging|preprod|recette)[0-9]*([.-]|$)') AS hors_prod
FROM f;
SQL

Comparez vos trois chiffres aux médianes du SBF 120, puis faites ce que l'étude s'est interdit : lister les noms du lexique, et pour chacun répondre à deux questions. Est-il encore résolu en DNS ? Répond-il depuis internet ? Ceux qui répondent sont votre liste de travail. Ceux qui ne résolvent plus, mais dont l'enregistrement pointe encore vers un service tiers, sont des candidats au subdomain takeover.

Le SAN, la première fuite

Un certificat ne couvre pas qu'un seul nom. Le champ Subject Alternative Name (SAN) liste tous les hôtes pour lesquels il est valide, et une seule demande peut couvrir une grappe de sous-domaines. L'extraction rapide, côté recon, passe par crt.sh, avec la réserve de troncature vue plus haut :

# Tous les noms vus dans des certificats pour *.example.com, dédoublonnés
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' \
  | tr '[:upper:]' '[:lower:]' | sed 's/^\*\.//' \
  | sort -u

# example.com
# api.example.com
# vpn-old.example.com          <- celui-là, vous l'aviez oublié
# grafana.staging.example.com  <- et celui-là, il n'aurait jamais dû sortir

Énumérer les SAN d'un domaine que vous connaissez reste du terrain balisé. Le vrai gain vient du pivot : partir d'un actif connu pour sauter vers des actifs dont vous ignoriez l'existence, voire vers d'autres domaines racine, ceux que la mesure ci-dessus ne voit pas.

Le vrai pivot : le certificat partagé

Un certificat possède une empreinte (le SHA-256 de sa forme DER) qui l'identifie de façon unique. Or un même certificat est souvent déployé sur plusieurs machines : les nœuds derrière un répartiteur de charge, une copie de staging clonée depuis la prod, une vieille VM oubliée, l'IP d'origine cachée derrière un CDN. Tous présentent la même empreinte. Et on ne partage pas sa clé privée avec des inconnus : si deux hôtes servent le même certificat auto-géré, ils appartiennent à la même organisation. Censys et Shodan, qui collecte la bannière de chaque service exposé indexent le certificat présenté par chaque IP : il suffit de leur demander qui d'autre sert exactement celui-là.

# 1) Empreinte SHA-256 du certificat servi par un actif connu
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -fingerprint -sha256
# SHA256 Fingerprint=A1:B2:...:9F

# 2) Pivot Censys : tout hôte qui présente CE certificat exact
censys search 'services.tls.certificates.leaf_data.fingerprint_sha256="a1b2...9f"'
# 203.0.113.10   <- api.example.com (connu)
# 198.51.100.7   <- inconnu : origine derrière le CDN ? staging ?

Ce pivot perce les CDN : si l'origine sert encore le même certificat que le domaine public, une recherche par empreinte recrache l'IP d'origine, et l'on tape directement le serveur en contournant le pare-feu applicatif, le plus radical des contournements de WAF.

Pivoter par le sujet et l'émetteur

Les champs du Subject portent souvent de l'or : une organisation (O=Example Corporation) sur un certificat OV ou EV, un nom d'hôte de management qu'un administrateur a un jour exposé par erreur. Pivoter par organisation fait sauter d'un domaine racine à l'autre : vous connaissiez example.com, le champ O= révèle des certificats sur example.org et example.net, qu'aucune énumération de sous-domaines n'aurait reliés entre eux.

# Censys : tous les certificats où l'organisation du sujet = la cible
parsed.subject.organization: "Example Corporation"

# Censys : certificats émis pour un domaine, même sur d'autres apex
parsed.names: /.*\.example\.(net|org)/

CertStream : surveiller le flux en temps réel

Tout ce qui précède est une photographie. Mais CT est un flux continu : en s'y branchant, on attrape un nouvel actif au moment où son certificat est émis, souvent avant que le service soit en production. On attrape aussi les domaines de typosquatting qu'un attaquant prépare : un certificat pour example-secure-login.com qui apparaît est un signal d'alerte précoce.

# CertStream pousse chaque entrée CT en JSON sur un WebSocket.
# Filtre maison : tout nom qui ressemble à la marque surveillée.

import certstream

WATCH = ("example", "exarnple")

def on_event(message, context):
    if message["message_type"] != "certificate_update":
        return
    for name in message["data"]["leaf_cert"]["all_domains"]:
        low = name.lower()
        if any(w in low for w in WATCH):
            print(f"[CT] {name}")          # -> webhook, SIEM, Discord...

certstream.listen_for_events(on_event, url="wss://certstream.calidog.io/")

NIS2 et bug bounty : la même source, deux usages

L'article 21 de la directive NIS2 impose une gestion des actifs, et on ne gère pas un inventaire qu'on ne connaît pas. Le flux CT comble l'écart entre la CMDB déclarative et la surface réellement exposée, en continu et avec des entrées horodatées et signées. C'est regarder sa propre surface avec les yeux de l'adversaire, la promesse de l'EASM, détaillée dans qu'est-ce que l'EASM. CT ne couvre pas tout pour autant : une PKI interne, un service en HTTP nu ou un certificat auto-signé n'y apparaissent pas. Il se complète par du DNS passif, du scan de ports et de l'OSINT, et la mesure de ce que la découverte passive d'actifs rapporte vraiment montre qu'aucune source unique ne suffit, ce que confirme la revue des outils OSINT et de leur périmètre.

En bug bounty, le pivot par certificat déterre des apex secondaires, des préproductions et des origines derrière CDN, le genre de surface sous-explorée où dorment les failles. Mais découvrir n'est pas autoriser. Un programme de bug bounty, avec ses plateformes et ses règles de triage, définit un scope précis : un apex remonté par O= et absent de la liste est hors scope, même s'il appartient manifestement à la cible. Documentez-le et signalez-le au programme plutôt que de l'attaquer.

De la découverte à la preuve

Un sous-domaine de staging déterré par CT peut héberger un panel d'administration sans MFA, une copie de base avec des données réelles, une API de debug. Reste à le prouver sans rien casser : c'est la frontière entre lister une exposition et démontrer son exploitabilité, creusée dans pentest vs scan de vulnérabilité. Un inventaire dit "ça existe", un pentest web blackbox dit "voilà ce qu'on en fait". Et pour les failles qui ne renvoient rien dans la réponse, une SSRF sur cette API de staging par exemple, la preuve passe par un canal hors bande, comme celui construit dans le serveur OOB maison.

À retenir

• Au 6 octobre 2026, une société médiane du SBF 120 avait laissé 139 noms d'hôtes dans les journaux CT en 24 mois, sur son seul domaine principal (quartiles 38 et 479).
• En médiane, 12,1 % de ces noms désignent un environnement dev, test, staging, preprod ou recette, et 101 sociétés sur 119 en ont au moins un. Les wildcards ne représentent que 2,6 % des noms en médiane.
• 117 sociétés sur 119 ont au moins un certificat Let's Encrypt : l'émission automatisée est partout, donc l'inventaire doit partir des journaux, pas des bons de commande.
• Un nom dans CT ne prouve ni l'existence actuelle ni l'exposition du service : il désigne une vérification à faire. Et la sortie JSON de crt.sh peut tronquer l'historique d'un grand domaine.
• Le pivot par empreinte et par O= relie des actifs et des apex inconnus à la cible, à condition que le certificat soit auto-géré. Découvrir n'est jamais autoriser.

Votre vrai périmètre n'est pas dans votre tableur : il est dans les journaux CT, et il grossit à chaque certificat émis. Le surveiller est le métier de la plateforme EASM, qui corrèle le flux CT au reste de votre surface exposée. Pour en parler avec un humain, la page contact est là.

Questions fréquentes