Sécuriser la validation de domaine HTTP-01 et DNS-01

La validation de domaine, ou DV (Domain Validation), décide qui peut obtenir un certificat public pour un nom donné. Elle ne prouve pas l’identité d’une organisation : elle prouve seulement le contrôle effectif d’un chemin HTTP ou d’une zone DNS à un instant donné. C’est une frontière de sécurité, pas une formalité de déploiement.

→ Lire l’explication complète de la marmotte

Domain Validation : ce que la preuve établit réellement

Une autorité de certification, ou AC, émet un certificat après avoir vérifié qu’un demandeur contrôle le domaine demandé. Pour un certificat de serveur, cette preuve permet au navigateur de faire confiance à la clé publique présentée par le serveur pendant une connexion TLS (Transport Layer Security). Le modèle est détaillé dans la PKI expliquée, mais un point mérite d’être martelé : la validation de domaine n’authentifie ni une personne morale, ni un service, ni une application saine.

Le compromis central est brutal : plus la validation est automatisée, plus le droit d’émettre un certificat se rapproche des identités techniques qui administrent HTTP ou DNS. On gagne des renouvellements fréquents, des certificats courts et moins de tickets d’exploitation. On paie avec une surface d’attaque concentrée sur le compte DNS, le pipeline de déploiement et les délégations de zone.

La recommandation est donc nette :

choisir HTTP-01 pour un service web unique, non wildcard, dont l’entrée HTTP publique est administrée par une chaîne de déploiement fortement contrôlée ;
choisir DNS-01 pour les certificats wildcard, les services sans entrée HTTP ou les architectures multi-ingress, mais uniquement avec une délégation DNS dédiée et un jeton d’automatisation limité ;
refuser les comptes de registrar utilisés comme identités d’automatisation de routine : un compte capable de transférer un domaine n’est pas un jeton de renouvellement, même si une slide le baptise « plateforme unifiée ».

Le protocole ACME (Automated Certificate Management Environment) orchestre souvent cette vérification, mais il n’est pas le sujet ici. Il transporte une preuve ; il ne rend pas cette preuve digne de confiance par magie. Un compte ACME compromis sans contrôle de domaine n’autorise pas l’émission. Un contrôle de domaine compromis, en revanche, peut autoriser une émission avec un compte ACME fraîchement créé.

HTTP-01 : contrôle du chemin web et détournements courants

HTTP-01 demande au client de publier une valeur imprévisible sous /.well-known/acme-challenge/ sur le nom à certifier. L’AC récupère cette valeur via HTTP public, généralement sur le port 80. Le jeton n’est pas secret : il est fait pour être lu depuis Internet. Sa sécurité dépend de l’intégrité du routage vers le bon serveur et de l’impossibilité pour un tiers de publier ce contenu.

HTTP-01 est incompatible avec les certificats wildcard. C’est une restriction saine : valider www.exemple.fr ne doit pas donner le droit d’émettre pour chaque sous-domaine futur, y compris celui qui hébergera un jour une console d’administration oubliée derrière un proxy.

Les détournements réalistes sont connus :

Attaque	Effet	Contre-mesure
Détournement DNS du nom	L’AC lit le jeton chez l’attaquant	Protéger le compte DNS, surveiller les changements et publier CAA
Prise de contrôle du proxy, de l’équilibreur ou du CDN (Content Delivery Network)	Publication du jeton sur la route publique	Séparer les droits de modification de route et les droits applicatifs
Sous-domaine pointant vers une ressource abandonnée	Un tiers revendique la ressource et répond au défi	Inventorier les enregistrements CNAME, supprimer les cibles orphelines
Règle de réécriture ou pare-feu applicatif	Échec ou remplacement de la réponse	Exempter explicitement le chemin de validation, tester depuis Internet
Déploiement applicatif arbitraire	Un attaquant dépose le jeton	Interdire l’écriture libre dans le répertoire servi publiquement

Le piège le plus banal reste le proxy frontal. Une application peut répondre parfaitement en réseau interne pendant que le répartiteur public redirige, met en cache, authentifie ou bloque le chemin de validation. Le test doit donc venir d’un réseau externe, viser le nom exact et vérifier le corps exact de la réponse. Un test local sur localhost ne démontre rien, à part la santé mentale relative du processus local.

