Vérificateur d’enregistrements CAA

Tapez un domaine ou un sous-domaine : vous voyez les enregistrements CAA qui s’y appliquent, où ils sont publiés, quelles autorités de certification peuvent émettre des certificats ordinaires et génériques, et les erreurs qui feraient refuser une autorité.

Les requêtes DNS vont directement de votre navigateur à des résolveurs publics (Cloudflare, Google) : nous ne voyons rien.

Ce que regarde le vérificateur

Les enregistrements qui s’appliquent: Une autorité cherche des enregistrements CAA sur le nom exact, puis sur chaque parent jusqu’au domaine. Le premier nom qui en a décide ; les autres sont ignorés. Le vérificateur suit le même chemin (RFC 8659).
issue et issuewild: « issue » liste les autorités autorisées à émettre. « issuewild » le remplace pour les certificats génériques ; sans lui, les génériques suivent « issue ». La valeur « ; » n’autorise personne.
iodef: L’adresse où une autorité peut signaler une demande qu’elle a refusée : une adresse mailto: ou https:. Facultatif, mais c’est ainsi que vous apprenez une tentative.
Syntaxe et drapeaux: Un enregistrement illisible, ou une étiquette inconnue marquée critique (drapeaux 128), fait refuser l’émission pour ce nom.

Comment lire le résultat

Aucun enregistrement CAA: N’importe quelle autorité de certification peut émettre pour le domaine. Rien n’est cassé ; vous n’utilisez simplement pas une restriction gratuite.
Une liste d’autorités: Elles seules peuvent émettre. Avant de changer de fournisseur de certificats ou d’activer un CDN ou une plateforme d’hébergement, ajoutez d’abord son autorité ici, sinon ses certificats ne se renouvelleront pas.
Des enregistrements hérités du parent: Un sous-domaine sans enregistrements CAA propres suit ceux du domaine. Un sous-domaine hébergé ailleurs peut avoir besoin des siens.

Les erreurs que l’on rencontre

Les messages que donnent les autorités de certification et les plateformes quand CAA bloque un certificat, et quoi faire.

CAA record for example.com prevents issuance

Pourquoi. Les enregistrements CAA qui s’appliquent au nom ne citent pas l’autorité sollicitée, souvent après un passage à une plateforme qui en utilise une autre (Let’s Encrypt, Google Trust Services, Sectigo…).

Correction. Ajoutez un enregistrement « issue » avec le nom que cette autorité documente (par exemple letsencrypt.org ou pki.goog), sur le domaine ou le sous-domaine concerné, puis redemandez le certificat.

SERVFAIL looking up CAA

Pourquoi. L’autorité n’a pas obtenu de réponse à sa question CAA : un serveur DNS qui ne répond pas au type CAA, ou un DNSSEC cassé. Elle refuse alors dans la plupart des cas, et toujours quand la zone est signée avec DNSSEC, même si aucun enregistrement CAA n’existe.

Correction. Vérifiez que chaque serveur de noms de la zone répond aux requêtes CAA (une réponse vide convient, une erreur non), et que DNSSEC valide.

Wildcard certificate refused

Pourquoi. Un enregistrement « issuewild » existe et ne cite pas l’autorité, ou vaut « ; » : il remplace « issue » pour les noms génériques.

Correction. Ajoutez l’autorité à « issuewild », ou retirez les enregistrements « issuewild » pour que les génériques suivent de nouveau « issue ».

Questions

Un enregistrement CAA est-il obligatoire ?

Non. Les autorités doivent le consulter depuis 2017, mais un domaine sans CAA est valide : chacun peut émettre. En publier un limite les dégâts d’une erreur ou d’un compte compromis chez une autorité que vous n’utilisez pas.

CAA touche-t-il les certificats déjà émis ?

Non. Il est lu à l’émission ou au renouvellement d’un certificat, pas par les navigateurs. Un certificat existant reste valide jusqu’à son expiration.

Quel nom écrire pour mon autorité ?

Celui que l’autorité documente, pas sa marque : letsencrypt.org, pki.goog, digicert.com, sectigo.com, amazon.com… Le vérificateur nomme les autorités qu’il reconnaît.

Envoyez-vous quelque chose à vos serveurs ?

Non. Les requêtes vont de votre navigateur à des résolveurs publics (Cloudflare, Google) ; nous ne voyons ni le domaine ni le résultat.