Enregistrements DNS CAA : le guide complet pour contrôler qui émet vos certificats

⚡TL;DR

• Un enregistrement DNS CAA déclare quelles autorités de certification ont le droit d'émettre un certificat TLS pour votre domaine. Sans CAA, n'importe quelle CA publique peut le faire.
• La syntaxe tient en trois champs : flag tag value. Les tags utiles sont issue (certificats classiques), issuewild (wildcards) et iodef (signalement des tentatives non autorisées).
• La CA vérifie le CAA au moment de l'émission en remontant le DNS du sous-domaine vers l'apex (tree climbing), et s'arrête au premier enregistrement trouvé (RFC 8659).
• RFC 8657 ajoute accounturi et validationmethods pour épingler l'émission à un compte ACME précis et à des méthodes de validation autorisées.
• Une configuration CAA mal pensée (issuewild oublié, point-virgule mal compris, CA absente) peut bloquer vos renouvellements ACME automatiques.

Le modèle de confiance des certificats TLS repose sur une centaine d'autorités de certification (CA) reconnues par les navigateurs. Le problème est structurel : par défaut, n'importe laquelle de ces CA peut émettre un certificat valide pour votre domaine, sans votre accord et sans même vous en informer. Un attaquant qui parvient à tromper une seule CA, ou une CA qui se trompe, peut produire un certificat parfaitement reconnu pour captaindns.com.

L'enregistrement DNS CAA (Certificate Authority Authorization), défini par la RFC 8659, ferme une partie de cette porte. Il agit comme une liste blanche publiée dans votre zone DNS : avant d'émettre un certificat, une CA conforme doit interroger le DNS et vérifier qu'elle figure bien dans vos enregistrements CAA. Si elle n'y est pas, elle refuse d'émettre. C'est une barrière à l'émission, pas une détection a posteriori.

Ce guide s'adresse aux administrateurs systèmes, aux équipes DevOps et SRE, et aux responsables sécurité. Il couvre le modèle de menace, la syntaxe complète d'un enregistrement CAA (tags issue, issuewild, iodef, flag critique), le mécanisme exact de validation par remontée d'arbre, les paramètres avancés de la RFC 8657 pour l'écosystème ACME, la configuration concrète chez les principaux fournisseurs, et les erreurs qui cassent les renouvellements automatiques.

Le problème : n'importe quelle CA peut émettre un certificat

Quand votre navigateur ouvre une connexion HTTPS, il vérifie que le certificat présenté est signé par une autorité de certification présente dans son magasin de confiance. Ce magasin contient une centaine de CA racine, gérées par des organisations très diverses, réparties dans de nombreux pays.

Une confiance horizontale et sans cloisonnement

Le défaut de conception est simple à énoncer : la confiance est horizontale. Le navigateur fait confiance à toutes les CA de son magasin de manière équivalente. Rien, dans le protocole de base, ne restreint une CA donnée à un sous-ensemble de domaines. Concrètement, une CA située à l'autre bout du monde, que vous n'avez jamais utilisée, est techniquement habilitée à émettre un certificat reconnu pour votre domaine.

Tant que toutes les CA fonctionnent parfaitement, ce modèle tient. Mais il suffit qu'une seule défaille, par erreur opérationnelle ou compromission, pour qu'un certificat frauduleux soit produit et accepté par tous les navigateurs.

Des incidents bien réels

L'histoire des certificats TLS est jalonnée d'incidents de mauvaise émission (mis-issuance) :

• DigiNotar (2011) : cette CA néerlandaise a été compromise. Les attaquants ont émis plus de 500 certificats frauduleux, dont un wildcard pour *.google.com, utilisé pour intercepter le trafic de citoyens iraniens. DigiNotar a perdu la confiance des navigateurs et a fait faillite.
• Symantec (2015 à 2017) : une série d'émissions non conformes, dont des certificats de test pour des domaines tiers émis sans autorisation, a conduit Google et Mozilla à programmer la révocation de la confiance accordée à l'ancienne infrastructure Symantec. L'activité de CA a été cédée à DigiCert.
• Détournements BGP : plusieurs attaques ont combiné détournement de routes réseau et validation de domaine pour obtenir des certificats frauduleux. Le cas MyEtherWallet (2018) a vu des attaquants détourner le trafic DNS pour obtenir un certificat et voler des fonds.

Ces incidents partagent un point commun : un certificat techniquement valide a été émis pour un domaine sans l'accord de son propriétaire. La recherche académique a confirmé que ce risque n'a rien d'anecdotique. L'étude "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018) a démontré qu'un attaquant pouvait obtenir des certificats frauduleux auprès des plus grandes CA en détournant les requêtes de validation de domaine via BGP, avec un taux de succès élevé.

La leçon est qu'une seule défaillance dans n'importe laquelle des CA de confiance suffit à compromettre n'importe quel domaine. C'est précisément l'ampleur de cette surface d'attaque que le CAA vient réduire, en limitant la liste des CA habilitées à émettre pour un domaine donné.

La détection ne suffit pas

