2026-07-21 · RECHERCHE · L'équipe Offensive Technology

Combien de grands domaines restreignent qui peut délivrer leurs certificats ?

En bref : Nous avons pris les 1 000 domaines les plus fréquentés d'Internet, résolu 994 d'entre eux et lu l'enregistrement CAA publié par chacun dans le DNS. Seuls 32.4% publient un enregistrement CAA. Les 67.6% restants ne placent aucune limite au niveau du DNS sur l'autorité de certification qui peut délivrer un certificat TLS pour leur nom. Ainsi, n'importe laquelle des dizaines d'AC publiquement reconnues pourrait, en principe, être trompée ou compromise pour délivrer un certificat valide pour eux, sans que rien dans la publication du domaine ne s'y oppose. Parmi la minorité qui configure un enregistrement CAA, moins de la moitié (42.5%) demande à être informée lorsqu'une AC voit une requête qui enfreint sa politique, ce qui est la ligne unique transformant le CAA d'une simple clôture silencieuse en alarme. Chaque chiffre provient de requêtes DNS publiques passives que nous avons exécutées nous-mêmes sur une liste publiée des sites les plus populaires. Aucun hôte n'a été contacté, rien n'a été scanné. Voici exactement comment nous l'avons mesuré, ainsi que ce que cela prouve et ne prouve pas.

Le résultat en un graphique

Pour chaque domaine, nous avons posé trois questions publiques. Publie-t-il un enregistrement CAA ? Si oui, nomme-t-il un contact de signalement (iodef) pour qu'une AC puisse l'avertir des violations ? Et contrôle-t-il la délivrance de certificats génériques (wildcard) séparément de la délivrance ordinaire ? Chaque niveau est plus restreint que le précédent :

Ce que fait réellement un enregistrement CAA

Chaque navigateur fait confiance à des dizaines d'autorités de certification et, par défaut, n'importe laquelle d'entre elles peut délivrer un certificat TLS valide pour n'importe quel domaine. C'est pratique, mais c'est aussi le point faible : si une seule AC est trompée lors d'un contrôle de validation de domaine défaillant, contrainte ou compromise, elle peut générer un certificat pour un nom qui n'est pas son client, et le navigateur l'acceptera. La délivrance abusive de certificats n'a rien de théorique ; c'est précisément la raison pour laquelle le secteur a mis en place des défenses en profondeur autour de la délivrance.

CAA (RFC 8659, qui a remplacé le précédent RFC 6844) constitue le volet DNS de cette défense. Un domaine publie un court enregistrement qui stipule, en substance : "seules ces AC peuvent délivrer des certificats pour moi." Depuis qu'un vote du CA/Browser Forum a pris effet le 8 septembre 2017, chaque AC publique est tenue de lire cet enregistrement au moment de la délivrance et de refuser d'émettre un certificat non autorisé par l'enregistrement. C'est un contrôle rare, à la fois gratuit à configurer et activement appliqué par le tiers.

Un ensemble d'enregistrements CAA comporte quelques éléments clés :

• issue désigne une AC autorisée à délivrer des certificats ordinaires, par exemple 0 issue "letsencrypt.org". Un issue ";" suivi d'un point-virgule signifie qu'aucune AC ne peut délivrer de certificat.
• issuewild régit les certificats génériques (*.example.com) séparément, ce qui est important car un seul certificat générique présente un rayon d'impact plus large qu'un simple nom d'hôte.
• iodef fournit une URL ou une boîte mail où une AC peut signaler une requête violant la politique. C'est la différence entre bloquer silencieusement une requête malveillante et être informé qu'une tentative a eu lieu.

Les deux tiers des domaines les plus fréquentés ne configurent rien

Le chiffre le plus frappant est cette absence. Sur les 994 domaines qui ont été résolus, 672 (67.6%) ne publient aucun enregistrement CAA. Pour ces domaines, le DNS ne précise pas qui peut délivrer leurs certificats, donc la réponse est : n'importe quelle AC présente dans le magasin de confiance public. Ce n'est pas une violation et ce n'est pas, en soi, une vulnérabilité. C'est une occasion manquée de réduire la surface d'attaque pour une catégorie d'attaques, au moyen d'un enregistrement qui ne coûte qu'une ligne et aucun argent.

