Configurer CAA sans bloquer les certificats et leur renouvellement

Le site fonctionne en HTTPS, mais son prochain certificat est refusé. Une politique CAA peut autoriser la mauvaise autorité, ou sa consultation DNS peut échouer. Le billet de Let’s Encrypt sur la gouvernance CAA invite à traiter cette politique comme une dépendance du renouvellement.

Intention de recherche : limiter les autorités de certification autorisées sans casser l’automatisation. Les exemples DNS sont fictifs ; letsencrypt.org est l’identifiant réel de cette autorité.

1. Examiner la politique réellement consultée

CAA indique quelles autorités peuvent émettre ; il ne remplace pas la preuve de contrôle du domaine et ne révoque pas les certificats existants. issue concerne l’émission ordinaire et, sans issuewild, les certificats wildcard. issuewild définit une politique spécifique aux wildcards. iodef fournit une destination de signalement ; il n’autorise aucune CA et ne garantit pas un rapport.

Listez tous les noms du certificat et les autorités utilisées par vos clients ACME, CDN et services tiers. Inspectez ensuite chaque nom, ses parents pertinents et ses CNAME :

Si votre version de nslookup ne gère pas CAA, utilisez dig. Une réponse NOERROR sans CAA au nom demandé n’est pas un refus : la recherche peut remonter aux parents. Les CNAME orientent aussi cette recherche vers leur cible. SERVFAIL n’est jamais équivalent à une politique vide valide.

2. Déployer une autorisation minimale mais complète

Risque : une restriction incorrecte laisse souvent le certificat actuel fonctionner, puis bloque son remplacement. Enregistrez les anciens CAA et leurs TTL avant de changer quoi que ce soit.

1. Faites l’inventaire des émetteurs nécessaires, y compris celui du proxy. Vérifiez l’identifiant CAA officiel de chaque CA, sans le déduire de son nom commercial.
2. Préparez la politique. Cet exemple autorise Let’s Encrypt pour les noms ordinaires et interdit l’émission wildcard :

1. Pour autoriser également les wildcards chez Let’s Encrypt, remplacez la valeur ";" de issuewild par "letsencrypt.org". Des autorisations multiples de même type sont additives ; ajouter un refus ne neutralise pas une autre autorisation.
2. Publiez les entrées sur la zone autoritative, puis interrogez tous ses NS. Ne placez pas un CAA au même nom qu’un CNAME standard.
3. Après convergence des caches, utilisez le test de renouvellement documenté par votre client ACME. Vérifiez les journaux : une réussite de consultation CAA ne prouve pas que le challenge ou le déploiement du certificat réussit.

Retour arrière

Restaurez la politique enregistrée si une CA nécessaire est bloquée. Contrôlez sa présence sur chaque NS, attendez les caches concernés, puis relancez le test. Si le problème est DNSSEC ou une indisponibilité DNS, supprimer CAA ne répare pas sa cause.

3. Vérification finale

Chaque nom du certificat doit aboutir à une politique autorisant l’émetteur prévu ; le wildcard suit sa règle dédiée. Documentez la date du test, la CA et le résultat du client. Conservez une surveillance de l’expiration et de l’exécution des renouvellements.

Erreurs courantes

Une faute dans l’identifiant de CA, un ancien CAA hérité, un CNAME vers une politique tierce ou une réponse DNSSEC invalide peuvent bloquer l’émission. Évitez les restrictions avancées de compte ou de méthode sans vérifier leur compatibilité. Ne prenez pas l’absence d’alerte iodef pour une preuve de bon fonctionnement.

Sources : Let’s Encrypt, gouvernance CAA, Let’s Encrypt, règles et dépannage CAA.