HSTS (HTTP Strict Transport Security) ne remplace pas HTTP-01 et ne protège pas sa publication. L’AC doit pouvoir joindre le chemin défini par la méthode. Bloquer le port 80 peut être un choix défendable, mais il écarte alors HTTP-01. Le chiffrement de transport ne corrige pas une délégation de trafic déjà compromise. Fermer la porte à double tour en laissant le DNS décider de la maison reste une stratégie créative.

DNS-01 : wildcard, délégation et contrôle de la zone

DNS-01 demande la publication d’un enregistrement TXT sous _acme-challenge.nom.example. L’AC interroge le DNS (Domain Name System) public et vérifie la valeur attendue. Cette méthode valide le contrôle de la zone, ce qui explique à la fois sa puissance et son danger.

DNS-01 est obligatoire pour un wildcard tel que *.example.net. Il est aussi le bon choix lorsque le service n’expose pas HTTP : messagerie, passerelle privée, terminaison TLS hors ligne ou plusieurs points d’entrée. En revanche, placer un jeton d’API (Application Programming Interface) ayant droit d’écrire toute la zone dans chaque pipeline revient à distribuer le droit d’émettre des certificats pour tout le domaine. Le mot « DevSecOps » n’améliore pas l’entropie du jeton.

La bonne architecture délègue uniquement _acme-challenge.example.net à une zone séparée, administrée par une identité dédiée. Cette identité doit pouvoir créer et supprimer des TXT dans cette sous-zone, pas modifier les enregistrements A, MX, NS ou les règles du registrar. Une délégation par CNAME vers une zone de validation dédiée peut aussi convenir si l’AC choisie la résout correctement et si ce comportement est testé avant généralisation.

DNSSEC (Domain Name System Security Extensions) protège l’intégrité cryptographique des réponses DNS entre zones signées et résolveurs validateurs. Il ne protège pas un compte DNS compromis, ni un jeton d’API trop large. Un attaquant qui peut publier une réponse signée dispose précisément de la clé nécessaire pour signer son mensonge. La cryptographie refuse rarement une mauvaise décision d’administration.

La propagation reste une source d’échec : le TTL (Time To Live) définit combien de temps un résolveur peut conserver une réponse, mais il ne force pas tous les caches à oublier instantanément l’ancienne valeur. Avant une validation, vérifier les serveurs faisant autorité, pas seulement le résolveur local. Après validation, supprimer le TXT temporaire si l’outil ne le gère pas lui-même ; conserver un jeton ancien n’aide aucun renouvellement et complique le diagnostic.

Exemple DNS-01 avec une zone de validation dédiée

L’exemple suivant montre une délégation de _acme-challenge.example.net vers une zone limitée. Il faut un serveur BIND 9 (Berkeley Internet Name Domain) faisant autorité et une clé TSIG (Transaction Signature) réservée au client d’émission. La valeur TXT reste fournie par le client de certificats : elle ne doit jamais être inventée ni réutilisée.

; Zone parente example.net : déléguer uniquement la validation de certificats.
_acme-challenge.example.net. 300 IN NS ns1.acme.example.net.

; Zone acme.example.net : le client autorisé écrit seulement des TXT.
$ORIGIN _acme-challenge.example.net.
@ 300 IN SOA ns1.acme.example.net. hostmaster.example.net. (
  2026092301 3600 600 1209600 300 )
@ 300 IN NS ns1.acme.example.net.

; Valeur créée temporairement par le client d'émission.
www 300 IN TXT "valeur-de-validation-fournie-par-le-client"

# Vérifier la réponse du serveur faisant autorité, sans dépendre du cache local.
dig @ns1.acme.example.net TXT www._acme-challenge.example.net +short

# Le résultat doit contenir exactement la valeur publiée par le client.
# Si rien ne répond, vérifier la délégation NS depuis la zone parente.
dig @ns1.example.net NS _acme-challenge.example.net +short

La clé TSIG doit être stockée dans un gestionnaire de secrets, injectée au moment de l’exécution et renouvelée sans chevauchement indéfini. Une clé sans date de fin est un abonnement à l’archéologie numérique. Les journaux du serveur DNS doivent tracer chaque mise à jour dynamique, avec l’identité de la clé et le nom modifié.

CAA, supervision et exploitation du droit d’émettre

CAA (Certification Authority Authorization) est un enregistrement DNS qui indique quelles AC sont autorisées à émettre pour un domaine. Il réduit l’impact d’un mauvais choix d’AC ou d’une tentative d’émission auprès d’une AC non approuvée. Il ne bloque pas un attaquant qui contrôle DNS et utilise une AC déjà autorisée. CAA est une barrière de réduction de périmètre, pas un garde du corps.