Parmi les 322 domaines qui publient un enregistrement CAA, la plupart ne s'appuient pas sur un seul fournisseur : les deux tiers (66.5%) autorisent plus d'une autorité de certification, avec une médiane de trois. C'est normal et judicieux pour une organisation qui utilise différentes AC pour différents systèmes, un fournisseur PKI interne ici, une AC publique pour le site marketing là. Ce qui ressort, c'est le manque de signalement. Seuls 42.5% des entités qui publient définissent un contact iodef, donc la majorité a construit une clôture sans alarme : une AC qui reçoit une requête enfreignant leur politique la refusera, mais le propriétaire du domaine ne saura jamais que quelqu'un a essayé. Cela rejoint directement le même thème que notre étude sur l'exposition de l'authentification des e-mails sur ces domaines, où le schéma était le même : l'enregistrement de base est configuré plus souvent que le paramètre qui déclencherait réellement une alarme.

Comment nous avons mesuré cela

Un sceptique doit pouvoir reproduire cela à partir de zéro, voici donc l'intégralité de la méthode, sans rien cacher.

• La population. Nous avons utilisé la liste Tranco (liste N29KW, générée le 20 juillet 2026), un classement de sites populaires orienté recherche qui établit une moyenne de plusieurs fournisseurs sur 30 jours pour résister aux manipulations quotidiennes. Il est publié, versionné et citable en permanence, ce qui importe davantage pour la reproductibilité que la liste d'un seul fournisseur. Voir tranco-list.eu et le papier NDSS 2019 sous-jacent.
• L'échantillon. Les 1 000 premiers domaines de cette liste. 994 ont été résolus vers des serveurs de noms actifs ; 6 ne l'ont pas été et ont été écartés, le dénominateur est donc 994.
• Les requêtes. Pour chaque domaine, une requête dig CAA <domain> auprès de résolveurs récursifs publics, ainsi qu'une requête NS comme contrôle de disponibilité. Nous avons analysé la réponse à la recherche des balises issue, issuewild et iodef et les avons lues à l'apex du domaine, ce qui constitue la métrique d'adoption conventionnelle et l'enregistrement qu'une AC consulte pour le domaine enregistré.
• Ce que nous n'avons pas fait. Nous n'avons jamais demandé de certificat, ne nous sommes connectés à aucun serveur web ni n'avons rien scanné. Lire un enregistrement DNS public est une simple consultation, pas un sondage. C'est la même frontière entre un contrôle et une infraction qui régit chaque mission que nous menons.
• Ce que nous avons conservé. Des décomptes globaux et des pourcentages uniquement. Les résultats par domaine sont restés en mémoire pendant l'exécution et n'ont jamais été écrits sur disque. Aucun domaine n'est nommé. Nous avons uniquement enregistré si une balise iodef était présente, jamais sa valeur de contact, et n'avons recueilli aucune donnée personnelle ; les domaines et leurs enregistrements DNS ne sont pas des données personnelles.

Un regard neutre sur les entités autorisées

Un agrégat mérite d'être présenté car il décrit les autorités de certification, et non les sites que nous avons mesurés, et ne nomme aucun domaine. Parmi les 322 domaines publiant un enregistrement CAA, ces émetteurs sont ceux qui apparaissent le plus souvent dans les listes autorisées. À lire comme une carte de popularité des AC de confiance, et non comme un tableau de score de la sécurité de quiconque :

Ce que cela ne prouve pas

Des limites honnêtes, car un chiffre sans ses mises en garde n'est que du marketing.

• Il s'agit d'un instantané. Le DNS change tous les jours. Ces chiffres décrivent la situation au 20 juillet 2026, pas une tendance. Un domaine sans CAA aujourd'hui peut en ajouter un la semaine prochaine.
• L'absence de CAA n'est pas une vulnérabilité. C'est un contrôle qui n'a pas été activé. De nombreuses organisations bien gérées se passent de CAA et s'appuient sur d'autres couches. Nous mesurons l'adoption d'une étape de durcissement, nous ne comptons pas les failles.
• Le CAA n'est pas un mur. Il ne contraint que les AC qui le respectent, ne révoque pas les certificats déjà délivrés et ne peut rien si une AC que vous avez autorisée est compromise. Il réduit l'ensemble des émetteurs pouvant agir, et iodef signale les tentatives. Détecter une délivrance inattendue après coup est le rôle de la surveillance Certificate Transparency, qui se combine naturellement avec le CAA.
• Apex uniquement. Nous avons lu l'enregistrement CAA à l'apex de chaque domaine enregistré. Étant donné que le CAA est évalué en remontant l'arbre DNS, un sous-domaine peut en hériter ou le surcharger ; nous n'avons pas énuméré les sous-domaines, et nous ne le ferions pas, car cela commencerait à ressembler à la cartographie du SI de quelqu'un plutôt qu'à la lecture d'un simple enregistrement public.
• Le haut de la liste est hétérogène. Les domaines les plus fréquentés incluent des CDN et des infrastructures dont les pratiques en matière de certificats diffèrent de celles d'une entreprise classique. La population étudiée correspond aux "noms à fort trafic", et non aux "entreprises comme la vôtre". Prenez donc ces pourcentages comme un aperçu global, et non comme une référence pour votre propre risque.