La Certificate Transparency (CT) impose depuis 2018 que tout certificat public soit journalisé dans des registres publics et vérifiables. Le gain est réel : un propriétaire de domaine peut surveiller ces logs et repérer un certificat émis à son insu.

Mais la Certificate Transparency reste une détection a posteriori. Au moment où vous repérez un certificat frauduleux dans un log, il a déjà été émis et peut déjà avoir servi. Le CAA s'attaque au problème en amont : il empêche l'émission plutôt que de la constater après coup. Les deux mécanismes sont complémentaires.

Qu'est-ce qu'un enregistrement CAA ?

Un enregistrement DNS CAA (Certificate Authority Authorization, RFC 8659) indique quelles autorités de certification sont autorisées à émettre des certificats TLS pour un domaine. Avant chaque émission, la CA interroge le DNS du domaine et refuse d'émettre si elle ne figure pas dans la liste publiée. C'est une autorisation préalable, contrôlée par le propriétaire du domaine via sa zone DNS.

Un type d'enregistrement DNS dédié

Le CAA est un type d'enregistrement DNS à part entière, le type 257. Il se publie dans votre zone exactement comme un enregistrement A, MX ou TXT. Vous pouvez le placer à l'apex de la zone (captaindns.com) ou sur un sous-domaine précis (api.captaindns.com).

Voici un exemple minimal qui n'autorise que Let's Encrypt à émettre des certificats pour le domaine :

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"

Cet enregistrement déclare une seule chose : la seule CA autorisée à émettre un certificat pour captaindns.com est Let's Encrypt, identifiée par son domaine letsencrypt.org. Toute autre CA conforme qui reçoit une demande pour ce domaine la refusera.

Un point essentiel sur la sémantique : la présence d'un seul enregistrement issue transforme la politique implicite. Sans CAA, toutes les CA sont autorisées par défaut. Dès qu'un issue existe, le défaut s'inverse : seules les CA explicitement listées sont autorisées, toutes les autres sont implicitement interdites. Ajouter une CA à votre politique consiste donc à publier un enregistrement issue supplémentaire ; en oublier une revient à la bloquer.

Une histoire en deux RFC

Le CAA a d'abord été défini par la RFC 6844 en 2013. Cette première version comportait un mécanisme de remontée d'arbre (tree climbing) jugé ambigu, notamment sur la gestion des erreurs et des alias CNAME/DNAME.

La RFC 8659, publiée en 2019, remplace la RFC 6844 et fait référence aujourd'hui. Elle clarifie l'algorithme de remontée et corrige les zones d'ombre de la première version. Une RFC complémentaire, la RFC 8657 (2019), ajoute deux paramètres orientés ACME : accounturi et validationmethods. Ils ont leur propre section plus bas.

Une barrière, pas une garantie absolue

Le CAA repose sur la coopération des CA. Toutes les CA publiquement reconnues, soumises aux Baseline Requirements du CA/Browser Forum, sont obligées de vérifier le CAA avant émission. C'est une exigence du référentiel, pas une option. En pratique, les CA majeures appliquent cette vérification.

Le CAA ne protège donc pas contre une CA malhonnête qui choisirait d'ignorer délibérément vos enregistrements, ni contre une CA privée interne à une organisation. Mais il élève fortement la barrière : pour émettre un certificat frauduleux malgré un CAA bien configuré, un attaquant devrait soit compromettre la CA que vous avez explicitement autorisée, soit falsifier vos réponses DNS au moment du contrôle. Ce dernier point ouvre tout le sujet du lien entre CAA et DNSSEC, qu'on traite plus bas.

Anatomie d'un enregistrement CAA

Un enregistrement CAA tient en trois champs, toujours dans le même ordre. Trois champs, c'est court, mais une virgule mal placée suffit à inverser le sens d'une politique.

La structure flag tag value

Chaque enregistrement CAA se compose de trois éléments :

Champ	Rôle	Valeurs
flag	Entier de contrôle	0 (non critique) ou 128 (critique)
tag	Propriété concernée	issue, issuewild ou iodef
value	Valeur de la propriété	Identifiant de la CA, ou URL de signalement

Lu de gauche à droite, l'enregistrement 0 issue "letsencrypt.org" se traduit par : flag non critique, propriété issue, valeur letsencrypt.org. La valeur est toujours entre guillemets droits dans la représentation textuelle.

Le tag issue : autoriser une CA pour les certificats classiques

Le tag issue autorise une CA à émettre des certificats non wildcard pour le domaine. La valeur est l'identifiant de la CA, généralement un nom de domaine.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  IN  CAA  0 issue "digicert.com"

Cet exemple autorise deux CA : Let's Encrypt et DigiCert. Quand plusieurs enregistrements issue coexistent, ils s'additionnent : toute CA listée est autorisée. C'est une liste blanche cumulative.

Un cas particulier à connaître : la valeur ";" (un simple point-virgule). Elle interdit toute émission.

captaindns.com.  IN  CAA  0 issue ";"

