2026-10-06 · RECHERCHE · L'équipe Offensive Technology

Comment les journaux de Certificate Transparency font fuiter des sous-domaines internes

Certificate Transparency fait-il fuiter des noms d'hôtes internes ? Oui, couramment. Nous avons analysé les journaux CT publics de 702 domaines de premier plan via crt.sh, la même recherche gratuite accessible à tous, et constaté que 65.5% ont enregistré au moins un nom d'hôte à consonance interne: a dev., staging., vpn., admin., jira., ou vault.-style, un nom qui était presque certainement destiné au personnel, pas à l'internet public. Aucun hôte n'a été scanné, résolu ou contacté pour obtenir ce chiffre. CT est un journal public, en ajout seul, de chaque certificat jamais émis par une CA publique, et il suffit qu'un nom reçoive un seul certificat publiquement approuvé pour devenir un enregistrement permanent et consultable. C'est la première démarche d'un attaquant avant même de commencer le moindre scan, et la plupart des organisations livrent gratuitement leur convention de nommage interne.

Pourquoi un journal public expose des noms à vocation privée

Certificate Transparency existe pour une bonne raison : empêcher une CA d'émettre discrètement un certificat illégitime pour un domaine non autorisé, car chaque certificat émis devient visible par le propriétaire du domaine et le public. Chrome et les autres navigateurs imposent la journalisation CT aux CA publiquement approuvées depuis 2018 en vertu de la RFC 6962. C'est une véritable avancée en matière de sécurité pour l'écosystème. L'effet secondaire est que CT journalise également le nom d'hôte lui-même, et ce nom d'hôte est souvent l'élément le plus révélateur de l'enregistrement.

Les systèmes internes obtiennent des certificats publics pour une raison banale et ordinaire : personne ne veut d'avertissement du navigateur lorsque les collaborateurs accèdent au portail VPN ou à l'instance Jira interne, même si la résolution DNS de ce nom ne fonctionne que sur le réseau d'entreprise ou à travers un tunnel VPN. Le nom reçoit donc un véritable certificat de Let's Encrypt, DigiCert ou d'une autre CA publique, exactement comme un site exposé sur internet. Le certificat remplit son rôle en silence. L'effet secondaire est que vpn.example.com ou staging-admin.example.com est désormais lisible de manière permanente par quiconque interroge CT pour example.com, via un outil gratuit comme crt.sh, sans la moindre interaction avec l'infrastructure de example.com.

Les données : ce que journalisent 702 domaines de premier plan

Nous avons interrogé crt.sh pour un échantillon de la liste des meilleurs sites Tranco (liste 94Y82), un domaine à la fois avec mise en cache et temporisation pour ménager le service, et nous avons classé le premier label DNS de chaque nom journalisé selon neuf catégories de nommage interne conventionnel : accès distant, authentification/identité, non-production, devops/CI, collaboration interne, observabilité, admin/gestion, secrets/infrastructure, et noms explicitement internes. 702 des 1,000 domaines demandés ont abouti ; 660 avaient un historique CT. Les résultats par domaine n'ont été conservés qu'en mémoire pendant l'exécution et jamais enregistrés sur disque, rien ici ne nomme donc d'organisation spécifique. Il s'agit de pourcentages globaux, pas d'une liste.

Les noms de non-production dominent : 58.8% des domaines ont journalisé un nom en dev., staging., test. ou similaire. C'est le résultat le moins surprenant et le moins dangereux en soi, le simple fait de nommer un environnement de staging ne constituant pas une vulnérabilité. Ce qui est plus intéressant, c'est la présence marquée de catégories plus dangereuses dans la liste. 20.4% ont journalisé un nom lié aux secrets ou à l'infrastructure comme vault., consul. ou k8s., et 21.8% ont journalisé un nom lié à l'accès distant comme vpn. ou citrix. Ce sont les catégories où le nom indique lui-même à un attaquant le produit précis pour lequel chercher une CVE connue.

