Résumé

  • DNS-01 démontre qu’un compte ACME possède sa clé et sait faire apparaître le condensat attendu au nom de validation observé par l’AC. Une délégation CNAME ou NS peut confier ce pouvoir sans donner la zone parente ni l’application.
  • Autorisation, portée générique, CSR, émission, stockage, installation, transparence et révocation sont des états distincts. Effacer un TXT ou un compte fournisseur n’en clôt pas la chaîne.

Un départ administratif, une capacité encore active

La zone déléguée est une frontière d’exploitation. Let’s Encrypt documente que sa résolution DNS-01 suit CNAME ou NS pour confier _acme-challenge à une zone spécialisée. C’est utile : le serveur web n’a pas besoin d’un jeton capable de modifier tout le DNS. Mais l’autorité technique survit tant que la délégation, le compte ACME et sa clé restent utilisables.

Le cas d’ouverture est un test de contrôle, pas un incident attribué. Il révèle une erreur fréquente de modèle : supprimer un rôle applicatif n’annule pas une capacité publiée dans un autre plan.

La preuve porte deux conditions

RFC 8555 fournit un jeton aléatoire d’au moins 128 bits. Le client le lie à la clé de son compte, calcule SHA-256 sur cette autorisation de clé, puis publie le résultat base64url sous _acme-challenge.<identifiant>. Le serveur ACME vérifie la valeur obtenue par DNS.

Le succès établit donc la maîtrise de la clé du compte et la capacité de produire cette réponse pour ce nom à cet instant. Il n’identifie ni société, ni personne, ni propriétaire de l’apex. Avec un autre compte ou un autre jeton, le condensat attendu change.

L’objet d’autorisation nomme le compte, l’identifiant, l’état et l’expiration. Il peut expirer, être désactivé ou révoqué. Un journal utile conserve ces noms au lieu d’écrire seulement « domaine validé ».

La délégation est étroite, mais décisive

Une zone réservée au défi réduit l’exposition par rapport à une clé API de l’apex. Elle reste toutefois suffisante pour l’émission lorsque l’AC suit ce chemin. DNSSEC peut authentifier parfaitement la délégation : il confirme ce que la zone signée a choisi, pas la validité actuelle du contrat commercial.

Il faut conserver le nom initial, chaque CNAME et coupure NS, le compte de zone final, l’état DNSSEC, le TTL et la réponse vue depuis les points de validation. Une interface affichant « entrée supprimée » ne prouve ni l’expiration des caches ni la route suivie par l’AC.

Le générique change la portée

Pour *.example, l’autorisation ACME porte sur le domaine de base sans *. et contient wildcard: true. Le nom TXT ressemble donc à une preuve du domaine de base alors que le certificat demandé couvre une famille de noms. Le drapeau générique doit accompagner l’ordre et le CSR.

RFC 9444 permet en outre, comme extension optionnelle et selon la politique du serveur, qu’une autorisation d’ancêtre serve des sous-domaines. On ne doit jamais supposer ce support. On doit enregistrer l’identifiant réellement autorisé et la décision du serveur.

La fermeture du CSR reste bornée

À la finalisation, le CSR doit reprendre exactement l’ensemble d’identifiants de l’ordre. Une SAN supplémentaire ne peut pas être ajoutée après le défi. Cette garantie ne décide pas qui doit garder la clé privée, sur quels terminaux installer le certificat ni quel rôle applicatif lui attribuer.

Séparez ordre, autorisation, CSR, émission, coffre, déploiement et première poignée de main observée. Un certificat émis mais jamais servi n’est pas un échec identique à un certificat installé hors mandat.

CAA peut réduire encore la surface. RFC 8657 définit accounturi et validationmethods pour lier une AC à un compte ou à une méthode reconnus. Ces paramètres sont optionnels, exigent un support cohérent de l’AC et ne remplacent pas la validation du domaine. Le texte avertit aussi qu’une sous-délégation DNS peut dépasser les restrictions héritées.

Nettoyer le DNS ne révoque pas

La suppression du TXT retire une réponse. La suppression de CNAME ou NS retire une route après convergence des caches. La désactivation du compte ou de l’autorisation change encore un autre état. Aucun de ces événements ne révoque à lui seul un certificat déjà délivré.

ACME prévoit une demande de révocation signée. Le compte émetteur, un compte autorisé pour tous les identifiants ou la clé privée du certificat peuvent fournir cette autorité. OCSP publie ensuite un état bon, révoqué ou inconnu. Certificate Transparency rend l’émission observable ; un SCT n’est ni une validation PKIX complète ni une révocation.

Prouver les refus

Retirez le fournisseur de l’application tout en gardant la délégation et tentez une nouvelle commande. Changez la clé du compte tout en publiant l’ancien condensat. Ajoutez une SAN au CSR. Validez simultanément un nom exact et un générique. Supprimez la délégation et interrogez les caches avant et après TTL.

Enfin, émettez sans déployer, puis effacez le défi : le statut du certificat ne doit pas changer par magie. Chaque contrôle doit échouer à la frontière qu’il prétend fermer.