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

Un certificat wildcard masque-t-il vos sous-domaines ?

Un certificat wildcard masque-t-il vos sous-domaines ? En grande partie, mais presque personne ne l'utilise réellement ainsi. Nous avons analysé le certificat actif de 660 domaines de premier plan via les mêmes journaux publics Certificate Transparency que n'importe qui peut interroger, et classé ce que chacun d'eux divulgue. 63.8% énumèrent au moins un sous-domaine réel par son nom dans des entrées SAN en clair, sans aucune protection par wildcard. Seuls 22.9% s'appuient uniquement sur un wildcard, masquant la structure de leurs sous-domaines comme la technologie le permet. Ajoutez les 11.1% qui font les deux à la fois, et 74.8% des certificats actuels sur les domaines majeurs divulguent un nom d'hôte spécifique, qu'ils disposent ou non d'un wildcard en parallèle. Un wildcard fonctionne parfaitement comme prévu. Presque personne ne le choisit pour cette raison.

Pourquoi il s'agit d'une décision, pas d'un simple comportement par défaut

Les certificats wildcard et SAN (Subject Alternative Name) résolvent le même problème, couvrir plusieurs noms d'hôte avec un seul certificat, de manières opposées. Un wildcard correspond à un motif : *.example.com est valide pour tout nom de premier niveau sous example.com, sans que ce nom n'apparaisse jamais sur le certificat lui-même. Un certificat SAN liste quant à lui explicitement les noms d'hôte, un seul certificat pouvant couvrir app.example.com, api.example.com, et admin.example.com en inscrivant les trois dans le champ SAN. Les deux approches sont standards, émises par toutes les CA publiques, et le sujet du certificat ne révèle pas si cette approche était un choix délibéré ou un effet secondaire de l'outillage.

L'effet secondaire est le cas le plus fréquent. L'émission automatisée et gratuite, telle qu'utilisée par la quasi-totalité des déploiements modernes, demande généralement un certificat pour le nom d'hôte exact configuré sur le serveur. Déployez dix sous-domaines avec dix requêtes de certificats automatisées distinctes, et vous obtenez dix certificats SAN, chacun enregistrant son propre nom, et jamais un wildcard unique couvrant les dix. Choisir un wildcard à la place est une étape supplémentaire que la plupart des équipes ne franchissent jamais, car la voie par défaut produit déjà un certificat fonctionnel.

Les données : ce que 660 certificats actuels choisissent réellement

Pour chacun des 660 domaines majeurs disposant d'un historique dans Certificate Transparency, nous avons extrait le certificat le plus récent déjà présent dans notre cache local (zéro nouvelle requête vers crt.sh pour cette analyse, en réutilisant le jeu de données de trois articles de recherche précédents) et lu ses champs Subject et SAN. Nous avons classé chaque certificat selon ce qu'il divulgue au-delà du couple classique et universel formé par le domaine nu et son adresse www. : une entrée wildcard sans rien d'autre, un wildcard accompagné de noms d'hôte explicites, des noms d'hôte explicites sans aucun wildcard, ou aucun des deux.

Les barres orange révèlent un nom d'hôte spécifique sur le certificat ; les barres bleu sarcelle ne le font pas. Seules la part de 22.9% strictement wildcard et la part de 2.3% limitée à l'apex, soit 25.2% de l'échantillon cumulé, gardent le nommage de leurs sous-domaines hors des registres publics. Les trois autres quarts des domaines livrent actuellement au moins un vrai nom de sous-domaine à quiconque consulte Certificate Transparency.

Il s'agit rarement d'un seul nom

Dès qu'un certificat divulgue une information, il a tendance à révéler bien plus qu'un simple nom d'hôte isolé. Parmi les 494 certificats mentionnant au moins un sous-domaine spécifique, le cas typique n'en liste qu'un ou deux, mais la distribution présente une longue traîne : le certificat le plus chargé de l'échantillon énumère 70 sous-domaines distincts, et 20 certificats (4.0% de tous les certificats avec divulgation) en listent dix ou plus, dont 9 en listant 25 ou plus. Un certificat de cette taille ne masque rien, il s'apparente plutôt à un sitemap public de l'infrastructure d'une organisation, émis en une seule requête et consigné dans un seul enregistrement.

