Sécuriser ACME wildcard et external account binding

ACME (Automated Certificate Management Environment) automatise l’émission et le renouvellement des certificats TLS (Transport Layer Security), mais ses extensions déplacent le risque vers le DNS (Domain Name System), les clés de compte et les politiques d’inscription. Le wildcard réduit la surface d’administration des certificats, pas la surface de confiance. L’EAB (External Account Binding) encadre l’accès à une autorité de certification, mais ne transforme pas une clé compromise en bon citoyen.

→ Lire l’explication complète de la marmotte

Wildcard ACME et délégation DNS-01

Un certificat wildcard, par exemple *.example.net, couvre les noms immédiatement sous ce domaine, tels que api.example.net et grafana.example.net. Il ne couvre ni example.net lui-même, ni a.b.example.net. Cette limite est régulièrement oubliée lors de la conception des règles de routage, puis redécouverte pendant une migration à une heure où personne ne voulait découvrir quoi que ce soit.

ACME impose le défi DNS-01 pour un wildcard. Le demandeur publie une valeur calculée sous _acme-challenge.example.net, puis l’autorité de certification vérifie sa présence dans le DNS public. Cette valeur TXT est dérivée du jeton de défi et de la clé de compte ACME : le contrôle du DNS devient donc la preuve de contrôle du domaine. HTTP-01, le défi fondé sur une ressource exposée par HTTP (Hypertext Transfer Protocol), ne peut pas prouver le contrôle d’un wildcard, même si un proxy expose parfaitement le port 80. C’est un choix cohérent : prouver la maîtrise de tous les hôtes futurs avec le contrôle d’un seul serveur web serait une idée de présentation commerciale, pas un modèle de sécurité.

Le compromis central est net : un wildcard diminue le nombre de certificats et de renouvellements, mais concentre le pouvoir de compromettre plusieurs services dans une même clé privée. Une clé associée à *.example.net permet d’usurper n’importe quel service couvert, alors qu’un certificat dédié à api.example.net limite le rayon d’impact à cette seule identité. La recommandation est donc de réserver les wildcards aux domaines dont les services partagent réellement une même frontière de confiance et un même cycle de vie. Un wildcard pour tout un domaine d’entreprise est un raccourci coûteux : la compromission d’un seul pod, d’un dépôt ou d’un compte de déploiement peut alors permettre l’usurpation de n’importe quel sous-domaine couvert.

Mélanger sous un même wildcard un portail RH, une API (Application Programming Interface) partenaire, des outils internes et un environnement de test fusionne des périmètres de confiance que la réduction du nombre de fichiers PEM (Privacy Enhanced Mail) ne compense pas. Séparer au minimum les zones publiques, les zones internes et les environnements, puis préférer des certificats par service pour les composants à privilèges élevés, les passerelles d’administration et les points d’accès mTLS (mutual TLS). Les mécanismes de TLS mutuel ne transforment pas une clé serveur surpuissante en décision raisonnable.

La délégation du préfixe _acme-challenge via un enregistrement CNAME (Canonical Name) ou NS (Name Server) vers une zone dédiée est préférable à l’accès d’écriture sur la zone principale. La zone déléguée doit accepter uniquement les mises à jour nécessaires aux enregistrements TXT (Text). Un jeton d’API DNS capable de supprimer la zone, modifier les enregistrements MX (Mail Exchange) ou rediriger www n’est pas un secret ACME : c’est une procuration générale sur l’identité du domaine. Chaque délégation doit garder une chaîne de propriété lisible : domaine source, zone cible, identité d’automatisation, autorité de certification acceptée et journalisation des mutations DNS. Une zone déléguée non inventoriée devient vite un mécanisme d’émission parallèle.

La délégation ne protège toutefois pas contre une compromission du fournisseur DNS, de son compte administrateur ou d’un résolveur interne mal configuré. L’autorité de certification interroge le DNS public et suit la délégation publiée, pas la vue DNS interne. Une zone split-horizon mal pensée peut donc valider en recette et échouer pour l’autorité, ou pire, faire croire qu’une délégation est confinée alors qu’elle est publiquement exploitable.