Les préfixes individuels racontent la même histoire avec une résolution plus fine. Voici les douze labels les plus fréquents que nous avons identifiés, par part de l'échantillon de 702 domaines :

Le préfixe vpn. représente à lui seul 12.8% de l'ensemble de l'échantillon, ce qui signifie qu'environ un des domaines les plus fréquentés d'internet sur huit a indiqué au monde entier, via un journal public auquel il n'a même pas eu besoin de toucher, qu'il utilise un produit d'accès distant spécifique sous un nom précis. Combinez cela à l'identification de version possible dès qu'un nom d'hôte est résolu, et un attaquant passe d'une connaissance nulle à une liste priorisée de cibles sans envoyer un seul paquet vers la cible.

Cela s'arrête rarement à un seul nom

Les fuites ne se limitent pas uniformément à un seul nom par domaine. Sur les 460 domaines présentant une fuite, 113 ont fait fuiter un nom dans exactement une catégorie, mais les autres ont présenté des fuites dans plusieurs catégories à la fois : 65 domaines touchent trois catégories, 42 en touchent six, et 22 domaines ont fait fuiter un nom dans l'ensemble des neuf catégories suivies. Dès qu'une organisation prend l'habitude d'attribuer de véritables certificats publics à ses outils internes, cette habitude a tendance à s'étendre à tous les outils internes qu'elle exploite, et pas à un seul. Pour un attaquant, un domaine qui présente des fuites étendues a bien plus de valeur qu'un domaine ne révélant qu'un seul nom, car il cartographie l'infrastructure de dev, d'authentification et d'administration en une seule requête.

Comment vérifier votre propre domaine

Cela prend moins d'une minute et ne nécessite aucun outil hormis un navigateur ou curl, car vous consultez le même registre public que nous.

• Interrogez directement crt.sh. Ouvrez https://crt.sh/?q=%25.yourdomain.com&output=json et examinez chaque nom d'hôte renvoyé. C'est tout ce que CT a enregistré pour votre domaine, y compris des noms émis il y a des années pour des serveurs potentiellement déclassés depuis longtemps.
• Filtrez la sortie pour repérer les labels à consonance interne. Cherchez spécifiquement les préfixes du tableau ci-dessus : dev, test, staging, admin, auth, vpn, internal, vault, jenkins, gitlab, grafana, ainsi que leurs variantes proches. Tout ce qui correspond est définitivement public, que le nom soit actuellement résolu ou non.
• Considérez chaque correspondance comme déjà connue d'un attaquant. Il est impossible de supprimer rétroactivement un certificat du journal. La seule option consiste à considérer le nom comme public, à s'assurer que le service sous-jacent ne repose pas sur l'obscurité, et à maintenir ses correctifs et son contrôle d'accès au même niveau qu'un actif exposé sur internet, car pour un attaquant qui lit CT, c'en est déjà un.

Ce que cela ne prouve pas

Des limites en toute transparence, car un chiffre sans ses nuances n'est que du marketing.

• Un nom journalisé n'est pas la preuve d'un service actif, joignable ou vulnérable. Nous avons uniquement recherché des correspondances textuelles de noms d'hôtes dans CT. Nous n'avons résolu aucun nom, ne nous sommes connectés à aucun hôte et n'avons pas testé si le service sous-jacent existe toujours. Certains de ces noms pointent vers des infrastructures déclassées ; d'autres ne pointent vers rien du tout.
• Il s'agit d'un échantillon de 702 domaines, pas de l'ensemble d'internet. Les sites de premier plan de Tranco favorisent les grandes organisations établies disposant de suffisamment d'infrastructures pour avoir des environnements de dev et de staging. Une méthodologie de classement différente ou un échantillon plus large modifierait les pourcentages exacts.
• Il s'agit d'un instantané. Ces chiffres décrivent l'état de CT au moment de notre lecture du 24 juillet 2026. Les organisations ajoutent et retirent des noms d'hôtes internes en continu, les chiffres exacts évoluent donc au fil du temps même si le comportement de fond reste identique.
• La correspondance par préfixe est heuristique, pas certaine. Un label comme admin désigne généralement un panneau d'administration interne, mais peut parfois être le nom d'un produit légitime exposé au public. Nous avons optimisé la liste des catégories pour le nommage conventionnel et non pour une précision parfaite, ces pourcentages doivent donc être considérés comme un signal fort, et non comme un inventaire exact.
• Cela mesure l'exposition d'un nom, pas son exploitabilité. Savoir que vpn.example.com existe relève de la reconnaissance, pas de la compromission. Ce que cela offre à un attaquant, c'est une liste priorisée et économique en efforts de ce qu'il faut examiner ensuite.

Foire aux questions

Les attaquants peuvent-ils utiliser les journaux de Certificate Transparency pour trouver des sous-domaines ?

Oui. Chaque certificat émis par une CA publique est consigné dans les journaux en vertu de la RFC 6962, et n'importe qui peut effectuer des recherches gratuites dans ces journaux via crt.sh. Dans notre échantillon de 702 domaines, 65.5% des organisations avaient journalisé au moins un nom d'hôte à consonance interne de cette manière, sans la moindre interaction avec leur infrastructure.

Les journaux CT peuvent-ils révéler des noms d'hôtes internes qui n'étaient pas censés être publics ?

Oui. Il suffit qu'un nom reçoive un seul certificat publiquement approuvé, souvent émis pour éviter un avertissement du navigateur aux collaborateurs, pour devenir un enregistrement public permanent. Le serveur sous-jacent n'a pas besoin d'être accessible depuis internet pour que le nom fuite.

Quelles informations sont exposées dans le champ Subject Alternative Name d'un certificat ?

Le champ SAN liste chaque nom d'hôte couvert par un certificat. Un seul certificat multi-domaines peut exposer des dizaines de noms d'un coup, tous interrogeables dans CT dès l'émission du certificat.

Comment découvrir des sous-domaines à l'aide de crt.sh ?

Interrogez https://crt.sh/?q=%25.yourdomain.com&output=json. Cela renvoie chaque certificat journalisé pour votre domaine et ses sous-domaines, y compris ceux émis pour des serveurs qui n'existent peut-être plus. Il s'agit d'une recherche passive en lecture seule dans un journal public, la méthode exacte employée ici.

Un certificat wildcard empêche-t-il les sous-domaines d'apparaître dans les journaux CT ?

Un certificat wildcard pour *.example.com ne journalise que la chaîne wildcard, masquant ainsi le label du sous-domaine spécifique. Mais dès qu'un service reçoit son propre certificat nommé individuellement, ce nom est journalisé même si tout le reste se trouve derrière un wildcard.

Comment empêcher les noms d'hôtes internes de fuiter dans Certificate Transparency ?

Utilisez une CA interne et privée pour les noms qui ne doivent jamais être publics, car seules les CA publiques sont tenues de journaliser dans CT. Privilégiez les certificats wildcard aux certificats feuilles nommés individuellement lorsque votre architecture le permet, et considérez tout ce qui figure déjà dans CT comme définitivement connu.

Les autorités de certification privées ou internes sont-elles exemptées de la journalisation dans Certificate Transparency ?

Oui. La journalisation CT est exigée pour les CA publiquement approuvées, pas pour les certificats en général. Un certificat provenant de votre propre CA interne, approuvé uniquement par vos appareils gérés, n'a jamais besoin d'apparaître dans un journal CT public.

Lectures complémentaires

• Que peuvent réellement voir les attaquants sur votre entreprise ? La question plus large de la surface d'attaque dont cet article traite un aspect.
• Combien de temps faut-il pour qu'un certificat apparaisse dans CT ? Même domaine crt.sh, la question du timing plutôt que celle du nommage.
• Certificate Transparency est-il déjà post-quantique ? Une couche différente du même écosystème de journaux publics, celle de la signature des points de contrôle au lieu du contenu des certificats.