Le CA/Browser Forum a voté pour rendre les extensions ACME CAA obligatoires à partir de mars 2027. Ce changement constitue l'un des derniers éléments nécessaires pour permettre une validation de domaine solide et cryptographiquement vérifiée au sein du Web PKI. Dans cet article de blog, nous expliquons pourquoi le Web PKI n'offre pas une assurance suffisante pour les sites web à forte visibilité, et comment DNSSEC, ACME et CAA peuvent être combinés pour parvenir à une validation cryptographique robuste de l'émission des certificats.
Convergence de DNSSEC et du Web PKI
Tout le monde n'apprécie pas DNSSEC, mais il apporte une fonctionnalité de sécurité essentielle que l'on ne trouve nulle part ailleurs. Les entreprises qui l'activent sur leurs noms de domaine garantissent l'intégrité de la résolution DNS. Certains estiment que le Web PKI fonctionne très bien tel quel, et c'est vrai, mais uniquement pour le cas d'usage courant : protéger des sites web qui ne font pas l'objet de menaces sérieuses. En résumé, les sites web à forte visibilité ont besoin d'une meilleure sécurité.
Pendant longtemps, les partisans de DNSSEC ont soutenu qu'il pourrait remplacer le Web PKI. Leur raisonnement était le suivant : une fois l'intégrité de la résolution DNS assurée, on obtient une propriété de sécurité sur laquelle on peut s'appuyer pour faire fonctionner les certificats X.509 sans autorités de certification. C'est vrai, mais seulement en théorie. En pratique, DNSSEC souffre de divers problèmes de conception et d'exploitation qui compliquent son adoption à grande échelle. Résultat, après de nombreuses années, son taux de prise en charge est loin d'être suffisant. Le Web PKI et les autorités de certification sont donc là pour durer.
Néanmoins, les organisations qui ont besoin d'une sécurité X.509 publique robuste n'ont d'autre choix que de déployer DNSSEC pour bénéficier de ses fonctionnalités uniques.
En 2025, le CA/Browser Forum, l'organisme qui régit l'émission des certificats, a décidé d'intégrer la validation DNSSEC au processus de validation de domaine. Cette exigence est devenue obligatoire en mars 2026 et a permis, pour la première fois, une validation cryptographique robuste de l'émission des certificats.
Les faiblesses à la racine du Web PKI
Le Web PKI est la PKI publique la plus strictement encadrée, avec des règles et des contrôles élaborés. C'est un écosystème que nous améliorons depuis des décennies. Cependant, à sa base, il présente deux problèmes majeurs. Ils rendent le système plus facile à utiliser, mais cela se paie par des exigences de sécurité assouplies.
Premièrement, il n'existe aucune authentification du demandeur de certificat. N'importe qui, dans le monde, peut demander un certificat pour n'importe quel nom de domaine ; si le processus de validation aboutit, le certificat sera émis au demandeur, même si le propriétaire du domaine ne l'a pas autorisé.
Deuxièmement, lorsqu'un certificat est demandé, l'autorité de certification effectue la validation de domaine via des échanges BGP, DNS et réseau non sécurisés. Toute personne capable d'interférer avec l'un de ces trois éléments peut compromettre la validation de domaine.
Si l'on ajoute DNSSEC à cet ensemble, cela permet de sécuriser le DNS, mais les deux autres aspects (BGP et trafic réseau en clair) restent vulnérables. Il faut donc trouver un moyen astucieux : faire en sorte que les décisions clés passent uniquement par DNSSEC et empêcher l'utilisation de tout autre moyen.
L'autorisation de l'autorité de certification
Les faiblesses du Web PKI peuvent être corrigées grâce à une norme appelée Certification Authority Authorization (CAA), définie dans le RFC 8659. La CAA est conçue pour permettre aux propriétaires de domaines de publier leurs politiques d'émission de certificats.
La version de base de la CAA est obligatoire depuis septembre 2017, mais elle ne suffit pas à répondre à nos besoins. Un autre document (RFC 8657) fait le lien entre le protocole ACME, destiné à l'émission automatisée de certificats, et la CAA, en ajoutant la prise en charge de permissions granulaires.
Grâce aux extensions ACME CAA, nous pouvons résoudre les deux problèmes évoqués précédemment, à l'aide d'un simple enregistrement de ressource CAA dans notre DNS, qui ressemble à ceci :
example.com. CAA 0 issue "letsencrypt.org;
accounturi=https://acme-v02.api.
letsencrypt.org/acme/acct/1726001367;
validationmethods=dns-01"Que fait cet enregistrement ?
À gauche, nous voyons le nom de domaine pour lequel nous souhaitons contrôler l'émission de certificats, ici example.com. À droite, nous avons trois contrôles. Le premier est l'identité d'une autorité de certification autorisée à émettre des certificats pour ce nom de domaine, ici letsencrypt.org.
Le deuxième contrôle est l'instruction accounturi, qui restreint l'émission au seul compte ACME nommé. Étant donné qu'ACME utilise toujours le chiffrement et une authentification cryptographique forte pour les comptes ACME, cette section garantit que seuls les utilisateurs autorisés peuvent demander des certificats pour ce nom de domaine.
Le troisième contrôle est l'instruction validationmethods, qui restreint l'émission à une seule méthode de validation de domaine basée sur le DNS. Lorsque DNSSEC est activé pour un nom de domaine, cette section garantit que toutes les opérations de validation de domaine sont cryptographiquement sécurisées. Ainsi, les autres méthodes non sécurisées deviennent sans importance ; l'autorité de certification ne les acceptera de toute façon jamais.
Peut-on utiliser les extensions ACME CAA dès maintenant ?
Les extensions ACME CAA existent depuis 2019, et certaines autorités de certification (par exemple Let's Encrypt, Google Trust Services, entre autres) les prennent déjà en charge. Ainsi, en théorie, vous auriez pu bénéficier de contrôles d'émission renforcés dès mars 2026, date à laquelle DNSSEC est devenu obligatoire pour la validation de domaine. En pratique, tant qu'une fonctionnalité n'est pas intégrée aux Baseline Requirements, les autorités de certification hésitent toujours à s'y engager pleinement. En effet, chaque nouvelle fonctionnalité alourdit leur charge de travail et complexifie leur mission. Le non-respect d'une politique écrite pourrait conduire à une émission de certificat non conforme.
L'équipe Chrome est depuis longtemps une fervente défenseure de l'automatisation. Le soutien à l'automatisation occupe une place centrale dans leur Root Program Policy, et, à ce titre, dans les exigences relatives à ACME et aux extensions ACME CAA. En février 2026, la politique a été modifiée afin d'exiger la prise en charge d'ACME CAA pour toutes les autorités de certification prenant en charge ACME.
En mai 2026, le CA/Browser Forum a voté (dans le cadre du Ballot SC-098v2) pour étendre officiellement la prise en charge de la CAA et rendre les extensions ACME CAA (RFC 8657) obligatoires pour toutes les autorités de certification, à compter de mars 2027.
Vous pouvez d'ores et déjà utiliser les extensions ACME CAA si vous travaillez avec des autorités de certification qui les prennent en charge. Dès l'année prochaine, cette fonctionnalité sera largement prise en charge, et vous aurez le choix parmi plusieurs autorités de certification.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.