Chaque domaine public devrait disposer d’une politique CAA explicite, incluant les émissions normales et, si nécessaire, les certificats wildcard. Toute modification de CAA, de délégation NS, de CNAME de validation ou de compte registrar doit déclencher une alerte. La surveillance des journaux CT (Certificate Transparency) complète ce dispositif : une émission inattendue devient détectable après publication du certificat. Elle ne l’empêche pas.

L’exploitation doit aussi couvrir les éléments moins glamour, donc les éléments qui cassent :

renouveler avant expiration avec une marge supérieure au délai de correction DNS et aux limites de débit de l’AC ;
séparer la clé privée du certificat, la clé de compte ACME et le jeton DNS : leur compromission n’a ni le même impact ni la même rotation ;
sauvegarder les zones DNS, les clés de signature DNSSEC et la configuration d’automatisation chiffrée, mais éviter de sauvegarder largement les clés privées de serveur, qui doivent pouvoir être régénérées ;
tester la restauration d’une zone et la révocation depuis une identité distincte du pipeline ordinaire ;
surveiller les certificats émis, les erreurs de validation, les changements DNS et les dates d’expiration.

La révocation réduit l’exposition future mais n’annule pas les sessions TLS déjà établies. Elle dépend aussi du comportement des clients, des caches et des mécanismes de vérification. Pour les usages à haute sensibilité, il faut donc ajouter une authentification applicative et, lorsque le cas d’usage le justifie, du TLS mutuel. Un certificat valide prouve le contrôle d’un nom, pas la légitimité de chaque processus derrière ce nom.

🐝 Ce qui arrive si on s’en passe

Sans validation de domaine soignée, le contrôle qui décide qui peut obtenir un certificat public pour un nom donné devient franchissable. Comme la validation prouve seulement le contrôle effectif d’un chemin HTTP ou d’une zone DNS à un instant donné, une faiblesse à ce point précis, une ressource oubliée servie sur le domaine, un enregistrement DNS manipulable, un sous-domaine délaissé, permet à un tiers de démontrer un contrôle qu’il ne devrait pas avoir. La conséquence est l’émission d’un certificat légitime pour un nom qui n’appartient pas au demandeur, ouvrant la voie à l’usurpation du service et à l’interception de ses connexions sans alerte navigateur. La validation n’étant qu’une preuve de contrôle et non d’identité ni d’intention, la négliger revient à laisser n’importe qui capable de toucher brièvement le domaine repartir avec un document officiel à son nom.

🦫 Explication de la marmotte 🍫

Pour obtenir un certificat public, une autorité de certification vérifie que la personne ou le programme qui le demande contrôle bien le nom de domaine. Ce certificat permet ensuite à un navigateur de vérifier qu’il parle à un serveur autorisé à utiliser ce nom et de chiffrer les échanges.

Avec la méthode HTTP-01, le demandeur publie un texte précis à une adresse web imposée. L’autorité vient lire ce texte depuis Internet. Si le texte est trouvé au bon endroit, elle accepte la demande. Cette méthode échoue si le site web, le routeur qui le précède ou le nom de domaine envoie la demande vers un autre endroit. Elle ne permet pas de demander un certificat couvrant tous les sous-domaines.

Avec la méthode DNS-01, le demandeur ajoute un texte précis dans les informations publiques qui dirigent les noms de domaine. Cette méthode permet de couvrir tous les sous-domaines, mais elle donne beaucoup de pouvoir au compte capable de modifier ces informations. Si ce compte est volé, un attaquant peut demander un certificat et imiter le site.

Il faut donc limiter les droits du programme de renouvellement, surveiller les nouveaux certificats et les changements de domaine, puis remplacer rapidement les accès compromis. Le certificat ne vérifie pas qu’une entreprise est honnête, que le serveur est sain ou que l’application protège les données. Ces protections doivent venir d’autres contrôles.

Pages voisines

La citent

Sécuriser la validation de domaine HTTP-01 et DNS-01

Elle cite

: les deux pages se citent l’une l’autre.

Sécuriser la validation de domaine HTTP-01 et DNS-01

Sécuriser la validation de domaine HTTP-01 et DNS-01

Domain Validation : ce que la preuve établit réellement

HTTP-01 : contrôle du chemin web et détournements courants

DNS-01 : wildcard, délégation et contrôle de la zone

Exemple DNS-01 avec une zone de validation dédiée

CAA, supervision et exploitation du droit d’émettre

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines