Un éditeur SaaS découvre un certificat TLS valide pour app.example.com émis par une autorité qu'il n'a jamais contactée. Le site fonctionne, le cadenas est vert, personne n'a reçu d'alerte. En creusant, l'équipe retrouve une validation DNS passée trois semaines plus tôt — probablement après une compromission d'accès au registrar ou d'un compte chez le fournisseur DNS. Sans enregistrement CAA, aucune règle n'interdisait cette émission.
Le CAA (Certification Authority Authorization) est un petit enregistrement DNS, souvent oublié, qui répond à une question simple : qui a le droit de signer un certificat pour ce nom ?
Ce que le CAA autorise — et ce qu'il ne fait pas
Un enregistrement CAA ne chiffre rien et ne remplace pas HTTPS. Il indique aux autorités de certification (CA) quelles entités peuvent émettre un certificat pour votre domaine. Depuis 2017, les CA membres du CA/B Forum doivent vérifier le CAA avant signature — sauf cas très limités.
| Tag CAA | Effet | Exemple |
|---|---|---|
issue | Autorise une CA pour certificats standards | 0 issue "letsencrypt.org" |
issuewild | Autorise une CA pour les wildcards (*.domain) | 0 issuewild "digicert.com" |
iodef | Adresse de notification en cas de demande non conforme | 0 iodef "mailto:secu@example.com" |
Le CAA ne protège pas contre une CA qui ignorerait la règle (rare mais documenté historiquement). Il ne bloque pas non plus un attaquant qui contrôle déjà votre serveur web ou votre clé privée. Il ferme surtout la porte la plus silencieuse : l'émission frauduleuse via validation DNS ou HTTP.
Sans CAA, toute CA reconnue peut tenter de valider votre domaine. Avec CAA, vous réduisez la surface à la liste blanche que vous définissez.
Quand le CAA devient indispensable
Trois situations le rendent prioritaire :
Renouvellement automatique. Let's Encrypt, ZeroSSL ou un ACME interne : si vous restreignez les CA sans inclure la vôtre, le renouvellement casse à minuit un dimanche.
Multi-fournisseurs. CDN, hébergeur, load balancer — chacun peut proposer son propre certificat. Le CAA force une décision explicite plutôt qu'une émission opportuniste.
Domaines à forte visibilité. E-commerce, authentification, API publiques : un certificat parallèle permet l'interception sans toucher votre infrastructure principale.
Syntaxe concrète selon votre stack
Exemple minimal pour un site Let's Encrypt uniquement :
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
Si vous passez par Cloudflare pour TLS et gardez Let's Encrypt en origine :
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
Cloudflare utilise DigiCert pour ses certificats edge ; Let's Encrypt reste fréquent côté serveur. Omettre l'un des deux provoque des échecs de renouvellement difficiles à diagnostiquer.
| Scénario | CA à autoriser | Piège fréquent |
|---|---|---|
| VPS + Certbot | letsencrypt.org | Oublier issuewild alors qu'un *.domain existe |
| CDN orange cloud | CA du CDN + CA origine | Ne lister que Let's Encrypt |
| Certificat EV entreprise | Votre CA contractuelle uniquement | Bloquer par erreur le staging interne |
Erreurs qui cassent la prod un vendredi soir
CAA trop restrictif avant migration. Changez de CA ? Mettez à jour le CAA avant de lancer la nouvelle émission, pas après.
TTL long + propagation. Un CAA erroné peut mettre des heures à se corriger selon le TTL. Baissez-le temporairement lors d'un changement.
Sous-domaine avec CAA vide. Un enregistrement CAA vide (;) sur un sous-domaine interdit toute émission pour ce sous-domaine — utile en sécurité, fatal si involontaire.
Confusion avec SPF/DKIM. Le CAA ne concerne que les certificats X.509, pas l'email.
Le sommet : le cadenas vert ne prouve pas que c'est votre certificat
C'est le point que les checklists « HTTPS activé » eludent : la présence de TLS ne garantit pas l'unicité du signataire. Surveillez les Certificate Transparency logs et combinez CAA + alertes sur émissions inattendues.
Décider et avancer sans angle mort
- Inventoriez qui émet aujourd'hui vos certificats (origine, CDN, staging).
- Publiez les enregistrements CAA correspondants,
issueetissuewildsi besoin. - Testez un renouvellement ACME en dry-run avant de verrouiller.
- Ajoutez une adresse
iodefvers votre équipe sécurité ou un alias monitored. - Documentez la procédure de changement de CA dans votre runbook.
Pour comparer les hébergeurs qui intègrent ACME ou certificats managés, consultez notre annuaire et le comparateur. Le guide DNSSEC complète cette approche si vous durcissez toute la chaîne DNS.
Questions fréquentes
Qu'est-ce qu'un enregistrement CAA exactement ?
C'est un enregistrement DNS (type CAA) qui liste les autorités de certification autorisées à émettre des certificats pour un domaine ou une wildcard. Les CA sérieuses le consultent avant de signer.
Le CAA remplace-t-il le renouvellement automatique Let's Encrypt ?
Non. Il le cadre. Si vous utilisez Let's Encrypt, ajoutez letsencrypt.org dans vos enregistrements CAA — sinon le renouvellement échouera à la prochaine échéance.
Faut-il un CAA sur chaque sous-domaine ?
Non. Les résolveurs remontent la chaîne DNS : un CAA sur example.com s'applique aux sous-domaines sauf si un CAA plus spécifique existe sur le sous-domaine concerné.
Comment vérifier que le CAA est actif ?
Interrogez le DNS avec dig CAA example.com ou un outil en ligne, puis tentez une émission test depuis une CA non listée — elle doit refuser.
La prochaine fois qu'on vous dira « le site est en HTTPS, c'est bon », demandez aussi : qui a le droit de signer pour ce domaine ?