Pour les principes de nommage, de délégation et de séparation des zones, voir DNS et TLS. Le certificat n’est qu’une partie de la chaîne, comme détaillé dans les fondations PKI (Public Key Infrastructure).

External Account Binding et contrôle des comptes ACME

EAB signifie External Account Binding. Il lie la création d’un compte ACME à un identifiant et à une clé secrète fournis hors du protocole, généralement par l’autorité de certification ou par une plateforme d’inscription interne. Le client génère sa propre paire de clés de compte, puis signe une preuve d’association avec une clé HMAC (Hash-based Message Authentication Code) remise par l’émetteur. L’autorité vérifie cette preuve avant d’accepter le compte.

EAB répond à un problème précis : empêcher la création anonyme ou non autorisée de comptes auprès d’une autorité ACME privée ou d’une offre qui applique des règles d’inscription. Il est pertinent lorsque l’autorité doit rattacher chaque compte à un tenant, appliquer des quotas ou exiger une approbation externe. Il fournit une preuve que le demandeur détenait un secret d’enrôlement. Il ne prouve ni l’identité humaine, ni l’autorisation d’émettre pour un domaine donné, ni la conformité du futur certificat aux règles d’architecture. Ces contrôles doivent rester côté autorité, politique de domaine et défi de validation : EAB est une barrière d’enrôlement, DNS-01 reste la preuve de contrôle du domaine, et la politique de l’autorité décide ce qu’un compte peut demander.

La clé EAB est souvent traitée comme un mot de passe d’installation. C’est faux. Elle autorise l’ouverture d’un compte dont les capacités dépendront des politiques de l’autorité. Sa fuite ne donne pas accès aux comptes déjà existants, qui reposent sur leurs propres clés de compte, mais elle permet de créer des comptes non autorisés tant que l’autorité accepte la liaison, donc de contourner la gouvernance d’émission et de consommer des quotas. Si cette autorité laisse un compte demander des certificats pour des identifiants sensibles, la fuite de la clé EAB devient une porte d’entrée d’émission. Une clé EAB à durée illimitée, partagée entre environnements, est une dette de sécurité avec une date d’explosion volontairement inconnue.

La recommandation est de délivrer une paire (kid, clé HMAC) unique par consommateur, c’est-à-dire par équipe ou par automate, ce qui permet une révocation ciblée et une piste d’audit exploitable. Partager un même couple entre tous les clients revient à un compte racine déguisé en paramètre YAML. Le kid (Key Identifier) identifie l’enrôlement, sans être lui-même secret. La clé HMAC doit être injectée depuis un gestionnaire de secrets, jamais depuis un dépôt Git, une image de conteneur ou une variable figée dans un manifeste durable, limitée à l’inscription initiale lorsque le produit le permet, puis révoquée ou expirée. Selon l’autorité, une liaison est à usage unique, réutilisable ou soumise à expiration : cette sémantique doit être vérifiée avant l’intégration, car elle conditionne la procédure de remplacement. Une rotation doit créer une nouvelle paire, vérifier l’enregistrement du nouveau compte et seulement ensuite invalider l’ancienne. Remplacer la valeur en place sans connaître les comptes qui l’utilisent transforme la rotation en test de continuité déguisé. Un secret EAB renouvelé mais absent du coffre de secours est une panne différée, et les pannes différées ont un goût prononcé pour les congés.

L’EAB ne remplace pas une authentification forte à l’interface d’administration de l’autorité, ni une séparation des rôles entre création d’enrôlement et définition des profils de certificats. Il ne remplace pas non plus la vérification des journaux d’émission. Une politique qui autorise *.example.net à chaque compte authentifié par EAB ne devient pas prudente parce que le nom comporte trois lettres de plus.

Exemple DNS-01 avec zone de challenge déléguée

Cet exemple utilise Certbot avec un fournisseur DNS compatible RFC (Request for Comments) 2136, le mécanisme de mises à jour dynamiques DNS. Il suppose que _acme-challenge.example.net est délégué vers acme-dns.example.net et que le serveur de mise à jour n’accepte que les TXT sous cette zone. Sur Debian, le module correspondant s’installe avec apt-get install certbot python3-certbot-dns-rfc2136.