Cette dernière ligne mérite que l'on s'y attarde. Un certificat de la catégorie "mixte" comporte 94 entrées wildcard distinctes associées à une seule clé, aux côtés d'entrées SAN explicites. Il s'agit très probablement d'une plateforme ou d'un fournisseur SaaS mutualisant la couverture wildcard de nombreux sous-domaines clients ou régionaux en une seule fois. C'est efficace sur le plan opérationnel. Cela signifie également qu'une seule clé privée, si elle venait à être compromise, serait valide pour chaque sous-domaine relevant de l'ensemble de ces 94 motifs simultanément, présents et futurs. L'usage du wildcard troque la confidentialité des sous-domaines contre un autre risque : l'étendue du rayon d'impact lié à une clé unique.

Pourquoi tout le monde n'utilise pas simplement un wildcard

Si un wildcard masque davantage d'informations, pourquoi seulement 22.9% de l'échantillon en utilise-t-il un exclusivement ? Quelques raisons pratiques à cela, dont aucune n'est une erreur en soi :

• L'automatisation privilégie par défaut le nommage explicite plutôt que le wildcard. Des outils comme Certbot demandent un certificat pour le nom d'hôte auquel le serveur répond déjà. Obtenir un wildcard à la place implique de prouver le contrôle du domaine via un challenge DNS-01, une étape supplémentaire nécessitant des outils additionnels que la plupart des déploiements évitent.
• Un wildcard ne couvre qu'un seul niveau. *.example.com correspond à app.example.com mais pas à a.app.example.com. Toute hiérarchie réelle de second niveau nécessite soit un second wildcard, soit des entrées explicites, ce qui pousse à nouveau les organisations vers l'énumération, même lorsqu'elles détiennent déjà un certificat wildcard.
• Le rayon d'impact d'une compromission de clé est bien réel. Une clé privée wildcard, une fois exposée, permet d'usurper l'identité de chaque sous-domaine qu'elle couvre en même temps. Une clé dédiée compromise n'a jamais couvert que son propre hôte. Les équipes gérant des sous-domaines sensibles et administrés séparément choisissent parfois délibérément des certificats explicites pour limiter ce rayon d'impact, même si cela se fait au détriment de la confidentialité de leurs sous-domaines.
• Certains audits exigent une couverture explicite. Certains processus de conformité et d'inventaire sont plus simples à mener avec un certificat qui liste individuellement chaque nom d'hôte couvert qu'avec un certificat qui applique une couverture via un motif.

Comment vérifier votre propre domaine

Cela prend moins d'une minute et ne nécessite rien d'autre qu'un navigateur, car cela revient à consulter le même registre public que celui que nous analysons.

• Interrogez crt.sh pour trouver votre certificat actuel. Ouvrez https://crt.sh/?q=yourdomain.com&output=json et examinez le champ name_value de l'entrée la plus récente, ou vérifiez directement le certificat de votre serveur avec openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Identifiez ce qu'il divulgue réellement. Une seule entrée *.yourdomain.com sans rien d'autre correspond à un certificat strictement wildcard. Tout le reste, le moindre hôte explicite au-delà du domaine nu et de www., est déjà public via CT, que vous possédiez par ailleurs un wildcard ou non.
• Faites un choix éclairé sur cet arbitrage. Si la confidentialité de vos sous-domaines prime sur le rayon d'impact en cas de compromission de clé pour votre architecture, privilégiez un wildcard et un flux d'émission DNS-01. Si ce n'est pas le cas, considérez a minima chaque entrée SAN explicite comme publique de manière définitive, et cessez de voir le fait de masquer un sous-domaine comme une mesure de sécurité.

Ce que cela ne prouve pas

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

• Nous avons analysé le certificat le plus récent par domaine, et non son historique complet. Un domaine a pu utiliser un wildcard pendant des années et n'ajouter que récemment une entrée SAN explicite, ou inversement. Il s'agit d'un instantané de l'état actuel de divulgation, pas d'une tendance historique immuable.
• Une entrée SAN explicite ne prouve pas que le service sous-jacent est actif ou joignable. Nous avons classé le texte du nom d'hôte présent sur un certificat, rien de plus. Certains sous-domaines explicites peuvent pointer vers une infrastructure qui n'existe plus.
• Il s'agit d'un échantillon de 660 domaines composé de sites importants et établis. Le classement des sites majeurs de Tranco surreprésente les organisations dont l'infrastructure justifie d'emblée l'usage de plusieurs noms d'hôte. Un échantillon différent modifierait la répartition exacte.
• Cela mesure la divulgation, pas l'exploitabilité. Connaître le nom d'un sous-domaine relève de la reconnaissance. Ce qu'un attaquant fait de ce nom dépend entièrement de ce qui tourne réellement derrière.