Cet enregistrement déclare qu'aucune CA n'est autorisée à émettre de certificat classique pour le domaine. C'est utile pour un domaine qui ne doit jamais porter de certificat (un domaine de parking, par exemple), mais c'est aussi une source d'erreur fréquente quand il est posé par inadvertance.

Le tag issuewild : le cas des wildcards

Le tag issuewild contrôle spécifiquement l'émission des certificats wildcard (du type *.captaindns.com). Sa syntaxe est identique à celle de issue.

La règle de priorité est essentielle : issuewild prime sur issue pour les certificats wildcard. Si un enregistrement issuewild est présent, c'est lui qui fait foi pour les demandes wildcard, et les enregistrements issue sont ignorés pour ce cas. Si aucun issuewild n'est présent, les certificats wildcard retombent sur les règles issue.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  IN  CAA  0 issuewild "digicert.com"

Dans cet exemple, les certificats classiques ne peuvent être émis que par Let's Encrypt, tandis que les certificats wildcard ne peuvent l'être que par DigiCert. Pour interdire purement et simplement tout certificat wildcard, on utilise le point-virgule :

captaindns.com.  IN  CAA  0 issuewild ";"

Cela bloque toute émission de wildcard tout en laissant les certificats classiques suivre les règles issue.

Le tag iodef : signaler les tentatives non autorisées

Le tag iodef (Incident Object Description Exchange Format) indique où une CA doit signaler une demande de certificat qui viole votre politique CAA. La valeur est une URL, soit un email au format mailto:, soit une URL HTTPS.

captaindns.com.  IN  CAA  0 iodef "mailto:security@captaindns.com"
captaindns.com.  IN  CAA  0 iodef "https://captaindns.com/caa-report"

Quand une CA reçoit une demande qu'elle refuse à cause de votre CAA, elle peut envoyer un rapport à l'adresse iodef. Le signal vaut de l'or : une tentative d'émission non autorisée trahit soit une attaque en cours, soit un service interne mal configuré. Le support de iodef varie selon les CA. Voyez-le comme un bonus de visibilité, pas comme une garantie de notification.

En pratique, un rapport iodef mérite une enquête immédiate. Soit un de vos services tente d'émettre un certificat via une CA que vous avez oublié d'autoriser (problème de configuration), soit un acteur externe tente d'obtenir un certificat pour votre domaine (problème de sécurité). Dans les deux cas, le iodef vous donne une visibilité que ni la Certificate Transparency ni les logs de votre infrastructure ne fournissent, car il capte la tentative au moment précis du refus.

Le flag critique : 0 contre 128

Le premier champ, le flag, est un octet dont seul le bit de poids fort (valeur 128, soit 0x80) a une signification définie : c'est le flag critique (issuer critical).

• Flag 0 : enregistrement non critique. Si une CA ne comprend pas le tag, elle l'ignore et continue.
• Flag 128 : enregistrement critique. Si une CA rencontre un tag qu'elle ne comprend pas avec ce flag positionné, elle doit refuser d'émettre.

Le flag critique sert à se prémunir contre l'introduction future de tags que les anciennes CA ne sauraient pas interpréter. En posant le flag 128 sur un tag, vous exigez que toute CA qui ne le comprend pas s'abstienne, par sécurité, plutôt que de l'ignorer. Dans l'immense majorité des configurations, le flag reste à 0 : les tags issue, issuewild et iodef sont universellement compris.

Les identifiants des CA courantes

La valeur d'un tag issue ou issuewild est l'identifiant de la CA, défini par chaque autorité dans sa documentation. Voici les identifiants des principales CA :

Autorité de certification	Identifiant CAA
Let's Encrypt	letsencrypt.org
DigiCert	digicert.com
Sectigo	sectigo.com
GlobalSign	globalsign.com
Google Trust Services	pki.goog
Amazon (AWS Certificate Manager)	amazon.com (et amazontrust.com, amazonaws.com, awstrust.com)

Utilisez toujours l'identifiant exact publié par la CA, et non une approximation. Une valeur incorrecte revient à ne pas autoriser la CA, et le certificat sera refusé. En cas de doute sur l'identifiant d'une CA non listée ici, consultez sa documentation officielle plutôt que de deviner.

Comment la validation CAA fonctionne

Tout se joue au moment de l'émission, quand la CA interroge le DNS. La plupart des erreurs de configuration viennent d'une mauvaise compréhension de cette étape.

La remontée d'arbre (tree climbing)

Quand une CA traite une demande de certificat pour un nom donné, elle ne se contente pas de regarder le CAA de ce nom précis. Elle remonte la hiérarchie DNS, label par label, du nom demandé vers l'apex de la zone, jusqu'à trouver un ensemble d'enregistrements CAA. C'est le tree climbing, défini à la section 3 de la RFC 8659.

Prenons une demande pour api.captaindns.com. La CA procède ainsi :

1. Elle interroge le CAA de api.captaindns.com. Si un ensemble CAA y est publié, elle l'utilise et s'arrête.
2. Sinon, elle remonte d'un cran et interroge captaindns.com. Si un ensemble CAA y est publié, elle l'utilise et s'arrête.
3. La remontée se poursuit jusqu'à trouver un ensemble CAA, ou jusqu'à atteindre la racine sans rien trouver.