# Le fichier contient une clé TSIG (Transaction SIGnature) dédiée aux TXT ACME.
# Droits 0600 : le jeton permet de publier des preuves de contrôle de domaine.
install -m 0600 /dev/null /etc/letsencrypt/rfc2136.ini

cat >/etc/letsencrypt/rfc2136.ini <<'EOF'
dns_rfc2136_server = 192.0.2.53
dns_rfc2136_port = 53
dns_rfc2136_name = acme-updater.
dns_rfc2136_secret = BASE64_SECRET_A_REMPLACER
dns_rfc2136_algorithm = HMAC-SHA256
EOF

# Demande explicite du nom nu et du wildcard : le wildcard ne couvre pas le nom nu.
certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini \
  -d example.net \
  -d '*.example.net'

Face à une autorité privée qui exige EAB, la même commande reçoit l’adresse du répertoire ACME et la paire EAB, lue dans le coffre de secrets au moment de l’exécution plutôt que stockée sur la machine :

# Valeurs EAB propres à cet automate, lues à l'exécution, jamais écrites sur disque.
ACME_EAB_KID="$(vault kv get -field=kid secret/acme/eab/equipe-api)"
ACME_EAB_HMAC_KEY="$(vault kv get -field=hmac_key secret/acme/eab/equipe-api)"

certbot certonly \
  --server https://ca.example.net/acme/directory \
  --eab-kid "$ACME_EAB_KID" \
  --eab-hmac-key "$ACME_EAB_HMAC_KEY" \
  --dns-rfc2136 \
  --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini \
  --dns-rfc2136-propagation-seconds 60 \
  -d example.net \
  -d '*.example.net'

La clé TSIG (Transaction SIGnature) ne doit pas permettre une mise à jour sur example.net entier. La règle du serveur DNS doit limiter le propriétaire à _acme-challenge.example.net. et le type à TXT. Elle doit aussi rester distincte de toute clé d’administration de zone. Le client ne doit pas conserver le fichier de secrets dans une image de conteneur, un manifeste Git ou un répertoire monté par tous les workloads. Les trois pratiques existent encore, ce qui prouve seulement que Git sait très bien mémoriser les regrets.

Avant automatisation, vérifier depuis un résolveur externe que la délégation et les réponses TXT sont visibles. Les caches DNS peuvent prolonger une ancienne valeur selon le TTL (Time To Live). Un TTL court réduit le délai de propagation mais augmente la dépendance à la disponibilité du DNS autoritatif. Il ne corrige ni une délégation erronée ni une politique de mise à jour trop large. Il ne garantit pas non plus la convergence : le délai d’attente avant validation (--dns-rfc2136-propagation-seconds) doit couvrir la convergence réellement observée entre le serveur faisant autorité, ses éventuels secondaires et les résolveurs externes, mesurée depuis plusieurs points avant de raccourcir quoi que ce soit.

L’automate doit enfin exécuter régulièrement certbot renew --dry-run, sans confondre ce test de renouvellement avec une preuve de reprise complète.

Surface d’attaque des comptes, défis et clés privées

Le vol de la clé de compte ACME permet de créer de nouvelles commandes au nom du compte, selon les politiques de l’autorité. Il ne donne pas automatiquement accès aux clés privées des certificats déjà émis, sauf si le client les stocke au même endroit, ce qui est une manière remarquablement efficace de transformer deux incidents en un seul. Séparer clé de compte, secret DNS, secret EAB et clé privée du certificat limite les compromissions corrélées.

Le vol du secret DNS permet de satisfaire DNS-01 et d’obtenir un certificat pour le domaine autorisé par ce secret. C’est l’attaque principale contre DNS-01, et la contre-mesure n’est pas un audit annuel du fournisseur DNS avec une jolie matrice colorée : il faut un jeton à portée minimale, limité à la zone de défi dédiée, à durée de vie courte lorsque le fournisseur le permet. Il faut donc journaliser chaque modification TXT, alerter sur les créations hors fenêtres attendues et conserver les traces d’identité du jeton ou de la clé utilisée. Les journaux de l’autorité doivent être rapprochés des événements DNS : une émission sans événement de renouvellement attendu mérite une investigation, pas un emoji vert dans un tableau de bord.

