Lorsqu’un site web utilise HTTPS, un certificat numérique garantit que la connexion est chiffrée et que le domaine présenté est bien celui attendu. Mais une question reste souvent invisible : qui a le droit d’émettre ce certificat ? C’est précisément le rôle d’un enregistrement DNS CAA, un mécanisme discret mais important pour renforcer la confiance autour des certificats TLS.
Un enregistrement DNS CAA, pour Certification Authority Authorization, est un type d’enregistrement DNS qui permet au propriétaire d’un nom de domaine d’indiquer quelles autorités de certification sont autorisées à délivrer des certificats pour ce domaine. En pratique, il s’agit d’une règle publiée dans la zone DNS, au même titre qu’un enregistrement A, AAAA, MX ou TXT.
Son objectif est simple : limiter le risque qu’une autorité de certification émette par erreur, ou à la suite d’une compromission, un certificat pour un domaine qu’elle ne devrait pas gérer. Avant de délivrer un certificat TLS, une autorité de certification doit vérifier si un enregistrement CAA existe. Si c’est le cas, elle doit respecter les instructions indiquées.
Ce mécanisme ne remplace pas les contrôles classiques de validation de domaine, mais il ajoute une couche de sécurité. Il donne au titulaire du domaine un moyen public de dire : “seules ces autorités peuvent émettre des certificats pour moi”. Depuis 2017, les règles du CA/Browser Forum imposent aux autorités de certification publiques de consulter les enregistrements CAA avant l’émission d’un certificat.
Le système des certificats repose sur un grand nombre d’acteurs de confiance. Des dizaines d’autorités de certification publiques peuvent techniquement émettre un certificat pour un domaine, à condition de réussir la validation requise. Cette architecture ouverte facilite l’interopérabilité, mais elle augmente aussi la surface de risque.
Avec un enregistrement CAA, l’administrateur d’un domaine réduit cette surface. Si l’entreprise utilise uniquement Let’s Encrypt, DigiCert ou Sectigo, elle peut l’indiquer dans le DNS. Une autre autorité, même reconnue par les navigateurs, devra refuser l’émission si elle n’est pas listée. C’est un contrôle préventif, particulièrement pertinent pour les organisations qui veulent encadrer strictement leur gestion des certificats.
Le CAA est également utile en cas de délégation. Une société peut confier la gestion technique de son site à un prestataire, tout en gardant la maîtrise des autorités autorisées. Cette séparation limite les erreurs humaines, les demandes non conformes et les certificats émis en dehors des processus internes.
Le CAA est publié dans le DNS du domaine concerné. Lorsqu’une autorité de certification reçoit une demande de certificat, elle interroge le DNS pour savoir si le domaine contient un enregistrement CAA. Si aucun CAA n’est trouvé, l’autorité peut poursuivre la procédure normale de validation. Si un ou plusieurs enregistrements existent, elle doit vérifier qu’elle est bien autorisée.
Le fonctionnement repose donc sur la résolution DNS. Selon les cas, les requêtes peuvent transiter par UDP ou TCP, notamment en fonction de la taille des réponses ou des contraintes réseau. Pour mieux comprendre ce point, le rôle complémentaire d’UDP et TCP dans le DNS explique pourquoi les deux modes coexistent dans l’infrastructure de résolution.
La recherche CAA peut aussi tenir compte de la hiérarchie du DNS. Si un sous-domaine ne possède pas son propre enregistrement CAA, l’autorité de certification peut remonter vers le domaine parent pour trouver une règle applicable. Par exemple, une règle définie sur example.com peut concerner www.example.com si rien de plus spécifique n’est publié au niveau du sous-domaine.
Un enregistrement CAA se compose généralement de trois éléments : un indicateur numérique, une propriété et une valeur. L’indicateur est souvent à 0. La propriété définit le type d’instruction. La valeur précise l’autorité ou l’information associée. Une entrée typique peut ressembler à : example.com. CAA 0 issue "letsencrypt.org".
Les propriétés les plus courantes sont peu nombreuses, mais elles couvrent les besoins essentiels. Elles permettent notamment de distinguer les certificats standards, les certificats wildcard et les informations de contact en cas de problème.
La différence entre issue et issuewild mérite une attention particulière. Un domaine peut autoriser une autorité pour les certificats ordinaires, tout en interdisant les certificats wildcard. Cette granularité est utile, car un certificat wildcard couvre un ensemble étendu de sous-domaines et représente donc un enjeu de sécurité plus important.
Dans un cas simple, une organisation qui utilise uniquement Let’s Encrypt peut publier une règle autorisant cette autorité : example.com. CAA 0 issue "letsencrypt.org". Cela signifie qu’une autre autorité publique ne devrait pas délivrer de certificat pour ce domaine. Si l’entreprise utilise aussi une autre autorité, elle peut publier plusieurs enregistrements CAA, chacun visant un fournisseur différent.
Pour interdire les certificats wildcard, il est possible de définir une règle issuewild vide. Par exemple : example.com. CAA 0 issuewild ";". Cette configuration indique qu’aucune autorité n’est autorisée à émettre un certificat wildcard pour le domaine. À l’inverse, une entreprise peut autoriser une autorité pour les certificats classiques et une autre pour les certificats wildcard, si son organisation interne le justifie.
L’entrée iodef peut être utile dans les environnements surveillés. Elle permet de recevoir des notifications lorsqu’une autorité détecte une demande non conforme aux règles CAA. Dans les faits, son adoption varie selon les autorités, mais elle reste un moyen intéressant de documenter un canal de signalement.
L’enregistrement CAA intervient avant l’émission du certificat, pas au moment où l’internaute visite le site. Le navigateur ne consulte généralement pas le CAA pour décider si une page HTTPS est fiable. Il vérifie plutôt la validité du certificat, sa chaîne de confiance, son nom de domaine, sa date d’expiration et d’autres paramètres liés à TLS.
Le CAA agit donc en amont, dans la chaîne de délivrance. Il ne chiffre pas la connexion et ne modifie pas le contenu du certificat. En revanche, il influence les conditions dans lesquelles ce certificat peut être obtenu. C’est pourquoi il complète, sans les remplacer, les bonnes pratiques liées à HTTPS, au renouvellement des certificats et à la configuration TLS du serveur.
Dans les hébergements mutualisés et les architectures modernes, le serveur doit aussi présenter le bon certificat en fonction du nom de domaine demandé. Ce mécanisme est lié à l’extension SNI utilisée dans TLS, qui permet de gérer plusieurs certificats sur une même adresse IP.
Le CAA n’est efficace que s’il est correctement configuré. Une erreur dans le nom de l’autorité, une règle trop restrictive ou un oubli sur un sous-domaine peut bloquer l’émission ou le renouvellement d’un certificat. Ce type d’incident peut entraîner une expiration non anticipée, avec un impact direct sur l’accès au site.
Il faut aussi tenir compte des chaînes de délégation DNS, des CNAME et des plateformes tierces. Certaines solutions SaaS, CDN ou hébergeurs automatisent les certificats via leur propre autorité. Si le domaine impose une règle CAA incompatible, la génération du certificat peut échouer. Avant d’ajouter une restriction, il est donc recommandé d’identifier tous les services qui émettent des certificats pour le domaine.
Autre point important : le CAA ne protège pas contre toutes les menaces. Il ne bloque pas un attaquant qui aurait déjà compromis le serveur, ne remplace pas DNSSEC et ne garantit pas qu’une autorité autorisée ne commettra jamais d’erreur. Il s’agit d’un mécanisme de contrôle, pas d’une solution de sécurité globale.
Avant de publier un CAA, il convient de dresser l’inventaire des certificats utilisés : site principal, sous-domaines, API, messagerie, CDN, environnements de test et outils internes. Cette cartographie évite d’exclure involontairement une autorité de certification nécessaire au fonctionnement d’un service.
La règle la plus prudente consiste à commencer avec une configuration claire et limitée, puis à la tester. Il est préférable de documenter les autorités autorisées, les raisons de ce choix et les personnes responsables des modifications DNS. Dans les grandes organisations, le CAA doit être intégré à la politique de gestion des certificats, avec un processus de validation en cas de changement.
Enfin, la surveillance reste essentielle. Les enregistrements DNS doivent être revus régulièrement, notamment lors d’un changement d’hébergeur, de CDN ou de fournisseur de certificats. Un CAA oublié peut devenir un obstacle au renouvellement automatique, alors qu’un CAA trop permissif perd une partie de son intérêt. Bien utilisé, l’enregistrement DNS CAA offre un moyen simple, peu coûteux et efficace de renforcer la gouvernance des certificats numériques.
