Enregistrement CAA : qui peut émettre vos certificats ?

Un enregistrement CAA, sigle de Certification Authority Authorization, est un enregistrement DNS qui permet au propriétaire d'un domaine de déclarer quelles autorités de certification sont autorisées à émettre des certificats TLS publics pour les noms du domaine. Les autorités de certification consultent la politique CAA lors de l'émission, lorsque les règles applicables l'exigent. L'enregistrement ne chiffre pas le trafic, n'installe pas de certificat et ne garantit pas qu'un site est sûr. C'est un contrôle supplémentaire sur l'émission : un moyen de rendre visibles dans le DNS les émetteurs de certificats voulus par le domaine, et de réduire le risque qu'une autorité non prévue émette un certificat alors que la politique du propriétaire du domaine ne l'autorise pas.

Ce que contient une politique CAA

Les enregistrements CAA utilisent des flags, une balise de propriété et une valeur. La propriété courante « issue » désigne une autorité autorisée à émettre des certificats, tandis que « issuewild » s'applique aux certificats génériques. La propriété « iodef » peut indiquer une destination de signalement pour les rapports de violation de politique, lorsqu'elle est prise en charge. La syntaxe réelle de l'enregistrement inclut l'identifiant documenté de l'autorité de certification émettrice, et ces identifiants ne sont pas des noms de marque interchangeables : utilisez la valeur exacte publiée par le fournisseur de certificats. Un domaine peut publier plus d'un émetteur autorisé. Lorsqu'une politique existe, un émetteur non listé peut se voir empêché d'émettre, sous réserve des règles de traitement DNS et des autorités de certification applicables.

La politique CAA suit les relations entre noms DNS. Un nom sans données CAA propres peut hériter de la politique pertinente la plus proche plus haut dans la hiérarchie du domaine, tandis qu'un CNAME peut influencer l'endroit où se trouvent les données applicables selon les règles DNS. Il est donc important de vérifier le nom exact pour lequel un certificat est demandé, et pas seulement le domaine racine. L'émission de certificats génériques mérite aussi une attention distincte : une politique qui autorise une autorité de certification pour les noms ordinaires peut ne pas traduire la même intention pour les certificats génériques si issuewild est présent. Vérifiez les normes en vigueur et les instructions de l'autorité de certification avant de vous appuyer sur une interprétation précise.

Planifier les changements avant de publier une restriction

Un enregistrement CAA restrictif peut bloquer le renouvellement légitime d'un certificat s'il omet l'autorité qu'utilisent votre plateforme d'hébergement ou votre automatisation de certificats. Avant d'en ajouter un, dressez l'inventaire de tous les services qui obtiennent des certificats pour le domaine, y compris les sous-domaines, l'hébergement géré, les points de terminaison de CDN et les systèmes de préproduction qui utilisent des certificats publiquement reconnus. Demandez à chaque fournisseur son identifiant CAA officiel et les enregistrements qu'il exige. Publiez ensuite les enregistrements et interrogez-les publiquement pour confirmer les valeurs. Coordonnez les changements avec les calendriers de renouvellement et surveillez la prochaine émission ou le prochain renouvellement, plutôt que de supposer qu'un enregistrement syntaxiquement valide signifie que chaque intégration est correctement configurée.

• Utilisez les valeurs CAA exactes de la documentation actuelle de l'autorité de certification.
• Vérifiez à la fois le nom racine et le sous-domaine précis qui reçoit un certificat.
• Tenez compte séparément de la politique des certificats génériques.
• Ne retirez pas un émetteur actuel avant que toute l'automatisation des certificats ait été migrée.
• Revérifiez les données CAA après un changement de fournisseur DNS ou une migration de plateforme de certificats.

Ce que CAA ne résout pas

CAA est une couche de gouvernance de l'émission des certificats, pas un substitut à la protection des comptes DNS, à la sécurisation de l'enregistrement du domaine, au renouvellement des certificats ou à la bonne configuration de HTTPS. Il ne révoque pas à lui seul un certificat existant, et il ne peut pas empêcher toutes les compromissions possibles de domaine ou de compte. L'enregistrement n'indique pas non plus à un navigateur si le certificat actuellement servi par un site web est valide : les navigateurs valident le certificat présenté pendant la connexion. Si un certificat est manquant ou incorrect, inspectez le point de terminaison TLS en direct en plus de la politique DNS.

Pour dépanner un échec d'émission, inspectez la réponse DNS, vérifiez l'identifiant de l'émetteur et contrôlez si le nom d'hôte demandé a hérité d'une politique ou l'a remplacée. Comparez les données publiées aux exigences actuelles du fournisseur de certificats. Pour le vocabulaire DNS général utilisé par CAA, consultez les types d'enregistrements DNS expliqués. CAA est un enregistrement précieux lorsque son responsable opérationnel comprend le chemin de renouvellement, mais une restriction négligente peut provoquer une panne au moment précis où un certificat automatisé arrive à échéance. Traitez-le comme une configuration qui exige une maintenance tout au long de son cycle de vie, et non comme une case de sécurité à cocher une fois pour toutes.

Garder la politique CAA alignée sur l'automatisation des certificats

L'émission de certificats peut être automatisée par plusieurs services à la fois : un hébergeur peut provisionner le certificat du site principal, un CDN peut renouveler un certificat de périphérie, et une plateforme distincte peut couvrir un portail client. Dressez un inventaire simple des noms de certificats, des émetteurs, de l'usage de certificats génériques et des responsables du renouvellement avant de restreindre CAA. Revoyez-le chaque fois que l'infrastructure ou la propriété du domaine change. Si un renouvellement échoue après une mise à jour de la politique, vérifiez le nom d'hôte réel, la politique héritée et l'identifiant de l'émetteur avant de retirer entièrement la restriction. Publiez une correction soigneusement délimitée et confirmez que le fournisseur peut mener à bien un renouvellement. Cette approche préserve l'intérêt de sécurité d'une émission autorisée tout en évitant une situation d'urgence où chaque responsable de service tente d'ajouter de larges permissions sans savoir quel flux de certificat est bloqué.