Le point clé : la CA s'arrête au premier nom qui possède des enregistrements CAA. Les enregistrements des niveaux supérieurs ne sont alors pas consultés.

L'héritage et ses conséquences

Cette mécanique a une conséquence importante : un sous-domaine hérite de la politique CAA de son parent, mais seulement s'il ne définit pas la sienne.

Si vous publiez un CAA à l'apex captaindns.com et rien sur api.captaindns.com, alors api.captaindns.com est soumis à la politique de l'apex. Mais dès que vous publiez un seul enregistrement CAA sur api.captaindns.com, la CA s'arrête à ce niveau et ignore totalement l'apex. L'héritage est binaire : soit le sous-domaine n'a aucun CAA et hérite, soit il en a et remplace intégralement la politique parente. Il n'y a pas de fusion entre les deux niveaux.

C'est une source d'erreur classique : on ajoute un CAA spécifique sur un sous-domaine pour autoriser une CA supplémentaire, sans réaliser que cet enregistrement remplace la politique de l'apex au lieu de s'y ajouter. Le sous-domaine doit alors lister toutes les CA dont il a besoin, y compris celles déjà autorisées au niveau parent.

L'interaction avec les wildcards

Le cas des certificats wildcard combine deux règles. D'abord la priorité issuewild sur issue déjà décrite. Ensuite la remontée d'arbre. Pour une demande de *.captaindns.com, la CA cherche d'abord un ensemble CAA en remontant l'arbre, puis applique au sein de cet ensemble la priorité issuewild. Si l'ensemble trouvé contient un issuewild, il fait foi pour le wildcard ; sinon, le wildcard retombe sur les issue du même ensemble.

Le cas des alias CNAME

Quand le nom traité pour la validation CAA pointe vers un alias CNAME, la recherche CAA suit cet alias. La RFC 8659 précise que si un nom est un alias CNAME, la recherche CAA se poursuit sur la cible de l'alias. C'est un détail qui surprend parfois : un sous-domaine en CNAME vers un service tiers peut, selon la configuration, dépendre du CAA de la cible plutôt que de celui de votre zone. Lorsque vous déléguez un sous-domaine à un fournisseur externe via CNAME, vérifiez quelle politique CAA s'applique réellement.

Ce que vérifie réellement la CA à l'émission

Au moment d'émettre, une CA conforme aux Baseline Requirements effectue le contrôle CAA dans une fenêtre temporelle limitée (au plus 8 heures avant l'émission, selon le référentiel). Passé ce délai, le contrôle doit être refait. Cette contrainte évite qu'une autorisation obtenue longtemps à l'avance ne reste valable après que vous avez retiré une CA de votre politique.

La CA doit aussi, depuis le déploiement de la validation multi-perspectives (MPIC, Ballot SC-067), effectuer le contrôle CAA et la validation de domaine depuis plusieurs points de présence réseau géographiquement distincts. L'objectif est de contrer les détournements BGP localisés : si un attaquant détourne le trafic dans une région pour falsifier la réponse CAA, les autres perspectives recevront la réponse légitime et la CA détectera l'incohérence. MPIC protège donc le contrôle CAA au niveau réseau, tandis que DNSSEC le protège au niveau du protocole DNS. Les deux mécanismes se renforcent mutuellement.

Concrètement, la séquence d'émission ressemble à ceci : la CA reçoit la demande, valide le contrôle de domaine (DNS-01, HTTP-01 ou TLS-ALPN-01), interroge le CAA en remontant l'arbre, confirme qu'elle figure dans la liste autorisée, puis émet. Si le CAA la refuse, l'émission s'arrête immédiatement et, si un iodef est présent, un rapport peut être envoyé.

Le lien avec DNSSEC

Le contrôle CAA repose sur des réponses DNS. Si un attaquant peut falsifier vos réponses DNS au moment où la CA interroge le CAA, il peut tromper le contrôle. DNSSEC répond à ce risque en authentifiant cryptographiquement les réponses DNS.

Le CA/Browser Forum a formalisé ce lien avec le Ballot SC-085v2, en vigueur depuis le 15 mars 2026, qui impose aux CA de valider DNSSEC, quand il est présent, lors des requêtes CAA et de validation de domaine. Concrètement, si votre zone est signée et que la chaîne de confiance est intacte, la CA obtient la garantie que les enregistrements CAA qu'elle lit sont authentiques. Nous avons consacré un article complet à ce changement réglementaire : les CA vérifient désormais DNSSEC avant d'émettre un certificat. Vous pouvez contrôler l'état de signature de votre zone avec notre vérificateur DNSSEC. Pour activer DNSSEC sur un domaine qui n'en bénéficie pas encore, suivez notre guide d'activation pas à pas.

Paramètres avancés : la RFC 8657 et ACME

La RFC 8657 étend le CAA avec deux paramètres qui s'inscrivent dans le tag issue ou issuewild. Ils sont particulièrement utiles dans un écosystème ACME automatisé.

