Enregistrement CAA : choisir qui peut émettre vos certificats

Techniquement, n'importe quelle autorité de certification reconnue publiquement peut émettre un certificat pour n'importe quel domaine. Le système repose sur le fait que chaque AC valide correctement le contrôle du domaine, et l'histoire offre des exemples où cela a mal tourné. Un enregistrement CAA (Certification Authority Authorization) est votre moyen de restreindre le champ : un enregistrement DNS qui dit « seules ces AC peuvent émettre des certificats pour ce domaine ». Une AC qui n'y figure pas doit refuser.

Cela ne coûte rien, prend cinq minutes, et n'a qu'une seule façon de vous nuire : oublier son existence quand vous changez d'AC. Ce guide traite les deux volets.

Ce que CAA fait et ne fait pas

CAA est défini par la RFC 8659 (qui a remplacé la RFC 6844 d'origine) et, depuis septembre 2017, les Baseline Requirements du CA/Browser Forum obligent toute AC reconnue publiquement à vérifier CAA avant d'émettre.

Il est vérifié par l'AC, au moment de l'émission. Les navigateurs ne le consultent jamais. Un certificat émis alors que CAA l'autorisait reste valide si vous modifiez l'enregistrement ensuite.
Pas d'enregistrement CAA signifie aucune restriction. Toute AC peut émettre, comme avant.
Il réduit le risque d'émission abusive via une AC que vous n'utilisez pas, par exemple par quelqu'un qui contrôle brièvement un serveur web ou une boîte e-mail et tente sa chance auprès d'une AC à la méthode de validation plus faible. Il n'arrête pas un attaquant qui contrôle votre DNS, puisqu'il peut aussi modifier l'enregistrement CAA.
Ce n'est ni un mécanisme de révocation, ni un substitut à la surveillance des journaux de Certificate Transparency.

Anatomie d'un enregistrement CAA

example.com.   3600   IN   CAA   0 issue "ca.example"
;                                │ │     └ value
;                                │ └ tag
;                                └ flags

Le champ flags vaut 0 dans pratiquement tous les cas. La valeur 128 positionne le bit « critique », qui signifie qu'une AC ne comprenant pas la balise ne doit pas émettre.

Les balises :

Balise	Signification
`issue`	L'AC nommée peut émettre des certificats pour ce nom. S'applique aussi aux certificats à joker, sauf si `issuewild` est présent.
`issuewild`	Règles pour les certificats à joker uniquement. Si elle est présente, elle remplace `issue` pour les demandes de joker.
`iodef`	Où une AC peut signaler une demande qui a violé la politique (`mailto:` ou `https:`). La prise en charge par les AC est limitée ; considérez-la comme facultative.
`issuemail`	Le même contrôle pour les certificats S/MIME (RFC 9495).

La valeur de issue/issuewild est le nom de domaine d'identification que chaque AC documente, par exemple sur sa page CAA ou dans son CPS. Ce n'est pas toujours le nom commercial ni le site web de l'AC, et les AC qui revendent les certificats d'une autre AC utilisent l'identifiant de l'AC en amont. Cherchez-le ; ne le devinez pas. La valeur spéciale ";" signifie « personne ».

Exemples

Une seule AC, pas de joker, avec une adresse de signalement :

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Deux AC (disons, votre AC ACME et celle qu'utilise votre CDN) :

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issue "ca-two.example"

Un domaine qui ne devrait jamais avoir de certificat :

parked.example.  IN  CAA  0 issue ";"

Des jokers émis par une AC différente de celle des certificats ordinaires :

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild "ca-two.example"

Comment une AC trouve l'enregistrement pertinent

C'est la partie que les gens comprennent de travers. Pour une demande de certificat couvrant www.shop.example.com, l'AC :

interroge CAA à www.shop.example.com ;
s'il n'y a aucun enregistrement CAA à ce niveau, interroge shop.example.com ;
puis example.com, et ainsi de suite en remontant l'arbre ;
s'arrête au premier nom qui possède des enregistrements CAA et n'utilise que ceux-là.

Conséquences :

Un enregistrement à example.com couvre chaque sous-domaine qui n'a pas de CAA propre.
Les enregistrements ne sont pas fusionnés. Un CAA à shop.example.com remplace entièrement celui de example.com pour tout ce qui se trouve sous shop. Vous pouvez vous en servir délibérément pour donner à un sous-domaine une AC différente.
Les CNAME sont suivis. Si shop.example.com est un CNAME vers stores.saas.example, la requête CAA pour shop.example.com reçoit pour réponse les enregistrements CAA de la cible. La politique CAA d'un fournisseur SaaS peut donc s'appliquer à votre nom d'hôte. Selon la RFC en vigueur, l'AC ne remonte pas l'arbre de la cible ; si la cible n'a pas de CAA, la remontée continue chez votre parent, example.com.
Un échec de requête n'est pas la même chose que « pas d'enregistrement ». Si l'AC ne peut pas obtenir une réponse nette (délai dépassé, SERVFAIL, DNSSEC cassé), elle ne doit pas émettre. Un DNS faisant autorité instable se manifeste par des renouvellements en échec.

Chaque nom d'un certificat multi-noms est vérifié séparément.

Lier l'émission à un compte ou à une méthode

La RFC 8657 ajoute des paramètres qui rendent CAA nettement plus fort pour les utilisateurs d'ACME :

example.com. IN CAA 0 issue "ca-one.example; accounturi=https://acme.ca-one.example/acct/12345"
example.com. IN CAA 0 issue "ca-one.example; validationmethods=dns-01"

accounturi limite l'émission à un seul compte ACME, de sorte qu'une autre personne disposant d'un compte chez la même AC ne peut pas obtenir de certificat même si elle réussit la validation. validationmethods limite la manière dont le contrôle peut être prouvé. Les deux ne fonctionnent qu'avec les AC qui les implémentent ; consultez la documentation de l'AC avant de vous y fier, et pensez à mettre l'enregistrement à jour si vous recréez un jour le compte ACME.

Ajouter CAA sans rien casser : liste de contrôle

Déterminez qui émet pour vous aujourd'hui. Inspectez les certificats de chaque nom d'hôte, ou cherchez votre domaine dans les journaux de Certificate Transparency. Surprises habituelles : le CDN, les certificats managés du répartiteur de charge, la boutique hébergée, la page de statut, le service de messagerie, et une équipe interne qui utilise une autre AC ACME.
Relevez l'identifiant CAA de chaque AC dans sa documentation.
Vérifiez les sous-domaines qui sont des CNAME vers des tiers : interrogez CAA sur eux et regardez ce qui revient.
Publiez les enregistrements à l'apex de la zone avec un TTL modéré (3600). Les AC peuvent mettre en cache le résultat d'une vérification CAA pendant au plus le TTL de l'enregistrement ou 8 heures, la valeur la plus grande des deux.
Testez un renouvellement tout de suite (certbot renew --dry-run effectue une validation complète contre l'environnement de test, qui, pour la plupart des AC ACME, comprend une vérification CAA) plutôt que de le découvrir dans 60 jours.
Documentez-le là où la prochaine personne regardera quand elle changera de CDN ou d'AC.

Interrogez ce qui est publié :

$ dig +short example.com CAA
0 issue "ca-one.example"
0 issuewild ";"
$ dig +short www.shop.example.com CAA      # empty → the CA will climb

Erreurs fréquentes

Changer de CDN ou d'hébergeur et oublier que le nouveau utilise une autre AC. Le nouveau certificat échoue silencieusement à l'émission, et l'ancien arrive à échéance. Voir certificat SSL expiré : que faire.
Utiliser le nom commercial de l'AC au lieu de son identifiant CAA documenté.
issuewild ";" alors qu'un certificat à joker est utilisé quelque part.
Croire qu'un issue à l'apex et un autre issue sur un sous-domaine s'additionnent. L'ensemble du sous-domaine l'emporte seul.
Un fournisseur DNS qui ne prend pas en charge le type CAA, où l'on tente de le stocker en TXT. Cela ne fait rien.
Des erreurs de guillemets dans les panneaux de gestion : la valeur est une chaîne entre guillemets, le drapeau et la balise ne le sont pas.
S'attendre à ce que CAA invalide les certificats existants. Il n'affecte que les nouvelles émissions.
Changer de serveurs de noms sans copier les enregistrements CAA ; ils comptent parmi les enregistrements les plus souvent perdus, comme le rappelle changer de serveurs de noms sans interruption.

Vérifiez avec OrbitProbe

La recherche DNS d'OrbitProbe inclut CAA parmi les types d'enregistrements qu'elle interroge, avec le TTL, tels que les résolveurs publics les renvoient à cet instant. Lancez-la d'abord sur le domaine nu, puis sur tout sous-domaine qui est un CNAME vers un service externe, pour voir quelle politique une AC y trouverait réellement. Pour la place de CAA parmi les autres types d'enregistrements, voyez les types d'enregistrements DNS expliqués.