ACME (Automatic Certificate Management Environment, RFC 8555) est le protocole par lequel une machine prouve à une autorité de certification qu'elle contrôle un nom de domaine, puis récupère un certificat TLS sans qu'aucun humain n'intervienne. C'est lui qui fait fonctionner Let's Encrypt, et lui que Traefik, Caddy ou lego parlent pour vous. Cette leçon s'adresse à l'administrateur ou au développeur qui publie un service en HTTPS : elle explique les étapes d'une émission, aide à choisir entre les trois défis (HTTP-01, TLS-ALPN-01, DNS-01), situe le passage aux certificats de 45 jours et fait émettre un vrai certificat contre Pebble 2.10.1, l'autorité de test de Let's Encrypt, sans domaine public ni exposition (il faut seulement pouvoir tirer les images de conteneurs).
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Ces objectifs vont de la compréhension du protocole au choix d'un défi, puis à la vérification d'une émission dans un environnement de test.
- Décrire les étapes d'une émission ACME, du compte au certificat signé
- Choisir le défi adapté : HTTP-01, TLS-ALPN-01 ou DNS-01
- Expliquer pourquoi on s'entraîne en staging et ce que les limites de débit protègent
- Situer le passage à des certificats de 45 jours et le rôle d'ARI (ACME Renewal Information, le mécanisme par lequel l'autorité indique quand renouveler)
- Émettre un certificat contre Pebble avec lego et vérifier sa chaîne avec
openssl - Diagnostiquer une émission en échec, y compris à cause d'un enregistrement CAA
Prérequis
Section intitulée « Prérequis »- Savoir ce qu'est un certificat TLS, une autorité de certification et une
chaîne de confiance. Au besoin, la leçon
Diagnostic TLS donne les bases
de lecture avec
openssl s_client, et Générer des certificats avec openssl montre comment on en produit à la main. - Savoir lancer des conteneurs avec Docker Compose (voir Docker Compose) pour la partie pratique.
- Avoir une machine Linux avec Docker, un accès
sudoetopenssl. La VM du lab est une Debian 13 avec Docker CE et Compose ; la pratique tourne dans des conteneurs.
La leçon Publier un service web pose le décor (nom, port, routage derrière un reverse proxy), mais celle-ci n'en dépend pas : il suffit de savoir ce qu'est un certificat.
Que se passe-t-il pendant une émission ACME ?
Section intitulée « Que se passe-t-il pendant une émission ACME ? »Une émission ACME suit toujours la même séquence : le client crée un compte, ouvre une commande (order) pour un ou plusieurs noms, reçoit une autorisation assortie d'un défi (challenge), prouve qu'il contrôle le nom, puis finalise la commande en envoyant une demande de signature. Le client est le logiciel qui parle ACME (lego, Traefik, certbot) ; l'autorité est le serveur ACME (Let's Encrypt en production, Pebble en test).
Le schéma ci-dessous déroule cet échange dans le temps. Regardez qui parle à qui : le client s'adresse à l'autorité pour déclarer et finaliser, mais l'autorité récupère la preuve sur le serveur à valider. Le client ne valide pas lui-même ce serveur.
Chaque étape a un rôle précis :
| Étape | Ce qui se passe | Ce que ça garantit |
|---|---|---|
| Compte | Le client génère une paire de clés de compte et l'enregistre (--accept-tos, e-mail de contact) | Les demandes suivantes sont signées par ce compte |
| Commande | Le client liste les noms souhaités | L'autorité sait quoi vérifier |
| Autorisation et défi | L'autorité propose une épreuve avec un jeton unique | La preuve ne peut pas être rejouée |
| Validation | L'autorité interroge elle-même le serveur | Seul celui qui contrôle le nom passe |
| Finalisation | Le client envoie un CSR (Certificate Signing Request, demande de signature) contenant la clé publique du futur certificat | La clé privée du certificat ne quitte jamais le client |
| Émission | L'autorité signe et le client télécharge le certificat | Chaîne complète prête à servir |
La clé privée du certificat est générée côté client : l'autorité ne la voit jamais, elle signe seulement la clé publique contenue dans le CSR.
Quel défi choisir : HTTP-01, TLS-ALPN-01 ou DNS-01 ?
Section intitulée « Quel défi choisir : HTTP-01, TLS-ALPN-01 ou DNS-01 ? »HTTP-01 est le choix par défaut dès que le port 80 est joignable depuis
Internet ; TLS-ALPN-01 convient quand seul le 443 l'est ; chez Let's Encrypt,
DNS-01 est, à la date du 2026-10-18, le seul défi déployé en production qui
émette un certificat joker et le seul qui serve une machine non exposée. Un
joker (wildcard, *.exemple.org) est un certificat valable pour tous les
sous-domaines d'un niveau. Le défi dit à l'autorité comment vérifier le
contrôle du nom ; le bon choix dépend donc de ce que votre machine expose au
monde.
Un quatrième défi, dns-persist-01, est en cours de normalisation à l'IETF.
Il remplace le TXT renouvelé à chaque émission par un enregistrement
durable, et son option policy=wildcard viserait les jokers. Let's
Encrypt l'a annoncé le
2026-02-18, mais le
fil de suivi
officiel
précise, dans son dernier message (2026-06-25), qu'il n'est pas déployé en
production tant qu'un point du brouillon reste ouvert. Ne planifiez donc rien
dessus sans relire ce fil.
| Défi | Preuve demandée | Port ou ressource | Joker | Machine non exposée |
|---|---|---|---|---|
| HTTP-01 | Servir un jeton à /.well-known/acme-challenge/<jeton> | 80 (en test avec Pebble : 5002) | Non | Non |
| TLS-ALPN-01 (RFC 8737) | Présenter un certificat de validation lors d'une négociation TLS | 443 | Non | Non |
| DNS-01 | Publier un enregistrement TXT _acme-challenge.<nom> | Le DNS, par son API | Oui | Oui |
Quelques règles de décision :
- Le plus simple : HTTP-01. Le port 80 doit rester ouvert, y compris si
tout votre site est en HTTPS. Let's Encrypt suit les redirections vers
les ports 80 ou 443 : une redirection vers HTTPS ne casse le défi que si la
cible ne sert pas le jeton. Le plus sûr reste de servir
/.well-known/acme-challenge/directement, sans redirection. - Le 80 est fermé par un pare-feu ou un fournisseur : TLS-ALPN-01 passe par le 443 (le défi se joue dans la négociation TLS elle-même, grâce à l'extension ALPN qui sert à choisir le protocole), à condition que votre proxy sache répondre à ce défi.
- Un joker ou un serveur interne : DNS-01, car l'autorité ne se connecte pas à la machine, elle lit le DNS. Le revers de la médaille : il faut confier au client un accès à l'API de votre fournisseur DNS, et ce jeton d'API se protège comme un secret.
L'autorité valide depuis plusieurs points du réseau, pas un seul : Let's Encrypt le fait en production depuis février 2020 (validation multi-perspective, billet de lancement), et Pebble le reproduit, vous le verrez dans son journal. Un filtrage géographique ou un blocage par IP côté pare-feu fait donc échouer la validation.
Pour la configuration de ces défis dans Traefik, voir Traefik SSL/TLS et ACME ; pour l'équivalent dans Kubernetes, voir cert-manager.
Pourquoi tester en staging, et que sont les limites de débit ?
Section intitulée « Pourquoi tester en staging, et que sont les limites de débit ? »Let's Encrypt propose un environnement de staging, séparé de la production, pour s'entraîner sans consommer les limites de débit de la production. Ses certificats sortent d'une autorité qu'aucun navigateur ne reconnaît : ils servent à vérifier que le défi passe, pas à servir de vrais visiteurs.
Les deux annuaires ACME sont documentés par Let's Encrypt. L'annuaire de
staging est https://acme-staging-v02.api.letsencrypt.org/directory ;
celui de production est https://acme-v02.api.letsencrypt.org/directory. Pour
passer de l'un à l'autre, vous ne changez que l'adresse de l'annuaire dans
votre client.
Les limites de débit (rate limits) plafonnent le nombre de certificats, de commandes ou d'échecs de validation par période. Elles protègent l'autorité contre les abus, mais elles bloquent aussi un script qui boucle sur une erreur de configuration. Leurs valeurs peuvent évoluer : lisez-les sur la page officielle, Rate Limits de Let's Encrypt, et ne vous fiez pas à un chiffre recopié dans un article. La parade est toujours la même : valider en staging, passer en production une fois le défi réussi, et conserver le certificat plutôt que de le redemander.
Pourquoi les certificats passent-ils à 45 jours, et qu'est-ce qu'ARI ?
Section intitulée « Pourquoi les certificats passent-ils à 45 jours, et qu'est-ce qu'ARI ? »Let's Encrypt raccourcit la durée de vie de ses certificats de 90 à 45 jours, par étapes, ce qui rend l'automatisation du renouvellement obligatoire. Le calendrier est annoncé par Let's Encrypt (ISRG) dans le billet « Decreasing Certificate Lifetimes to 45 Days » du 2 décembre 2025 (reproduit sur isrg.org, sous le titre « from 90 to 45 »). Il est le suivant :
| Date | Changement |
|---|---|
| 2026-05-13 | Le profil tlsserver (facultatif) délivre des certificats de 45 jours |
| 2027-02-10 | Le profil par défaut, classic, passe à 64 jours |
| 2028-02-16 | Le profil classic passe à 45 jours |
Un profil est un jeu de caractéristiques (durée de vie notamment) que le
client choisit à la commande. Let's Encrypt en propose trois à ce jour
(page des profils, relevée le
2026-10-18) : classic (par défaut, 90 jours aujourd'hui), tlsserver
(45 jours) et shortlived (160 heures, soit un peu plus de 6 jours). Pebble
charge deux profils : default (90 jours) et shortlived, soit
518400 secondes ou exactement 6 jours, pratique pour observer un
renouvellement sans attendre.
Pourquoi raccourcir ? Un certificat volé ou mal émis peut être révoqué
(l'annuaire ACME expose revokeCert, et lego a une sous-commande
lego certificates revoke en v5). Mais la révocation ne protège que si les
clients la vérifient, et cette vérification reste inégale selon les
logiciels. Un certificat volé peut donc rester accepté, chez certains clients,
jusqu'à son expiration : moins il vit longtemps, moins l'incident dure.
Les clients disposent de deux moyens de connaître l'état d'un certificat. OCSP (Online Certificate Status Protocol) leur fait interroger un serveur de l'autorité, certificat par certificat. Les CRL (Certificate Revocation Lists) sont des listes de certificats révoqués que l'autorité publie et que le client télécharge. Let's Encrypt avait annoncé l'arrêt de ses répondeurs OCSP pour le 6 août 2025, au profit des CRL, dans son calendrier du 5 décembre 2024.
La conséquence pratique est ce qui compte pour vous : à 45 jours, renouveler manuellement toutes les six semaines n'est plus tenable, et un certificat qu'un humain renouvelle finit par expirer en production. Let's Encrypt n'envoie en outre plus de courriels d'expiration depuis le 4 juin 2025 (annonce du 26 juin 2025) : surveillez vous-même les dates de vos certificats. La leçon Traefik : observabilité montre comment mesurer et alerter.
Le renouvellement lui-même évolue avec ARI (ACME Renewal Information, RFC 9773). Au lieu de renouveler à date fixe, le client demande à l'autorité quand renouveler : si elle doit révoquer en masse ou si une fenêtre précise est préférable, elle l'annonce. Sans ARI, Let's Encrypt recommande, dans le même billet, de renouveler vers les deux tiers de la durée de vie, soit autour du 30e jour d'un certificat de 45 jours. La prise en charge d'ARI dépend du client : vérifiez-la dans la documentation de celui que vous utilisez.
Comment s'entraîner sans domaine public avec Pebble ?
Section intitulée « Comment s'entraîner sans domaine public avec Pebble ? »Pebble est l'autorité ACME de test de Let's Encrypt : elle parle le même protocole que la production, mais tourne chez vous, valide ce que vous lui dites de valider et signe avec une chaîne éphémère. Elle permet de rejouer une émission autant de fois qu'on veut, sans limite de débit, sans domaine public et sans exposer la machine (seul le téléchargement des images de conteneurs demande un accès réseau).
Trois comportements de Pebble sont volontaires et utiles à connaître :
- elle génère une racine et un intermédiaire neufs à chaque démarrage : un certificat émis avant un redémarrage ne se vérifie plus après ;
- elle refuse 5 % des nonces (le nombre à usage unique qui protège
chaque requête) pour obliger les clients à gérer l'erreur
badNonce; un échec ponctuel est donc normal, on relance ; - sans la variable
PEBBLE_VA_NOSLEEP=1, Pebble ajoute un délai aléatoire (de 0 à 15 secondes d'après son README) avant chaque validation : l'autorité simule la latence d'une vraie validation. Ce délai explique que l'émission prenne plus ou moins longtemps d'un essai à l'autre.
Pebble reproduit le protocole ACME dans un environnement local, sans délivrer de certificats reconnus par les navigateurs ni consommer les quotas de production. Il s'appuie sur un service de test pour résoudre les noms du scénario. Le laboratoire fournit les détails d'accès et le matériel nécessaire : ils dépendent de son environnement isolé et ne sont pas des paramètres de production.
Comme Pebble crée une nouvelle chaîne de confiance à chaque démarrage, un certificat obtenu lors d'une session précédente ne se valide pas contre la racine de la session suivante. Ce comportement permet de vérifier que l'on contrôle bien l'autorité qui a signé le certificat.
Mettre en pratique : émettre un certificat contre Pebble
Section intitulée « Mettre en pratique : émettre un certificat contre Pebble »Le laboratoire vous fait réaliser une émission ACME de bout en bout : lancer l'autorité de test, obtenir un certificat avec un client ACME, retrouver la preuve du défi dans les journaux et vérifier le certificat avec OpenSSL. Il évalue le certificat et la trace d'émission, pas la présence d'une commande particulière dans votre configuration.
Pendant l'exercice, distinguez les preuves : le journal de l'autorité montre qu'elle a validé le défi et émis un certificat ; l'inspection du certificat permet de confirmer son nom et son émetteur ; la vérification de chaîne confirme qu'il remonte à l'autorité de test active. N'utilisez jamais une racine de démonstration comme ancre de confiance pour un service de production.
Que faire quand l'émission échoue ?
Section intitulée « Que faire quand l'émission échoue ? »Une émission ACME qui échoue laisse presque toujours une trace côté autorité : lisez le journal de Pebble (ou l'erreur renvoyée par Let's Encrypt) avant de modifier quoi que ce soit. Le tableau regroupe des symptômes courants. Certains peuvent apparaître dans ce lab ; d'autres orientent le diagnostic en production.
| Symptôme | Cause probable | Solution |
|---|---|---|
badNonce | Pebble refuse 5 % des nonces à dessein | Relancer la commande ; un client robuste réessaie seul |
| Erreur de connexion lors de la validation du défi | L'autorité ne peut pas atteindre le service chargé de présenter la preuve | Vérifier l'adresse d'écoute, la publication du port, la connectivité du réseau et le pare-feu depuis le point de vue de l'autorité |
| L'autorité tente une adresse de défi qui ne répond pas | Le service de défi et l'autorité n'utilisent pas la même famille d'adresses, ou le service n'écoute pas sur l'adresse attendue | Comparer l'adresse visée et les adresses d'écoute, puis vérifier qu'elles sont joignables depuis le réseau de validation |
| Option HTTP inconnue | L'option ne correspond pas à la version du client ou à la sous-commande utilisée | Vérifier la version installée et la syntaxe de la sous-commande dans l'aide du client |
openssl verify échoue (error 20 ... unable to get local issuer certificate) après un redémarrage de Pebble | Racine et intermédiaire neufs à chaque démarrage : l'ancien certificat reste signé par l'ancienne chaîne | Émettre un nouveau certificat avec la session Pebble active, puis vérifier sa chaîne avec les certificats de confiance de cette session |
Permission denied lors de la lecture du stockage de certificats | Les fichiers appartiennent à un autre compte ou leurs droits sont trop restrictifs | Vérifier le propriétaire et les permissions, puis accéder aux fichiers avec le compte prévu |
mount ... not a directory au lancement du client ACME | Le montage de données entre en conflit avec un fichier ou un chemin déjà utilisé | Choisir un répertoire de données distinct de l'exécutable et vérifier les types des chemins source et destination |
certificate signed by unknown authority lors de la connexion à l'annuaire de test | Le client ne fait pas confiance à l'autorité qui sert l'annuaire | Vérifier le certificat de l'autorité de test, son montage et le réglage de confiance attendu par le client |
Pool overlaps with other one on this address space au démarrage de Compose | Un autre réseau Docker ou une interface de l'hôte utilise déjà le sous-réseau demandé | Repérer le conflit dans les réseaux et interfaces existants, choisir un sous-réseau libre et mettre à jour ensemble les paramètres réseau qui en dépendent |
En production, quatre causes sont à vérifier en premier : un port 80 ou 443
fermé, une redirection qui capture le chemin
/.well-known/acme-challenge/ vers une cible qui ne sert pas le jeton, un
enregistrement DNS qui pointe vers une autre machine que celle qui répond
au défi, et un enregistrement CAA.
Un enregistrement CAA (Certification Authority Authorization, RFC 8659) est
une ligne DNS qui liste les autorités autorisées à émettre pour un
domaine. Il est facultatif : sans aucun enregistrement CAA, toute autorité
peut émettre. Un CAA posé sur le domaine parent vaut aussi pour ses
sous-domaines qui n'en ont pas. Let's Encrypt le consulte avant chaque
émission et refuse si un CAA existe sans le nommer. L'erreur affichée
mentionne CAA y compris quand un résolveur DNS répond
mal (SERVFAIL, c'est-à-dire un échec côté serveur DNS, ou délai dépassé), même
sans enregistrement CAA publié
(documentation CAA). Ce cas n'a pas été
rejoué dans ce lab.
Le CAA sert aussi de mesure de durcissement : publier
exemple.org CAA 0 issue "letsencrypt.org" interdit à toute autre autorité
d'émettre pour le domaine. Deux paramètres (RFC 8657) restreignent en plus
l'émission : accounturi impose votre compte ACME (identifié par l'URL
du compte que l'autorité lui a attribuée, pas par l'e-mail) et
validationmethods limite les défis acceptés.
À retenir
Section intitulée « À retenir »- ACME automatise le contrôle d'un nom et l'émission : compte, commande, autorisation, défi, finalisation.
- C'est l'autorité qui vérifie la preuve, depuis plusieurs points du réseau ; la clé privée du certificat ne quitte jamais le client.
- HTTP-01 (port 80) est le défaut, TLS-ALPN-01 (port 443) s'utilise quand le 80 est fermé, DNS-01 est, chez Let's Encrypt aujourd'hui, seul à émettre des jokers et à servir des machines non exposées.
- On s'entraîne en staging et on lit les limites de débit sur la page officielle de Let's Encrypt.
- Les certificats Let's Encrypt passent à 45 jours : le renouvellement s'automatise, et ARI (RFC 9773) laisse l'autorité indiquer la bonne date.
- La révocation (OCSP, CRL) protège de façon inégale et Let's Encrypt n'envoie plus de courriel d'expiration : surveillez vous-même les dates.
- Un enregistrement CAA peut bloquer l'émission, ou la durcir en la réservant à une autorité, un compte et un défi.
- Pebble émet des certificats de test avec une chaîne neuve à chaque
démarrage ;
openssl verifyvérifie contre la racine et l'intermédiaire courants.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Faire fonctionner une application derrière un point d'entrée
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications