# CAA, l’enregistrement DNS discret qui peut bloquer vos certificats TLS > Un renouvellement Let's Encrypt échoue sans qu'aucun paramètre serveur n'ait bougé. L'enregistrement CAA, souvent oublié, est parfois le seul responsable. - Auteur : Clément Hadrot - Publié le : 2021-02-25 - Mis à jour le : 2021-02-25 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/caa-enregistrement-dns-bloque-certificats-tls/ ## L’essentiel - CAA restreint quelles autorités peuvent émettre un certificat - Un enregistrement oublié depuis des années peut bloquer un renouvellement - dig reste l'outil le plus rapide pour diagnostiquer Rien n'avait changé sur le serveur. Le renouvellement automatique de Certbot tournait depuis des mois sans incident, planifié en tâche cron, silencieux et fiable. Et pourtant, un matin, l'échéance de renouvellement a échoué avec un message d'erreur sec : autorisation refusée par le domaine. Aucune modification de configuration nginx, aucun changement de DNS visible dans les enregistrements A ou CNAME habituels. La piste, cette fois, se trouvait ailleurs : dans un enregistrement DNS que presque personne ne pense à vérifier, le CAA. CAA, pour Certification Authority Authorization, est un type d'enregistrement DNS qui restreint quelles autorités de certification sont autorisées à émettre un certificat pour un domaine donné. Depuis septembre 2017, ce contrôle est devenu obligatoire pour toutes les autorités de certification publiques : avant d'émettre le moindre certificat, elles doivent interroger le DNS du domaine et respecter ce qu'il déclare, sous peine de sanction par les programmes racine des navigateurs. ## Comment un enregistrement CAA bloque un renouvellement Un enregistrement CAA prend la forme suivante dans une zone DNS : ``` exemple.fr. IN CAA 0 issue "letsencrypt.org" ``` Cette ligne autorise explicitement Let's Encrypt à émettre des certificats pour le domaine, et implicitement, interdit toute autre autorité non listée. Le problème survient quand cet enregistrement a été posé pour une autre raison, il y a des années, par exemple pour restreindre l'émission à une autorité de certification commerciale utilisée à l'époque, puis oublié après un changement de prestataire TLS vers Let's Encrypt. ``` exemple.fr. IN CAA 0 issue "sectigo.com" ``` Avec un tel enregistrement en place et aucune ligne mentionnant `letsencrypt.org`, chaque tentative de Certbot pour émettre ou renouveler un certificat échoue silencieusement du point de vue du serveur : le blocage se produit côté autorité de certification, qui refuse simplement d'émettre, conformément à ce que le CAA lui impose de respecter. ## Diagnostiquer en moins d'une minute avec dig > L'essentiel à retenir : CAA restreint quelles autorités peuvent émettre un certificat ; Un enregistrement oublié depuis des années peut bloquer un renouvellement ; dig reste l'outil le plus rapide pour diagnostiquer Face à un échec de renouvellement TLS sans cause évidente côté serveur, la vérification du CAA doit devenir un réflexe précoce, avant de perdre du temps à éplucher les logs Certbot en détail : ``` dig CAA exemple.fr +short ``` Si la commande ne retourne rien, aucun enregistrement CAA n'est en place, ce qui autorise par défaut n'importe quelle autorité de certification à émettre pour ce domaine : ce n'est donc pas la source du blocage. Si elle retourne une ou plusieurs lignes ne mentionnant pas `letsencrypt.org`, la cause est identifiée : il faut ajouter ou corriger l'enregistrement chez le gestionnaire de la zone DNS. ## Corriger sans tout casser La correction elle-même est simple, mais deux pièges méritent d'être connus avant de la faire à la légère : - Un domaine peut avoir plusieurs enregistrements CAA simultanés, un par autorité autorisée : ajouter une ligne pour Let's Encrypt ne doit pas nécessairement supprimer les autres, si d'autres certificats émis par d'autres autorités sont encore utilisés ailleurs sur des sous-domaines ou services liés. - Le TTL de l'enregistrement CAA doit être pris en compte avant de relancer le renouvellement : un TTL élevé, hérité d'une configuration ancienne, peut retarder la prise en compte du changement de plusieurs heures côté résolveurs utilisés par l'autorité de certification. - Le paramètre `iodef` peut être ajouté en complément pour recevoir une notification en cas de tentative d'émission non autorisée détectée par une autorité respectueuse du protocole, un signal utile en cas de compromission suspectée d'un compte chez un registrar. ``` exemple.fr. IN CAA 0 issue "letsencrypt.org" exemple.fr. IN CAA 0 iodef "mailto:securite@exemple.fr" ``` ## Pourquoi ce piège est plus fréquent qu'on ne le pense Le CAA a ceci de particulier qu'il est souvent posé une seule fois, par précaution ou par défaut lors d'une migration DNS chez un nouveau registrar, puis jamais revisité. Contrairement à un enregistrement A ou MX, dont l'absence ou l'erreur se remarque immédiatement (site inaccessible, emails qui n'arrivent plus), un CAA mal configuré ne se manifeste qu'au moment précis où une autorité de certification tente d'émettre un certificat, ce qui, avec un renouvellement automatique tous les 90 jours chez Let's Encrypt, peut laisser passer plusieurs mois avant que le problème ne surgisse. > Sur chaque nouveau serveur que nous provisionnons, la vérification `dig CAA` du domaine fait désormais partie de la checklist de mise en production, au même titre que la vérification des enregistrements MX. Ce n'est pas la cause la plus fréquente d'échec TLS, mais c'est la plus longue à diagnostiquer si on ne pense pas à la chercher directement. ## En résumé Un échec de renouvellement TLS sans cause serveur évidente mérite un réflexe précis : vérifier l'enregistrement CAA du domaine avant toute autre hypothèse. Ce contrôle, obligatoire depuis 2017 pour toutes les autorités de certification, reste l'un des enregistrements DNS les plus discrets et les plus facilement oubliés d'une zone, précisément parce qu'il ne se manifeste que le jour où il bloque quelque chose.