DNS-PERSIST-01 : un nouveau modèle pour la validation de défis basée sur le DNS

• Le DNS-PERSIST-01 de Let's Encrypt est un nouveau modèle de défi ACME qui remplace les validations répétées de la méthode DNS-01 existante par l’utilisation d’enregistrements de validation persistants
• Cette approche permet de prouver durablement le contrôle d’un domaine via des enregistrements TXT liés à un compte ACME spécifique et à une CA donnée
• Elle réduit les changements DNS et la charge de déploiement des identifiants d’API, renforçant à la fois l’efficacité opérationnelle et la sécurité
• Elle prend en charge des fonctions de contrôle fines comme les options de politique (policy=wildcard), la date d’expiration (persistUntil) et l’autorisation de plusieurs CA
• Un déploiement en staging est prévu pour la fin du T1 2026, suivi d’un rollout complet au T2, avec l’espoir de simplifier la gestion des certificats dans les environnements à grande échelle et automatisés

---

Limites de la méthode DNS-01

• Le défi DNS-01 existant nécessite de générer un nouveau jeton à chaque émission de certificat et d’ajouter un enregistrement TXT à _acme-challenge.
  • Chaque validation exige une mise à jour DNS, ce qui entraîne des délais de propagation et une automatisation plus complexe
• Dans les déploiements à grande échelle, les identifiants d’API DNS sont répartis sur plusieurs systèmes, ce qui augmente les risques de sécurité
• Certains abonnés souhaitent éviter ces modifications DNS répétées

Structure et fonctionnement de DNS-PERSIST-01

• Cette nouvelle méthode introduit le concept d’autorisation persistante
  • Il suffit de configurer une seule fois un enregistrement TXT sous _validation-persist. contenant la CA et l’URI du compte ACME
  • Ensuite, le même enregistrement peut être réutilisé pour les émissions et renouvellements ultérieurs
• Exemple :

  _validation-persist.example.com. IN TXT (  
    "letsencrypt.org;"  
    " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
  )  
  

• Cela retire les modifications DNS du chemin d’émission, améliorant ainsi l’efficacité opérationnelle

Équilibre entre sécurité et exploitation

• Avec DNS-01, le principal actif était le droit d’écriture sur le DNS ; avec DNS-PERSIST-01, l’élément clé devient la protection de la clé du compte ACME
• Après la configuration initiale, l’accès en écriture au DNS peut être limité, ce qui réduit la surface d’attaque
• En contrepartie, comme il s’agit d’une structure de validation persistante, la fuite d’une clé de compte augmente le risque ; il faut donc renforcer la gestion de la sécurité du compte

Contrôle de la portée et de la durée de vie

• Par défaut, la validation est valable indéfiniment uniquement pour le FQDN vérifié
• L’option policy=wildcard permet d’étendre la portée aux wildcards et aux sous-domaines

  "policy=wildcard"  
  

• L’attribut persistUntil permet de définir une date d’expiration (en secondes UTC)
  • Un renouvellement est nécessaire avant expiration, avec un système de supervision indispensable

  "persistUntil=1767225600"  
  

• Pour autoriser plusieurs CA simultanément, il faut ajouter des enregistrements TXT par CA sous _validation-persist.

Calendrier d’adoption et état de l’implémentation

• Le vote CA/Browser Forum SC-088v3 a été adopté à l’unanimité en octobre 2025, et le groupe de travail ACME de l’IETF a retenu le brouillon
• La prise en charge existe déjà dans Pebble (version allégée de Boulder), et une implémentation du client lego-cli est également en cours
• Staging à la fin du T1 2026, puis déploiement complet au T2
• Ce modèle convient particulièrement aux environnements où la méthode existante est inefficace, comme l’IoT, le multi-tenant et l’émission massive de certificats

Contexte sur Let's Encrypt et l’ISRG

• Let's Encrypt est une autorité de certification (CA) gratuite, automatisée et ouverte, exploitée par l’organisation à but non lucratif ISRG
• Le rapport annuel 2025 de l’ISRG présente ses activités liées à la sécurité de l’Internet

[GN⁺]

Commentaires Hacker News

• Je suis vraiment ravi de voir cette annonce
  Quand j’utilise bind comme serveur de noms faisant autorité, je le configure pour limiter le hmac-secret afin que chaque serveur web ne puisse mettre à jour que les enregistrements TXT qui le concernent
  Ainsi, même si le serveur « bob » est compromis, il ne pourra obtenir qu’un certificat pour le domaine « bob »
  Un exemple de configuration consiste à utiliser update-policy pour restreindre chaque clé afin qu’elle ne puisse modifier que les sous-domaines _acme-challenge

  • Si vous êtes prêt à exploiter un serveur DNS distinct au lieu de bind, acmedns offre une fonctionnalité similaire
    Lorsqu’on crée un nouveau compte, un sous-domaine unique lui est attribué, et si le domaine de challenge est configuré en CNAME vers ce sous-domaine, seul ce compte peut mettre à jour cette zone

• Je pense que cette fonctionnalité résout un gros irritant opérationnel dans la pratique
  En revanche, l’exposition de l’identifiant du compte d’administration m’inquiète
  Un nom d’utilisateur n’est pas protégé comme un secret d’authentification, mais il peut aider un attaquant à identifier sa cible
  Il est fort probable que des services comme Shodan indexent ce type d’ID et proposent une recherche inversée

  • Le champ accounturi des enregistrements CAA expose déjà un identifiant de compte, donc c’est en partie déjà public
    Je pense même qu’il vaut mieux que les formats CAA et persist soient cohérents
  • Il serait bien de fournir aux utilisateurs un identifiant aléatoire de type UUID à utiliser dans accounturi à la place du vrai compte
  • Comme il s’agit du même compte que celui créé par le client ACME, je ne pense pas que le risque de recherche inversée soit très élevé