accounturi : épingler un compte ACME

Le paramètre accounturi restreint l'émission à un compte ACME précis. Au lieu d'autoriser n'importe quel compte d'une CA donnée à émettre pour votre domaine, vous épinglez l'autorisation à l'URI d'un compte ACME unique.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

Cet enregistrement autorise Let's Encrypt à émettre, mais uniquement pour le compte ACME numéroté 12345678. Une demande émanant d'un autre compte Let's Encrypt sera refusée. C'est une protection forte : même si un attaquant utilise la même CA que vous, il ne pourra pas émettre avec son propre compte.

validationmethods : restreindre les méthodes de validation

Le paramètre validationmethods limite les méthodes de validation ACME autorisées pour le domaine. Les valeurs correspondent aux types de défi ACME : dns-01, http-01 et tls-alpn-01.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01"

Ici, seule la validation par enregistrement DNS (dns-01) est acceptée. Une tentative d'émission via http-01 (placement d'un fichier sur le serveur web) sera refusée. Cela durcit la configuration : si vous savez que vos certificats sont toujours validés par dns-01, interdire les autres méthodes réduit la surface d'attaque, par exemple un serveur web compromis qui tenterait une validation http-01.

Les trois méthodes de validation ACME ont des profils de risque distincts. La méthode dns-01 exige le contrôle de la zone DNS et permet les certificats wildcard. La méthode http-01 exige le contrôle du serveur web sur le port 80. La méthode tls-alpn-01 valide via une extension TLS sur le port 443. Restreindre validationmethods à la seule méthode que vous utilisez réellement empêche un attaquant qui ne contrôlerait qu'un de ces vecteurs d'obtenir un certificat par une voie que vous n'aviez pas anticipée.

Combiner les paramètres pour un domaine durci

Les paramètres se cumulent dans un même enregistrement, séparés par des points-virgules. Une configuration durcie typique combine CA, compte et méthode :

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"

Cet enregistrement n'autorise que Let's Encrypt, uniquement via le compte ACME 12345678, et uniquement par la méthode dns-01. C'est le niveau de contrôle le plus fin offert par le CAA. Attention toutefois : plus la configuration est stricte, plus une erreur (changement de compte, migration de méthode de validation) risque de bloquer un renouvellement. Le support de la RFC 8657 dépend aussi de la CA ; Let's Encrypt l'implémente, mais vérifiez la documentation de votre CA avant de déployer accounturi ou validationmethods.

Guide pratique : configurer CAA chez votre fournisseur

La syntaxe CAA est standard, mais chaque fournisseur DNS expose une interface différente. Certains demandent les trois champs séparément (flag, tag, value), d'autres une chaîne complète. Le type d'enregistrement est toujours CAA (type 257). Voici les démarches chez les fournisseurs courants.

Cloudflare

Dans le tableau de bord Cloudflare, allez dans DNS puis Records, et ajoutez un enregistrement de type CAA. L'interface présente trois champs distincts :

• Flags : laissez 0 dans la plupart des cas.
• Tag : choisissez issue, issuewild ou iodef dans la liste déroulante.
• CA domain name (ou Value) : saisissez l'identifiant, par exemple letsencrypt.org.

Cloudflare propose également une API et son outil en ligne de commande pour automatiser la création d'enregistrements CAA dans une infrastructure as code. Notez que Cloudflare ajoute parfois automatiquement des enregistrements CAA pour ses propres certificats gérés ; vérifiez la liste complète après modification pour ne pas écraser une entrée nécessaire à un service Cloudflare.

AWS Route 53

Dans la console Route 53, sélectionnez votre zone hébergée et créez un enregistrement de type CAA. Route 53 attend la valeur au format complet, une ligne par enregistrement :

0 issue "amazon.com"
0 issue "letsencrypt.org"

Si vos certificats sont gérés par AWS Certificate Manager (ACM), Amazon documente plusieurs identifiants acceptés : amazon.com, amazontrust.com, amazonaws.com et awstrust.com. Vous pouvez les autoriser tous pour couvrir l'ensemble des cas. Pensez à conserver les autres CA dont vous avez besoin pour les services hors AWS.

OVHcloud

Dans l'espace client OVHcloud, ouvrez la zone DNS de votre domaine et ajoutez une entrée. Sélectionnez le type CAA. OVHcloud demande généralement le flag, le tag et la cible (la valeur) dans des champs distincts. Saisissez 0 pour le flag, le tag voulu, et l'identifiant de la CA pour la cible. Validez, puis attendez la propagation.

Gandi

Dans l'interface de gestion DNS de Gandi (LiveDNS), ajoutez un enregistrement de type CAA. Gandi attend la valeur au format textuel complet :

0 issue "letsencrypt.org"

Comme chez les autres fournisseurs, vous pouvez ajouter plusieurs lignes CAA pour autoriser plusieurs CA, ou pour ajouter issuewild et iodef. La validation des certificats Gandi pour les domaines hébergés chez eux s'appuie sur les CA qu'ils utilisent ; pensez à les inclure si vous comptez sur leurs certificats.

Vérifier la propagation après configuration

