Introduction
Défini en 2013 par la RFC6844, le CAA est un type d’enregistrement DNS qui permet aux propriétaires de sites de préciser quelles autorités de certification (CA) sont autorisées à émettre des certificats contenant leurs noms de domaine.
Quel est l’intérêt
Par défaut, chaque autorité de certification publique est autorisée à émettre des certificats pour tout nom de domaine dans le DNS public, à condition qu’elle valide le contrôle de ce nom de domaine.
L’enregistrement CAA offre aux détenteurs de domaines un moyen de réduire ce risque d’une émission de certificat non souhaitée en intégrant une étape de confirmation/refus aux autorités de certification dans leurs processus d’émission de certificat.
L’intérêt d’un tel système prend tout son sens suite à l’essor des certificats générés « à la volée ». Ces types de certificat sont émis sans aucune vérification sur le titulaire du domaine. Il est aisé de demander un certificat pour n’importe quel domaine.
L’enregistrement CAA permet donc au propriétaire d’un nom de domaine de spécifier les autorités de certification qu’il autorise à émettre un certificat.
Notez que l’utilisation de DNSSEC pour authentifier les enregistrements CAA est fortement recommandée mais non requise (RFC 6844, section 4.1). Du point de vue sécurité, vous devez absolument utiliser le DNSSEC pour obtenir une requête/réponse authentique des CA à votre serveur DNS.
Enfin, cet enregistrement n’est pas encore obligatoire, mais je vous encourage à le mettre en oeuvre avant de personnes malveillantes n’utilisent cet oubli à leur avantage.
Principe de fonctionnement
Quand une autorité de certification reçoit une demande de certificat, elle vérifie le domaine afin de déterminer si un enregistrement de type CAA existe. Si un enregistrement existe et que la CA est bien autorisée, alors l’autorité de certification génère le certificat. Si l’enregistrement CAA spécifie une CA différente, alors la génération du certificat est refusée. A ce jour, si l’enregistrement CAA n’existe pas, alors la CA est autorisée à générer le certificat.
Structure d’un enregistrement CAA
Chaque enregistrement CAA est constitué d’un octet « flag » et d’une paire étiquette-valeur appelée une propriété.
Plusieurs propriétés peuvent être associées au même nom de domaine en publiant plusieurs enregistrements CAA à ce nom de domaine.
Un seul « flag » est défini: le « issuer critical » est représenté par le bit le plus significatif de l’octet. S’il est activé (c’est-à-dire que l’entier résultant est égal ou supérieur à 128) l’autorité de certification qui n’est pas à même de comprendre ou de mettre en œuvre l’étiquette de cet enregistrement doit refuser de délivrer un certificat pour le domaine.
Outre le « flag », trois mots clés sont définis:
- issue : autorise une autorité (via son nom de domaine spécifié dans le champ « value ») à délivrer des certificats pour le domaine sur lequel l’enregistrement pointe
- issuewild : est similaire à issue et vise les émissions de certificats wildcard
- iodef : indique un moyen pour les autorités de signaler une demande de certificat ou un souci avec celle-ci
Pour interdire l’émission d’un certificat, il faut spécifier « ; » comme valeur pour le mot clé issue ou issuewild.
Exemple de mise en oeuvre
Qui prend en charge l’enregistrement CAA ?
Si vous voulez publier un enregistrement CAA, le logiciel (ou le fournisseur) de DNS de votre domaine doit prendre en charge le CAA.
Le site https://sslmate.com/caa/support vous indique quels logiciels et fournisseurs DNS prennent en charge la CAA. En France, les 2 principaux fournisseurs, Gandi et OVH, supportent le CAA.
Mise en oeuvre
Pour illustrer notre exemple, nous allons utiliser le domaine example.com et l’autorité de certification Let’s Encrypt.
Le nom de domaine d’identification de Let’s Encrypt pour la CAA est letsencrypt.org.
Si votre fournisseur est répertorié, vous pouvez utiliser le générateur d’enregistrements CAA de sslmate pour générer un ensemble d’enregistrements CAA répertoriant les CA que vous souhaitez autoriser.
Voici les captures :
Enfin, vous publiez votre politique CAA en ajoutez les enregistrements CAA suivants au DNS de votre domaine. Votre DNS doit être hébergé par un service qui prend en charge la CAA.
Plusieurs formats sont rencontrés :
– générique (utilisé par Google Cloud DNS, Route 53, DNSimple, et les autres services DNS hébergés) :
Name Type Value
example.com. CAA 0 issue ";"
0 issuewild "letsencrypt.org"
0 iodef "mailto:support@example.com"
- standard (utilisé par BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0) :
Name Type Value
example.com. IN CAA 0 issue ";"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:support@example.com"
- legacy RFC 3597 (utilisé par BIND <9.9.6, NSD <4.0.1, Windows Server 2016) :
Name Type Value
example.com. IN TYPE257 \# 8 000569737375653B
example.com. IN TYPE257 \# 26 0009697373756577696C646C657473656E63727970742E6F7267
example.com. IN TYPE257 \# 33 0005696F6465666D61696C746F3A737570706F7274406578616D706C652E636F6D
Résolution des problèmes
Comment vérifier
Commande DIG
Une requête de test avec dig montre les enregistrements :
$ dig @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional
; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45743
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;celea.org. IN CAA
;; ANSWER SECTION:
celea.org. 1800 IN CAA 0 iodef "mailto:mathias@celea.org"
celea.org. 1800 IN CAA 0 issuewild "letsencrypt.org"
celea.org. 1800 IN CAA 128 issue "letsencrypt.org"
celea.org. 1800 IN RRSIG CAA 13 2 1800 (
20210520000000 20210429000000 7209 celea.org.
9CmiaEqazRE272NDI8SgfY4iaWFI+Du13j0bTDWAzsCn
H6Y4dI7VT2UfG/vWNuLdUPSpXGkhwee0MOSMoQJcFA== )
;; Query time: 96 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: ven. mai 07 17:43:20 CEST 2021
;; MSG SIZE rcvd: 258
Services en ligne
Vous pouvez aussi utiliser un service en ligne https://caatest.co.uk/ :
Erreur CAA liée au fournisseur DNS
Avant l’émission d’un certificat, l’autorité de certification vérifie les enregistrements CAA. Parfois des erreurs sont renvoyées même pour des domaines n’ayant pas défini d’enregistrements CAA. Lorsqu’une erreur est obtenue, la CA ne peut pas savoir si elle est autorisée à émettre un certificat pour le domaine concerné. En effet, des enregistrements CAA pourrait être présents interdisant l’émission, mais qui ne sont pas visibles à cause de l’erreur.
Certains fournisseurs DNS qui ne sont pas familiers avec la CAA répondent initialement aux rapports de problèmes par « Nous ne prenons pas en charge les enregistrements CAA ». Votre fournisseur DNS n’a pas besoin de prendre spécifiquement en charge les enregistrements CAA. Il doit seulement répondre par une réponse NOERROR pour les types de requêtes inconnus (y compris le CAA). Renvoyer d’autres opcodes, y compris NOTIMP, pour les types de requête inconnus est une violation de la RFC1035, et doit être corrigé.
SERVFAIL
L’erreur les plus courantes rencontrée est SERVFAIL. Le plus souvent, cela indique un échec de la validation DNSSEC.
Si vous obtenez une erreur SERVFAIL, votre première étape devrait être d’utiliser un débogueur DNSSEC comme dnsviz.net. Si cela ne fonctionne pas, il est possible que vos serveurs de noms génèrent des signatures incorrectes uniquement lorsque la réponse est vide. Et les réponses CAA sont le plus souvent vides.
Si vous n’avez pas activé DNSSEC et que vous obtenez un SERVFAIL, la deuxième raison la plus probable est que votre serveur de noms faisant autorité a renvoyé NOTIMP, ce qui est une violation de la RFC1035. Il devrait plutôt renvoyer NOERROR avec une réponse vide. Si tel est le cas, contactez de votre fournisseur DNS.
Enfin, les SERVFAILs peuvent être causés par des pannes au niveau de vos serveurs de noms faisant autorité. Vérifiez les enregistrements NS de vos serveurs de noms et assurez-vous que chaque serveur est disponible.
Timeout
Parfois, les requêtes CAA n’aboutissent pas. Même après plusieurs tentative, le serveur de noms faisant autorité ne répond pas. Le plus souvent, cela se produit lorsque votre serveur de noms est protégé par un pare-feu mal configuré qui rejette les requêtes DNS avec des QTYPES inconnus. Contactez alors votre fournisseur DNS.
Les champs QTYPE apparaissent dans la partie question d’une requête. Les QTYPES sont un sur-ensemble de TYPEs, donc tous les TYPEs sont des QTYPEs valides
Surveillez votre domaine
Même si vous publiez un enregistrement CAA, une autorité de certification non conforme peut ignorer vos enregistrements CAA. Utilisez Cert Spotter pour surveiller les journaux de Certificate Transparency afin d’être averti si cela se produit.