• Je suis surpris que DNSSEC ne soit pas requis
  Autrefois, je trouvais DNSSEC pénible, mais aujourd’hui il existe tellement d’enregistrements qui influencent la confiance à la racine — CAA, CERT, SSHFP, TXT, etc. — qu’ils sont vulnérables aux attaques MITM
  Surtout que même de grandes entreprises déploient encore mal DNSSEC, donc cela devrait au moins être indiqué comme recommandation

  • Le brouillon de RFC recommande déjà l’usage de DNSSEC en « SHOULD » (lien)
  • Le DNS a toujours été un point de défaillance unique pour l’émission de certificats TLS
    Si un attaquant prend le contrôle du DNS, il peut falsifier un certificat via HTTP-01, TLS-ALPN-01 ou DNS-01
  • Personnellement, je pense que TLSA est une meilleure approche que DNSSEC, même si c’est dommage que les navigateurs ne le prennent presque pas en charge

• Grâce à cette fonctionnalité, il devrait devenir beaucoup plus simple d’émettre des certificats pour des serveurs LAN qui ne sont pas exposés à Internet
  À l’avenir, la plupart des interfaces d’administration devraient pouvoir générer automatiquement une chaîne à coller dans un enregistrement DNS pour obtenir directement un certificat Let’s Encrypt

  • J’ai essayé quelque chose de similaire dans un environnement comparable, mais la configuration de headscale magic DNS était plus compliquée que prévu, donc je suis finalement revenu au renouvellement manuel

• Pour les utilisateurs de certbot, on peut suivre l’état de la prise en charge de cette fonctionnalité dans cette issue GitHub

• J’étais autrefois sceptique vis-à-vis des certificats de courte durée, mais les certificats d’adresse IP et la validation HTTP-01 m’ont fait changer d’avis
  Désormais, je ne stocke plus les certificats sur disque, et un thread en arrière-plan vérifie chaque jour s’il existe un nouveau certificat
  Cela permet de créer une solution auto-hébergée où l’utilisateur peut déployer le logiciel sur une VM et être opérationnel en moins de 5 minutes
  Combiné à un service comme checkip.amazonaws.com, on peut obtenir un déploiement entièrement automatisé

  • En revanche, les limites d’émission de Let’s Encrypt ne sont pas négociables, donc si on fait trop de demandes, on risque de devoir attendre
  • Si l’on ne stocke absolument aucun certificat, la disponibilité dépendra de l’uptime de LE, donc un minimum de persistance reste nécessaire

• On dirait enfin qu’il devient plus facile à automatiser l’émission de certificats pour des services web internes uniquement
  J’ai vraiment l’impression que cela résout le plus gros problème opérationnel que nous avions jusqu’à présent

• Le point manquant ici, c’est la vérification de propriété du compte ACME
  La plupart des outils d’automatisation créent les comptes eux-mêmes, donc les utilisateurs ne les manipulent pas directement, mais il faudra désormais transmettre au fournisseur ACME des identifiants prouvant la propriété du compte
  Si Let’s Encrypt ne peut pas créer de jetons limités par domaine, il faudra peut-être créer un compte distinct pour chaque domaine

  • Mais les comptes ACME ont déjà des identifiants d’authentification, et la propriété du domaine est déjà vérifiée via les challenges DNS ou HTTP
    Donc si ces identifiants ou ces endpoints sont compromis, on est déjà face à un problème bien plus grave

• C’est vraiment une excellente nouvelle pour les utilisateurs de Dynamic DNS
  Par exemple, avec un service comme Namecheap où les requêtes de modification n’étaient possibles que depuis une IP fixe, il devient désormais possible d’automatiser le renouvellement une fois la configuration faite
  Je compte absolument essayer ça dans le cadre de la modernisation de mon homelab

• Sauf si j’ai mal compris, je me demande si quelqu’un qui contrôle le serveur DNS de mon domaine, ou qui intercepte le trafic entre Let’s Encrypt et le serveur DNS, pourrait obtenir un certificat TLS pour mon domaine
  C’est déjà vrai avec DNS-01, mais ici cela semble encore plus simple, puisqu’un attaquant n’aurait qu’à placer son propre compte LE dans la réponse DNS
  Je me demande s’il ne vaudrait pas mieux mettre directement mon certificat public dans le DNS

  • Si vous ne pouvez pas faire confiance à votre fournisseur DNS, c’est la relation elle-même qui pose problème
    Si quelqu’un peut faire une attaque MITM sur le trafic entre LE et le serveur DNS, alors la situation est déjà bien plus grave
  • Toute personne qui contrôle le DNS peut obtenir un certificat auprès de n’importe quelle AC
    Si le DNS peut être modifié, il n’existe pas de moyen d’empêcher l’émission d’un certificat
  • Si quelqu’un contrôle le DNS, il peut aussi réaliser un challenge HTTP, donc en pratique le domaine lui appartient
  • Les AC consultent déjà le DNS depuis plusieurs points afin d’atténuer ce type d’attaques réseau
    Let’s Encrypt fonctionne ainsi depuis des années, et depuis 2024 c’est une obligation pour toutes les AC
    Lien vers les règles du CAB Forum
  • En réalité, c’est l’approche adoptée par DANE
    Documentation connexe