Les attaques par délégation CNAME sont fréquentes lorsque des sous-domaines historiques pointent vers des zones abandonnées ou des services tiers non maîtrisés. Un inventaire périodique des CNAME sous _acme-challenge est nécessaire. Toute cible externe doit avoir un propriétaire désigné, une date de revue et une procédure de retrait. Une délégation ACME orpheline est une capacité d’émission orpheline.

Le détournement en amont, par changement non autorisé de délégation ou compromission du bureau d’enregistrement (registrar), échappe entièrement au client ACME. DNSSEC (Domain Name System Security Extensions) protège l’intégrité des réponses signées, mais pas contre un administrateur légitime ou compromis qui modifie la zone. La protection passe par des comptes séparés, une authentification forte, des validations hors bande pour les changements chez le registrar et des alertes sur les enregistrements NS, DS (Delegation Signer) et sur les CNAME de défi.

Stocker la clé privée du certificat dans un module matériel de sécurité ou un mécanisme non exportable réduit le risque de copie dans un dépôt, un volume partagé ou un vidage mémoire du proxy, mais n’empêche pas un processus déjà autorisé à signer d’être abusé. Un tel module ne sécurise pas le nom de domaine : il empêche surtout la clé de partir en vacances.

La révocation d’un certificat ne ferme pas les sessions TLS déjà établies et ne retire pas les copies de la clé privée. Certains clients ignorent aussi les mécanismes de statut ou conservent des chaînes en cache. La réponse immédiate à une fuite est donc triple : révoquer le certificat, remplacer la clé privée sur tous les terminaux TLS et retirer la capacité ayant permis l’émission, par exemple le jeton DNS ou la clé EAB. Elle se complète par l’investigation des accès DNS et la vérification des certificats émis pendant la période d’exposition. Réémettre avec la même clé privée revient à repeindre une fuite d’eau.

Exploitation, rotation et reprise ACME

Les certificats ont une durée finie, souvent 90 jours chez les autorités publiques. Le renouvellement doit démarrer suffisamment tôt pour absorber une indisponibilité DNS, une limite de débit de l’autorité ou un échec de déploiement. Un seuil de 30 jours avant expiration est raisonnable pour déclencher l’alerte, mais l’automate peut renouveler bien avant. Avec des certificats plus courts ou une fenêtre de changement contrainte, une alerte unique ne suffit pas : ajouter des seuils successifs, par exemple à vingt puis sept jours, et une alerte sur tout échec répété de renouvellement. Attendre les dernières quarante-huit heures n’est pas une stratégie, c’est un pari sur la météo des dépendances.

Superviser quatre états distincts : expiration du certificat déployé, succès du dernier renouvellement, capacité de publication DNS et cohérence entre le certificat obtenu et celui servi. Y ajouter deux événements : les échecs de défi DNS et toute modification de compte ACME. Un renouvellement réussi dans un volume local ne vaut rien si le proxy n’a pas rechargé le nouveau fichier. Pour la couche de terminaison et la vérification côté service, consulter TLS expliqué.

La sauvegarde doit couvrir la configuration d’automatisation, les identifiants de compte et les références vers les secrets, mais pas multiplier sans contrôle les clés privées exportées. La clé de compte ACME mérite une sauvegarde chiffrée avec un contrôle d’accès distinct de celui des clés privées de certificats : elle gère les commandes et, selon l’autorité, permet de demander une révocation. Sa perte ne compromet pas le certificat existant, mais peut bloquer certaines opérations de gestion. Sauvegarder uniquement les certificats et leurs clés crée une reprise incomplète ; sauvegarder indistinctement toutes les clés dans un coffre partagé transforme la reprise en distribution non maîtrisée. Si une clé est sauvegardée, elle doit être chiffrée, soumise à contrôle d’accès et testée en restauration. Une reprise documentée doit pouvoir recréer un compte, réinstaller les autorisations DNS, retrouver le secret EAB, demander un certificat et le déployer sans dépendre d’une machine disparue. L’état ACME local est précieux, mais il ne doit pas être l’unique détenteur de la capacité de reprise.