Foire aux questions

Un certificat wildcard masque-t-il les sous-domaines ?

Partiellement. Un wildcard pour *.example.com n'enregistre que la chaîne du motif générique, pas les libellés spécifiques. Cependant, dans notre échantillon, 63.8% des certificats actuels nomment malgré tout un vrai sous-domaine, et seuls 22.9% s'appuient uniquement sur un wildcard sans exposer de nom d'hôte explicite.

Des sous-domaines couverts par un wildcard peuvent-ils quand même apparaître dans les journaux Certificate Transparency ?

L'entrée wildcard elle-même n'apparaît que sous la forme du motif, sans nom spécifique. En revanche, dès qu'un certificat distinct nomme explicitement un hôte, ce nom est consigné dans son intégralité, même s'il existe par ailleurs un wildcard. 11.1% des certificats étudiés ici font les deux.

Quelle est la différence entre un certificat wildcard et un certificat SAN ?

Un wildcard couvre un motif, *.example.com, sans nommer aucun sous-domaine. Un certificat SAN liste explicitement des noms d'hôte spécifiques. L'émission automatisée génère par défaut des certificats SAN pour le nom d'hôte exact utilisé par un serveur, c'est pourquoi l'énumération, et non le wildcard, constitue le cas le plus courant.

Un certificat wildcard est-il plus sécurisé que le fait de lister explicitement chaque sous-domaine ?

Pour la confidentialité du nom des sous-domaines, oui. Pour le rayon d'impact en cas de compromission de la clé, pas nécessairement : une clé wildcard dérobée est valide pour tous les sous-domaines qu'elle couvre en même temps, alors qu'une clé compromise dédiée à un hôte ne couvre que cet hôte.

Que se passe-t-il si la clé privée d'un certificat wildcard est compromise ?

Un attaquant peut usurper l'identité de n'importe quel sous-domaine relevant de ce motif jusqu'à ce que le certificat soit révoqué et réémis partout où il était déployé. Dans notre échantillon, un certificat comporte 94 entrées wildcard distinctes sur une même clé, ce qui représente un rayon d'impact considérable si cette clé venait à être exposée.

Un wildcard couvre-t-il les sous-domaines de sous-domaines ?

Non. *.example.com correspond à a.example.com mais pas à a.b.example.com. Un nom de second niveau nécessite son propre wildcard ou une entrée SAN explicite, ce qui explique pourquoi les organisations énumèrent des noms d'hôte même lorsqu'elles disposent déjà d'un wildcard.

Comment les attaquants utilisent-ils les journaux Certificate Transparency pour énumérer des sous-domaines à partir des listes SAN ?

Chaque certificat émis par une CA publique est consigné conformément à la RFC 6962 et consultable gratuitement via crt.sh. Un certificat qui énumère les noms d'hôte fournit à un attaquant une cartographie prête à l'emploi de ses sous-domaines, sans aucun scan requis.

Faut-il choisir wildcard ou SAN pour des raisons de sécurité, et pas seulement de commodité ?

Si la confidentialité du nommage de vos sous-domaines importe, le wildcard constitue le choix par défaut le plus solide, et la plupart des organisations de cet échantillon ne font pas ce choix. Si vous énumérez, traitez chaque SAN explicite comme définitivement public, et évaluez le compromis lié au risque de compromission de clé avant de basculer.

Lectures recommandées

• Comment les journaux Certificate Transparency font fuiter des sous-domaines internes Même cache, la question du contenu : quelles catégories de noms d'hôte internes apparaissent réellement dès lors qu'un certificat en divulgue un.
• Combien de temps faut-il pour qu'un certificat apparaisse dans CT ? Même périmètre crt.sh, la question du délai au lieu de celle de la divulgation.
• La règle des certificats à 200 jours est-elle déjà entrée en vigueur ? Un troisième angle sur le même cache de 660 domaines : la durée de vie autorisée des certificats, et non ce qu'ils divulguent.