Quel que soit le fournisseur, ne considérez pas la configuration terminée tant que vous n'avez pas confirmé que l'enregistrement est visible publiquement. Interrogez le DNS depuis l'extérieur de votre réseau et confirmez que le CAA apparaît bien avec le flag, le tag et la valeur attendus. Tenez compte du TTL : un enregistrement modifié peut rester en cache pendant la durée du TTL précédent. Sur un domaine signé avec DNSSEC, vérifiez également que le nouvel enregistrement CAA est correctement signé, faute de quoi un résolveur validant le rejettera.

Configurer iodef pour le signalement

Quel que soit le fournisseur, le tag iodef se configure comme issue, mais sa valeur est une URL de signalement plutôt qu'un identifiant de CA. Utilisez une adresse de messagerie surveillée par votre équipe sécurité :

0 iodef "mailto:security@captaindns.com"

Vérifiez que l'adresse est réellement relevée. Un iodef pointant vers une boîte abandonnée ne sert à rien.

Tester avant de verrouiller

Une recommandation prudente : commencez par une politique permissive qui liste toutes vos CA réellement utilisées, déployez-la, vérifiez que les renouvellements passent, puis durcissez progressivement. Tenez compte du TTL de vos enregistrements : un TTL élevé ralentit la prise en compte d'un changement de CA. Avant une migration de CA, abaissez le TTL du CAA pour accélérer la propagation.

Vérifier et auditer vos enregistrements CAA

Une fois le CAA déployé, vérifiez qu'il est correctement publié et qu'il reflète votre intention. Deux approches se complètent : la ligne de commande et les outils d'audit.

Lire le CAA avec dig

L'outil dig interroge directement le DNS. Pour afficher les enregistrements CAA d'un domaine :

dig CAA captaindns.com +short

La sortie ressemble à ceci :

0 issue "letsencrypt.org"
0 issuewild "digicert.com"
0 iodef "mailto:security@captaindns.com"

Chaque ligne correspond à un enregistrement CAA, dans l'ordre flag tag value. Si la commande ne retourne rien, le domaine ne publie aucun CAA à ce niveau. N'oubliez pas la remontée d'arbre : un sous-domaine sans CAA hérite de l'apex. Pour vérifier ce dont hérite réellement api.captaindns.com, interrogez successivement le sous-domaine puis l'apex.

Pour voir le détail complet, y compris le TTL et la section d'autorité, omettez l'option +short :

dig CAA captaindns.com

Les outils CaptainDNS

La ligne de commande montre l'enregistrement brut, mais ne dit pas s'il est cohérent. CaptainDNS propose deux niveaux de vérification.

Le vérificateur CAA dédié affiche vos enregistrements et leur interprétation, en tenant compte de l'héritage par remontée d'arbre. Il vous indique clairement quelle CA est autorisée pour les certificats classiques et pour les wildcards.

Pour une vue plus large, notre audit de sécurité et de délivrabilité intègre désormais le CAA dans son scoring. Le pilier Sécurité DNS combine deux signaux : DNSSEC, qui pèse 80 points, et CAA, qui pèse 20 points. Cette pondération reflète leur rôle respectif : DNSSEC authentifie l'ensemble de vos réponses DNS, le CAA restreint spécifiquement l'émission de certificats. Un domaine qui publie un CAA cohérent gagne ces 20 points et améliore sa posture de sécurité globale.

Ce qu'il faut vérifier

Lors de l'audit, contrôlez quelques points précis :

• Cohérence issue et issuewild : la CA qui émet vos wildcards est-elle bien autorisée par un issuewild, ou comptez-vous sur le repli vers issue ?
• Aucune CA orpheline : chaque CA que vous utilisez réellement (y compris pour les services tiers, CDN, passerelles mail) figure-t-elle dans la liste ?
• iodef joignable : l'adresse de signalement est-elle surveillée ?
• Pas de point-virgule involontaire : un issue ";" posé par erreur bloquerait toute émission.

Erreurs courantes à éviter

La plupart des incidents liés au CAA viennent de quelques erreurs récurrentes. En voici les principales, avec le moyen de les éviter.

Oublier issuewild. Vous publiez un issue pour Let's Encrypt et tout fonctionne, jusqu'au jour où vous demandez un certificat wildcard. Si aucun issuewild n'est présent, le wildcard retombe sur issue, ce qui passe. Mais si vous avez posé un issuewild pour une autre CA, ou un issuewild ";", le wildcard sera refusé. Vérifiez toujours la cohérence entre issue et issuewild.

Bloquer sa propre CA. L'erreur la plus directe : oublier de lister la CA que vous utilisez réellement. Si vos certificats viennent de Let's Encrypt mais que votre CAA n'autorise que DigiCert, le prochain renouvellement échouera. Cette erreur survient souvent après un changement de CA ou l'ajout d'un nouveau service.