Les clés privées de certificats à forte valeur doivent être générées et conservées dans un HSM (Hardware Security Module) ou un mécanisme équivalent lorsque la pile TLS le supporte. ACME ne garantit pas cette protection : il transporte une demande de signature de certificat et orchestre sa validation. La génération, la non-exportabilité et la rotation de la clé relèvent de l’architecture de gestion des clés, pas d’un miracle protocolaire.

Après une compromission, la rotation d’un wildcard génère toujours une nouvelle paire de clés. Pour le renouvellement courant, la réutilisation de la clé ne se tolère que si elle est non exportable, si le périmètre reste inchangé et si la politique de l’autorité l’autorise ; dans tous les autres cas, une nouvelle clé par émission limite l’exposition dans le temps. Le coût cryptographique est négligeable, et l’argument de performance relève généralement de la paléontologie informatique.

En résumé, EAB ne remplace pas une autorisation de domaine, DNS-01 ne remplace pas une gestion de secrets et le wildcard ne remplace pas la segmentation. ACME automatise une émission ; le reste vient de l’architecture, de l’IAM (Identity and Access Management), des contrôles DNS et de l’exploitation.

🐝 Ce qui arrive si on s’en passe

Sans traiter les clés de compte ACME, les secrets EAB et les accès DNS comme des actifs critiques, l’automatisation des certificats déplace le risque au lieu de le réduire. Une clé de compte volée permet de piloter l’émission et le renouvellement au nom de l’organisation, et un secret d’External Account Binding compromis ouvre l’accès à l’autorité de certification que ce mécanisme devait justement encadrer. Le wildcard aggrave l’impact : un seul certificat de secours obtenu abusivement couvre toute une famille de noms, offrant un passe pour l’étage entier plutôt qu’une porte. Un accès DNS détourné, sur lequel repose la validation DNS-01, laisse prouver le contrôle de domaines qu’on ne possède pas. La conséquence est l’émission de certificats valides pour des services qui n’ont jamais été visés, et l’interception silencieuse de leurs connexions, faute d’avoir gardé le registre et les clés qui décident qui peut demander quoi.

🦫 Explication de la marmotte 🍫

Un système demande un certificat pour prouver l’identité d’un site sécurisé. Il crée d’abord une clé privée, qui doit rester secrète, et une clé publique. Il ouvre ensuite un compte auprès de l’organisme qui délivre les certificats. Avec la liaison de compte externe, cet organisme fournit un identifiant et un secret avant l’inscription. Le système utilise ce secret pour prouver qu’il a reçu une autorisation de créer ce compte.

Pour obtenir un certificat couvrant tous les sous-domaines directs, le système doit prouver le contrôle du nom de domaine. Il publie une valeur temporaire dans le service qui gère les noms sur Internet. L’organisme vérifie cette valeur depuis Internet. Si elle est absente, incorrecte ou invisible à cause d’une mauvaise délégation, la demande échoue. Si le secret permettant de publier cette valeur est volé, un attaquant peut aussi réussir cette preuve et demander un certificat.

Après émission, le certificat et sa clé privée sont installés sur le serveur qui protège les connexions. Le renouvellement doit se produire avant expiration et être surveillé. Si une clé privée ou un secret de publication fuit, il faut retirer le certificat concerné, créer une nouvelle clé, couper l’accès volé et vérifier quels certificats ont été obtenus. La liaison externe limite qui peut créer un compte, mais ne remplace pas ces contrôles.

Pages voisines

La citent

Sécuriser ACME wildcard et external account binding

Elle cite

Sécuriser ACME wildcard et external account binding

Sécuriser ACME wildcard et external account binding

Wildcard ACME et délégation DNS-01

External Account Binding et contrôle des comptes ACME

Exemple DNS-01 avec zone de challenge déléguée

Surface d’attaque des comptes, défis et clés privées

Exploitation, rotation et reprise ACME

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines