Le problème
Une plateforme avec de nombreux sous-domaines, dont la plupart sont privés. Le challenge ACME classique (HTTP-01) valide chaque nom en servant un fichier sur le port HTTP public. Il faut donc exposer quelque chose pour chaque sous-domaine, y compris ceux qui n’ont rien à faire sur Internet. Et chaque certificat émis inscrit son nom dans les journaux de transparence des certificats, publics et scannés en continu : émettre un certificat par service revient à publier la carte de son infrastructure.
Le pattern
Le challenge DNS-01 prouve le contrôle du domaine plutôt que d’un
serveur web. Le client ACME pose un enregistrement TXT temporaire
(_acme-challenge.<domaine>) via l’API du registrar (OVH), Let’s Encrypt
le vérifie, le certificat est émis. Conséquences :
- Aucun port à ouvrir. La validation passe par le DNS plutôt que par le serveur.
- Wildcard possible (
*.domaine.fr) : un seul certificat couvre tous les sous-domaines, présents et futurs, sans les énumérer publiquement. - Renouvellement entièrement automatique, intégré au reverse proxy (résolveur ACME de Traefik), sans cron externe ni rechargement manuel.
Les pièges
- Le credential API devient le secret critique. Qui peut écrire dans la zone DNS peut émettre des certificats. Le token doit être limité au strict nécessaire (droits sur la zone concernée uniquement) et géré comme un secret de premier ordre (gestion des secrets).
- La propagation DNS n’est pas instantanée. Le client ACME doit attendre que le TXT soit visible des résolveurs de Let’s Encrypt. Les délais et TTL se configurent, sinon les échecs sont intermittents.
- Le renouvellement silencieux doit être surveillé. Automatique ne veut pas dire garanti : une expiration qui approche doit lever une alerte. C’est un des cas d’usage de l’observabilité prévue en roadmap.
Quand ne pas l’utiliser
Un seul domaine public, pas de sous-domaines privés, pas d’API DNS fiable : HTTP-01 est plus simple et suffit. DNS-01 vaut son coût dès qu’il y a du privé à protéger ou du wildcard à couvrir.