Casser le renouvellement ACME avec une politique trop stricte. Les paramètres accounturi et validationmethods sont puissants mais rigides. Si vous épinglez un compte ACME puis recréez ce compte (nouvel identifiant), ou si vous migrez de http-01 vers dns-01 sans mettre à jour le CAA, les renouvellements automatiques échoueront silencieusement. Sur une infrastructure ACME automatisée, ce type d'échec ne se voit qu'à l'expiration du certificat.

Mal comprendre l'héritage. Ajouter un enregistrement CAA sur un sous-domaine ne complète pas la politique de l'apex, il la remplace pour ce sous-domaine. Un sous-domaine avec son propre CAA doit lister toutes les CA dont il a besoin. Oublier ce point conduit à autoriser une CA tout en bloquant accidentellement celle de l'apex.

Le point-virgule mal interprété. issue ";" interdit toute émission. C'est voulu sur un domaine qui ne doit jamais porter de certificat, mais c'est un piège quand on pense qu'il s'agit d'un séparateur ou d'une valeur vide. Relisez chaque enregistrement après saisie.

Le mauvais flag. Poser le flag critique 128 sans comprendre son effet peut bloquer des CA qui ne reconnaissent pas un tag. Dans la grande majorité des cas, le flag doit rester à 0. Ne passez à 128 que si vous avez une raison précise et que vous comprenez quelles CA en seront affectées.

Croire que le CAA agit a posteriori. Le CAA est une barrière à l'émission, pas un mécanisme de révocation. Il ne révoque pas un certificat déjà émis et n'agit pas sur les certificats existants. Pour surveiller les certificats déjà produits, c'est la Certificate Transparency qui joue ce rôle.

Le CAA dans l'écosystème de la sécurité DNS

Le CAA ne se suffit pas à lui-même. Il s'inscrit dans un ensemble de mécanismes qui sécurisent différentes étapes du cycle de vie d'un certificat. Les confondre conduit à des attentes erronées.

Quatre mécanismes, quatre rôles

Mécanisme	Ce qu'il protège	Moment d'action
CAA	Quelle CA peut émettre	Avant l'émission
Certificate Transparency	Visibilité des certificats émis	Après l'émission
DANE / TLSA	Quel certificat le client doit accepter	À la connexion
DNSSEC	Authenticité des réponses DNS	À chaque résolution

Le CAA agit en amont : il restreint qui peut produire un certificat. La Certificate Transparency agit en aval : elle rend tout certificat émis public et donc détectable. DANE (DNS-based Authentication of Named Entities) agit côté client : il publie dans le DNS, via des enregistrements TLSA, l'empreinte du certificat que le client doit attendre, ce qui permet de rejeter un certificat valide mais illégitime. DNSSEC sous-tend l'ensemble : sans réponses DNS authentifiées, ni le CAA ni DANE ne sont fiables.

Une défense en profondeur

Ces mécanismes se complètent au lieu de se concurrencer. Le CAA empêche l'émission non autorisée. Si une émission frauduleuse passe malgré tout, la Certificate Transparency permet de la détecter. DANE permet au client de rejeter un certificat qui ne correspond pas à celui que vous avez publié. Et DNSSEC garantit que les enregistrements CAA et TLSA lus par les CA et les clients sont authentiques.

Pour approfondir la complémentarité entre CAA et DANE, consultez notre guide complet sur DANE et TLSA. Pour comprendre en détail comment DNSSEC authentifie les réponses DNS sur lesquelles repose tout l'édifice, lisez notre article sur la chaîne de confiance DNSSEC.

La stratégie recommandée est claire : publiez un CAA cohérent pour restreindre l'émission, signez votre zone avec DNSSEC pour authentifier vos réponses, surveillez la Certificate Transparency pour détecter toute émission inattendue, et déployez DANE si votre écosystème le permet (notamment pour le mail avec MTA-STS et DANE).

Plan d'action recommandé

1. Inventoriez vos CA réelles : listez toutes les autorités qui émettent des certificats pour vos domaines, y compris les services tiers (CDN, passerelles mail, plateformes cloud).
2. Publiez un CAA permissif : déclarez d'abord toutes vos CA via issue, ajoutez issuewild si vous utilisez des wildcards, et un iodef vers une boîte surveillée.
3. Vérifiez la prise en compte : contrôlez avec dig CAA et confirmez que vos renouvellements passent toujours.
4. Durcissez progressivement : envisagez accounturi et validationmethods sur les domaines critiques, après avoir vérifié le support de votre CA.
5. Signez votre zone avec DNSSEC : pour que le contrôle CAA soit fiable et conforme aux exigences SC-085v2.
6. Surveillez : intégrez la vérification CAA et DNSSEC à votre supervision, et relevez les rapports iodef.

FAQ

Qu'est-ce qu'un enregistrement CAA et à quoi sert-il ?

Un enregistrement DNS CAA (Certificate Authority Authorization, RFC 8659) déclare quelles autorités de certification sont autorisées à émettre des certificats TLS pour un domaine. Avant chaque émission, une CA conforme interroge le DNS et refuse d'émettre si elle ne figure pas dans la liste. Le CAA réduit ainsi le risque d'émission de certificats frauduleux par une CA non autorisée.

Un enregistrement CAA est-il obligatoire ?