Pourquoi un attaquant s'y intéresse, et pourquoi vous devriez aussi

Un certificat falsifié mais valide est un outil puissant. Il permet à un attaquant déjà en position d'intercepter le trafic, via un chemin réseau détourné ou un résolveur empoisonné, de présenter votre domaine avec un cadenas auquel le navigateur fait confiance, sans aucun avertissement pour le visiteur. La délivrance abusive est rare précisément parce que les AC sont auditées et que le CAA est appliqué, mais cette rareté ne doit pas faire oublier que hausser le niveau d'exigence ne coûte qu'un simple enregistrement DNS. Publier un enregistrement CAA écarte de l'équation toutes les AC que vous n'utilisez pas, et ajouter un contact iodef permet d'être averti si quelqu'un tente d'obtenir un certificat auprès d'une AC non autorisée, plutôt que de l'apprendre par un client.

La solution est peu spectaculaire et pratiquement gratuite : listez les AC que vous utilisez réellement, ajoutez une entrée issuewild si vous délivrez des certificats génériques et configurez une boîte mail iodef que vous consultez. La partie difficile n'est jamais la modification DNS. C'est de connaître chaque endroit où votre organisation obtient légitimement des certificats, afin qu me réactiver le CAA ne rompe pas silencieusement un renouvellement oublié. C'est une question de discernement, le même discernement qui permet de savoir lesquelles de vos surfaces exposées comptent vraiment et lesquelles ne sont que du bruit.

Autorisation de certificats : réponses rapides

Qu'est-ce qu'un enregistrement CAA ?

Le CAA (Certification Authority Authorization, RFC 8659) est un enregistrement DNS indiquant quelles autorités de certification sont autorisées à délivrer des certificats TLS pour un domaine. Depuis septembre 2017, le CA/Browser Forum exige des AC publiques qu'elles le vérifient et refusent toute délivrance non autorisée par l'enregistrement. L'absence d'enregistrement CAA signifie l'absence de restriction : n'importe quelle AC publique peut délivrer un certificat.

Quelle proportion des grands domaines publie un enregistrement CAA ?

Lors de notre analyse de juillet 2026 sur les 1 000 domaines les plus fréquentés (994 résolus), seuls 32.4% publiaient un enregistrement CAA ; 67.6% n'en publient aucun. Parmi les entités qui publient, 42.5% définissent également un contact de signalement iodef et 36% contrôlent la délivrance de certificats wildcard séparément.

Un enregistrement CAA empêche-t-il toute délivrance abusive de certificats ?

Non. Il s'agit d'une défense en profondeur : il ne contraint que les AC qui le respectent, ne révoque pas les certificats déjà délivrés et n'empêche pas la compromission d'une AC autorisée. Il restreint les acteurs pouvant délivrer des certificats et, avec iodef, signale les tentatives. Associez-le à une surveillance Certificate Transparency.

Comment vérifier et configurer mon propre enregistrement CAA ?

Lisez-le avec dig CAA yourdomain.com. Pour en configurer un, autorisez uniquement les AC que vous utilisez (par exemple 0 issue "letsencrypt.org"), ajoutez une entrée issuewild si vous utilisez des certificats génériques, et ajoutez 0 iodef "mailto:[email protected]" pour qu'une AC puisse signaler les violations. Vérifier votre propre enregistrement est une consultation passive, c'est donc sûr et gratuit.

Lectures similaires

• À quel point les grands domaines sont-ils exposés à l'usurpation d'e-mail ?
• Que peuvent réellement voir les attaquants sur votre entreprise ?
• Pourquoi l'autorisation précède tout test