Non. Le CAA est optionnel. Sans CAA, n'importe quelle CA publiquement reconnue peut émettre un certificat pour votre domaine. Le publier est une bonne pratique de sécurité fortement recommandée, car il restreint explicitement la liste des CA autorisées et limite la surface d'attaque liée à la mauvaise émission.

Que se passe-t-il si aucun enregistrement CAA n'est présent ?

En l'absence de CAA, une CA considère qu'aucune restriction n'est imposée et procède à l'émission après ses contrôles habituels de validation de domaine. Concrètement, toute CA publique peut alors émettre un certificat pour votre domaine. Le CAA n'a d'effet restrictif que s'il est explicitement publié.

Quelle est la différence entre les tags issue et issuewild ?

Le tag issue autorise une CA à émettre des certificats classiques (non wildcard). Le tag issuewild contrôle spécifiquement les certificats wildcard comme *.captaindns.com. Si un issuewild est présent, il prime sur issue pour les demandes wildcard. S'il est absent, les wildcards retombent sur les règles issue.

Un enregistrement CAA empêche-t-il vraiment l'émission d'un certificat frauduleux ?

Il l'empêche fortement, mais pas de manière absolue. Le CAA repose sur la coopération des CA, qui sont obligées par les Baseline Requirements du CA/Browser Forum de le vérifier. Il ne protège pas contre une CA qui ignorerait délibérément vos enregistrements, ni contre une falsification de vos réponses DNS. Associé à DNSSEC, qui authentifie ces réponses, il devient nettement plus solide.

Comment vérifier un enregistrement CAA avec dig ?

Utilisez la commande dig CAA captaindns.com +short en remplaçant par votre domaine. Elle affiche les enregistrements CAA au format flag tag value, par exemple 0 issue "letsencrypt.org". Si la commande ne retourne rien, aucun CAA n'est publié à ce niveau, mais le domaine peut hériter de la politique d'un nom parent par remontée d'arbre.

Comment fonctionne l'héritage CAA sur les sous-domaines ?

Lors d'une demande, la CA remonte la hiérarchie DNS du sous-domaine vers l'apex et s'arrête au premier nom qui possède des enregistrements CAA (tree climbing, RFC 8659). Un sous-domaine sans CAA hérite donc de la politique de son parent. Mais dès qu'un sous-domaine publie son propre CAA, il remplace intégralement la politique parente pour ce sous-domaine, sans fusion.

Faut-il configurer CAA si j'utilise déjà DNSSEC ?

Oui. DNSSEC et CAA répondent à des besoins différents. DNSSEC authentifie l'intégrité de vos réponses DNS, mais ne restreint pas quelle CA peut émettre un certificat. Le CAA, lui, déclare explicitement les CA autorisées. DNSSEC fiabilise le contrôle CAA (la CA lit des enregistrements authentiques), il ne le remplace pas. Les deux sont complémentaires.

Quelle norme définit l'enregistrement CAA ?

L'enregistrement CAA est défini par la RFC 8659 (2019), qui remplace la RFC 6844 (2013). La RFC 8657 (2019) ajoute les paramètres accounturi et validationmethods pour l'écosystème ACME. La vérification CAA par les CA est par ailleurs imposée par les Baseline Requirements du CA/Browser Forum.

Télécharger les tableaux comparatifs

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.

• Télécharger les identifiants CAA des CA (CSV)
• Télécharger les identifiants CAA des CA (JSON)

Glossaire

• CAA (Certificate Authority Authorization) : type d'enregistrement DNS (type 257) qui déclare quelles autorités de certification sont autorisées à émettre des certificats pour un domaine.
• CA (Certificate Authority) : autorité de certification habilitée à émettre des certificats TLS reconnus par les navigateurs.
• CA/Browser Forum : consortium des CA et éditeurs de navigateurs qui définit les Baseline Requirements, le référentiel que toute CA publique doit respecter, dont l'obligation de vérifier le CAA.
• Tree climbing (remontée d'arbre) : algorithme par lequel une CA remonte la hiérarchie DNS du nom demandé vers l'apex pour trouver les enregistrements CAA applicables.
• issuewild : tag CAA spécifique aux certificats wildcard, prioritaire sur issue pour ce cas.
• iodef : tag CAA indiquant une URL (mailto ou HTTPS) où signaler les tentatives d'émission non autorisées.
• ACME (Automatic Certificate Management Environment) : protocole (RFC 8555) d'automatisation de l'émission et du renouvellement de certificats, utilisé notamment par Let's Encrypt.
• Mis-issuance (mauvaise émission) : émission d'un certificat valide pour un domaine sans l'accord de son propriétaire, par erreur ou compromission de la CA.

Sources

1. RFC 8659 : DNS Certification Authority Authorization (CAA) Resource Record (IETF)
2. RFC 8657 : Certification Authority Authorization (CAA) Record Extensions for Account URI and ACME Method Binding (IETF)
3. CA/Browser Forum : Baseline Requirements
4. Ballot SC-085v2 : Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
5. Let's Encrypt : CAA (documentation officielle)