Certbot : obtenir et renouveler des certificats Let's Encrypt correctement

Ce qu'est certbot, et ce qu'il fait réellement

Certbot est un client ACME gratuit et open source maintenu par l'Electronic Frontier Foundation. ACME est le protocole qu'utilisent Let's Encrypt (et un nombre croissant d'autres autorités de certification) pour émettre des certificats sans intervention humaine. Certbot le parle à votre place : il crée une clé de compte, demande un certificat à l'autorité, prouve que vous contrôlez le domaine, enregistre le certificat et la clé sur le disque, et, si vous le lui permettez, modifie la configuration de votre serveur web et renouvelle tout avant l'expiration.

La preuve de contrôle est un challenge, et certbot en prend en charge deux. HTTP-01 : l'autorité demande un jeton aléatoire à http://example.com/.well-known/acme-challenge/<token> sur le port 80, et certbot s'assure que ce fichier est servi. DNS-01 : l'autorité recherche un enregistrement TXT à _acme-challenge.example.com, et certbot (ou vous) le publie. HTTP-01 est l'option simple par défaut ; DNS-01 est le seul moyen d'obtenir un wildcard et la façon d'émettre pour un serveur inaccessible depuis Internet.

Qui fait quoi est défini par deux types de plugins. Un authenticator répond au challenge (--nginx, --apache, --webroot, --standalone, --manual, ou un plugin DNS tel que --dns-cloudflare). Un installer place le certificat dans une configuration de serveur (nginx ou apache). certbot --nginx fait les deux ; certbot certonly ... récupère seulement le certificat et vous laisse la configuration.

Tout atterrit sous /etc/letsencrypt. Les fichiers vers lesquels vous pointez un serveur se trouvent dans /etc/letsencrypt/live/<cert-name>/ : fullchain.pem (votre certificat plus l'intermédiaire) et privkey.pem. Ce sont des liens symboliques vers archive/, donc les chemins ne changent jamais d'un renouvellement à l'autre. Pour le contexte sur ce qu'est un certificat et pourquoi il est gratuit, lisez free SSL certificates ; ce guide porte sur l'outil.

Installer certbot : snap d'abord, paquets de la distribution ensuite

Le projet certbot recommande le paquet snap sous Linux. Il suit la version actuelle (5.x en 2026), embarque son propre Python, et installe un timer systemd pour le renouvellement. Supprimez d'abord toute copie fournie par la distribution pour qu'il n'y ait pas deux certbots en conflit sur /etc/letsencrypt : sudo apt remove certbot, sudo dnf remove certbot ou sudo yum remove certbot.

Les paquets de la distribution fonctionnent et sont ce que beaucoup de serveurs possèdent déjà : sudo apt install certbot python3-certbot-nginx (ou python3-certbot-apache) sous Debian et Ubuntu, et les mêmes noms de paquets depuis EPEL sous RHEL, Rocky et Alma. Le compromis, c'est l'ancienneté : une distribution LTS peut livrer un certbot de plusieurs versions majeures en retard, ce qui compte maintenant que Let's Encrypt réduit la durée de vie des certificats (voir la section sur le renouvellement). Certbot est aussi publié sur PyPI et sous forme d'images Docker (certbot/certbot et une image par plugin DNS) si vous préférez ces options.

Après l'installation, certbot --version indique ce que vous avez obtenu, et sudo certbot certificates liste chaque certificat géré avec ses domaines, sa date d'expiration et ses chemins de fichiers.

Installation recommandée sous Linux (snap)

# remove an OS-packaged certbot first, if present
sudo apt remove certbot

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

certbot --version
sudo certbot certificates

Émettre un certificat pour nginx et Apache

Les plugins nginx et Apache sont le chemin le plus court. sudo certbot --nginx -d example.com -d www.example.com trouve le bloc server dont le server_name correspond, répond au HTTP-01 à travers lui, écrit ssl_certificate et ssl_certificate_key dans ce bloc et recharge nginx. Les versions récentes ajoutent la redirection HTTP vers HTTPS par défaut ; --no-redirect la désactive. --apache fait la même chose avec les hôtes virtuels. Les deux ont besoin d'un server_name / ServerName qui correspond au domaine, sinon certbot ne peut pas savoir quel bloc modifier. Nouveau sur le serveur lui-même ? Commencez par what nginx is.

Webroot est le choix quand vous voulez que certbot ne touche pas à votre configuration : il écrit le fichier de challenge dans un répertoire que votre serveur en marche sert déjà. certonly signifie que vous ajoutez vous-même les deux lignes ssl_, une fois ; les renouvellements remplacent ensuite simplement les fichiers derrière les mêmes chemins.

Standalone démarre son propre petit serveur web sur le port 80. C'est pour les machines sans serveur web, ou avec un serveur qui n'est ni nginx ni Apache. Le port 80 doit être libre pendant l'émission et à chaque renouvellement, donc arrêtez l'autre serveur dans un hook : --pre-hook "systemctl stop haproxy" --post-hook "systemctl start haproxy".

Chaque -d ajoute un nom au même certificat, et le premier devient le nom du certificat. Pour ajouter un nom plus tard, relancez la commande avec la liste complète plus --cert-name example.com ; certbot remplace l'ancien certificat au lieu d'en créer un second.

Les quatre façons courantes d'émettre (choisissez-en une)

# nginx: issue and install
sudo certbot --nginx -d example.com -d www.example.com

# Apache: issue and install
sudo certbot --apache -d example.com -d www.example.com

# webroot: issue only; your server keeps serving /.well-known/acme-challenge/
sudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com

# standalone: certbot listens on :80 itself
sudo certbot certonly --standalone -d example.com

# then, in nginx, for the webroot/standalone case:
#   ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
#   ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Certificats wildcard avec DNS-01

Let's Encrypt n'émet *.example.com que via DNS-01. Un wildcard couvre un seul niveau (shop.example.com, pas a.shop.example.com) et ne couvre pas le domaine nu, donc demandez les deux : -d example.com -d '*.example.com'. Mettez l'astérisque entre guillemets pour que le shell ne l'étende pas.

Avec un plugin DNS, certbot crée et supprime les enregistrements TXT via l'API de votre fournisseur DNS, ce qui rend le renouvellement automatique. Il existe des plugins officiels pour Cloudflare, Route 53, Google Cloud DNS, DigitalOcean, Linode, OVH, les serveurs RFC 2136 et d'autres, et des plugins tiers pour bien davantage. Avec le snap, autorisez d'abord les plugins à s'exécuter en root (sudo snap set certbot trust-plugin-with-root=ok), puis installez le snap du plugin. Gardez le fichier d'identifiants en mode 600, et donnez au jeton d'API la portée la plus étroite que propose votre fournisseur (pour Cloudflare, *Zone: DNS: Edit* sur cette seule zone).

Avec --manual, certbot affiche la valeur TXT et attend que vous l'ajoutiez à la main. Demander example.com et *.example.com ensemble réclame deux valeurs TXT sous le même nom _acme-challenge.example.com ; publiez les deux comme des enregistrements distincts. Vérifiez avec dig +short TXT _acme-challenge.example.com avant d'appuyer sur Entrée. Le piège : un certificat manuel ne se renouvelle pas automatiquement sauf si vous fournissez des scripts --manual-auth-hook et --manual-cleanup-hook qui font le travail DNS, donc pour tout ce qui doit durer, utilisez un plugin.

Si votre fournisseur DNS n'a pas d'API, vous pouvez faire pointer _acme-challenge.example.com vers une zone que vous contrôlez avec un enregistrement CNAME ; l'autorité suit le CNAME et lit l'enregistrement TXT là-bas.

Wildcard plus apex via le plugin DNS Cloudflare (snap)

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

# /root/.secrets/cloudflare.ini  (chmod 600)
#   dns_cloudflare_api_token = <token with Zone:DNS:Edit>

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

# by hand (no automatic renewal without hooks)
sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d '*.example.com'

Renouvellement automatique : timers, hooks et --dry-run

Vous n'écrivez pas de tâche cron pour certbot ; le paquet l'a déjà fait. Le snap installe le timer systemd snap.certbot.renew.timer, les paquets Debian et Ubuntu installent certbot.timer, et certains paquets utilisent un fichier dans /etc/cron.d/. La tâche exécute certbot renew deux fois par jour, ce qui renouvelle seulement les certificats qui en ont besoin et se termine silencieusement sinon. Vérifiez-le avec systemctl list-timers | grep certbot.

Quand un certificat doit-il être renouvelé ? Depuis certbot 4.0, quand il reste moins d'un tiers de sa durée de vie (la moitié, pour les certificats de 10 jours ou moins), et certbot suit aussi les indications ACME Renewal Info (ARI) de l'autorité. Cela compte parce que Let's Encrypt réduit les durées de vie : le profil par défaut passe de 90 à 64 jours le 10 février 2027, puis à 45 jours en février 2028. Une configuration qui renouvelle depuis une ligne cron codée en dur « tous les 60 jours » va se casser ; une qui exécute certbot renew quotidiennement ne se cassera pas. Let's Encrypt a aussi arrêté d'envoyer des e-mails de rappel d'expiration en 2025, donc personne ne vous avertira si le renouvellement échoue silencieusement : surveillez vous-même la date d'expiration du certificat.

Rechargez le serveur après le renouvellement. Les installers nginx et Apache rechargent pour vous. Avec webroot, standalone ou un plugin DNS, ajoutez un deploy hook, qui ne s'exécute que lorsqu'un certificat a réellement été renouvelé. Placez-le dans la commande au moment de l'émission (--deploy-hook, enregistré dans /etc/letsencrypt/renewal/<name>.conf) ou déposez un script exécutable dans /etc/letsencrypt/renewal-hooks/deploy/.

Testez toujours avec sudo certbot renew --dry-run. Cela exécute le renouvellement complet contre l'environnement de staging de Let's Encrypt, avec de vrais challenges, sans toucher à vos certificats en production ni utiliser les limites de débit de production.

Vérifier le timer, tester le renouvellement, recharger nginx après chaque renouvellement

systemctl list-timers | grep certbot

sudo certbot renew --dry-run

# reload nginx whenever any certificate is renewed
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

# when does each certificate expire?
sudo certbot certificates

Les limites de débit de Let's Encrypt que vous pouvez vraiment atteindre

Les limites de Let's Encrypt sont généreuses pour un usage normal et douloureuses pendant une session de débogage. Celles qui mordent :

5 certificats par ensemble exact de noms toutes les 7 jours. Émettre example.com + www.example.com cinq fois en une semaine, par exemple en relançant un script de provisionnement ou en effaçant /etc/letsencrypt à chaque démarrage de conteneur, verrouille cet ensemble exact pendant plusieurs jours. L'erreur dit *too many certificates already issued for this exact set of identifiers* et donne une heure de nouvelle tentative. Il n'y a pas de dérogation pour celle-ci. Changer l'ensemble de noms (en ajoutant un nom supplémentaire) obtient une nouvelle limite, mais la vraie solution est de garder /etc/letsencrypt sur un stockage persistant.

5 validations échouées par nom d'hôte, par compte, par heure. Un enregistrement DNS erroné plus une boucle de nouvelles tentatives épuise cela en quelques minutes.

50 certificats par domaine enregistré toutes les 7 jours, comptés sur tous les sous-domaines de example.com, et 300 nouvelles commandes par compte toutes les 3 heures. Les plateformes d'hébergement avec de nombreux sous-domaines les atteignent les premières.

Les renouvellements sont traités avec plus d'indulgence : un renouvellement qui utilise ARI, comme le fait certbot actuel, est exempté de toutes les limites, et un renouvellement simple du même ensemble de noms est exempté des limites par domaine et par commande.

La règle pour les expérimentations : ajoutez --test-cert (alias --staging) ou utilisez --dry-run. Le staging a des limites bien plus élevées et émet des certificats auxquels les navigateurs ne font pas confiance, ce qui est exactement ce que vous voulez pendant que vous faites fonctionner le challenge.

Erreurs certbot courantes et comment les corriger

Timeout pendant la connexion / connexion refusée sur le port 80. HTTP-01 démarre toujours sur le port 80, même si votre site ne diffuse que du HTTPS. Ouvrez le port 80 dans le pare-feu et le groupe de sécurité cloud ; le rediriger vers HTTPS ne pose pas de problème, car l'autorité suit les redirections. Si le port 80 ne peut pas être ouvert, passez à DNS-01.

Réponse invalide / 404 sur /.well-known/acme-challenge/. La requête a atteint un serveur, mais pas le bon, ou pas le bon répertoire. Causes typiques : l'enregistrement A pointe encore vers un ancien hôte, un répartiteur de charge envoie la requête vers un autre nœud, un bloc location ou une réécriture intercepte le chemin, ou -w pointe vers le mauvais webroot. Testez-le vous-même : créez un fichier sous .well-known/acme-challenge/ et récupérez-le avec curl en HTTP simple depuis l'extérieur.

Un enregistrement AAAA pointant ailleurs. Si le nom a une adresse IPv6, Let's Encrypt valide d'abord via IPv6. Un enregistrement AAAA obsolète qui répond depuis un autre serveur fait échouer la validation même si l'IPv4 est correcte. Corrigez ou supprimez l'enregistrement AAAA ; dig AAAA example.com le montre.

Problème DNS : NXDOMAIN / pas d'enregistrement A valide. Le nom ne résout pas encore. Attendez la propagation, et vérifiez l'enregistrement auprès d'un résolveur extérieur, pas seulement sur votre propre machine.

Un enregistrement CAA empêche l'émission. Un enregistrement CAA sur le domaine (ou un parent) liste les autorités autorisées à émettre, et Let's Encrypt n'y figure pas. Ajoutez example.com. CAA 0 issue "letsencrypt.org", et issuewild aussi si vous en définissez un pour les wildcards. Contexte dans what is DNS.

Enregistrement TXT incorrect / aucun enregistrement TXT trouvé. DNS-01 a été vérifié avant que l'enregistrement ne se propage, ou seule l'une des deux valeurs wildcard a été publiée. Augmentez le --dns-<provider>-propagation-seconds du plugin ou attendez plus longtemps en mode manuel.

Impossible de trouver automatiquement un bloc server correspondant. Le plugin nginx a besoin d'un server_name égal au nom demandé. Ajoutez-le, lancez nginx -t, et réessayez.

Trop de certificats déjà émis. La limite de doublons ci-dessus. Utilisez le certificat que vous avez déjà (certbot certificates), et testez désormais avec --staging.

Certbot sous Windows : utiliser un client ACME natif pour Windows

Certbot a abandonné le support de Windows. Le dernier installeur Windows a été livré avec certbot 2.9.0 en février 2024, et le site de certbot renvoie désormais les utilisateurs Windows vers des alternatives listées par la communauté. Les anciens installeurs qu'on trouve encore sur les sites de téléchargement ont des années de retard et ne recevront pas les changements de renouvellement que Let's Encrypt déploie, donc ne vous appuyez pas sur eux.

Ce qu'il faut utiliser à la place dépend du serveur :

IIS ou tout serveur Windows : win-acme a été le choix habituel : un outil en ligne de commande qui lie le certificat dans IIS, l'écrit dans le magasin de certificats Windows ou dans des fichiers PEM/PFX, et crée une tâche planifiée pour le renouvellement. Son mainteneur développe désormais simple-acme, décrit comme un remplacement compatible et direct, donc vérifiez ce projet avant un nouveau déploiement.

Automatisation PowerShell : Posh-ACME est un module PowerShell avec un grand nombre de plugins DNS pour les wildcards.

Vous préférez une interface graphique : Certify The Web est un client graphique pour IIS.

Vous voulez vraiment certbot : exécutez-le dans WSL 2 pour l'émission, puis exportez les fichiers vers Windows. C'est pratique pour les certificats DNS-01 que vous copiez ailleurs, moins pour un site IIS qui a besoin d'une liaison automatique.

Rien de tout cela n'est une recommandation officielle : ce sont tous des projets tiers, donc lisez leur documentation actuelle avant de vous y fier.

Révoquer et supprimer des certificats

Révoquez quand la clé privée a pu fuiter, ou quand vous ne contrôlez plus le domaine. Certbot a besoin soit du nom du certificat, soit du fichier du certificat, et d'une raison : keycompromise, superseded, cessationofoperation, affiliationchanged ou unspecified (par défaut). Après la révocation, certbot propose de supprimer les fichiers locaux ; répondez oui, sinon il continuera d'essayer de renouveler un certificat révoqué. Si la clé a fuité, émettez le remplacement avec une nouvelle clé, ce que fait certbot par défaut.

Supprimez sans révoquer quand vous arrêtez simplement d'utiliser un certificat, par exemple après avoir déplacé un site : certbot delete --cert-name example.com le retire de /etc/letsencrypt et du renouvellement. Retirez d'abord les lignes ssl_ correspondantes de la configuration du serveur, sinon nginx échouera à démarrer au prochain rechargement.

Let's Encrypt a arrêté de faire fonctionner l'OCSP ; les navigateurs apprennent les révocations via les CRL, donc une révocation n'est pas visible partout instantanément. C'est une raison supplémentaire de garder les clés privées lisibles par root uniquement.

Révoquer un certificat compromis, ou supprimer un certificat dont vous n'avez plus besoin

sudo certbot revoke --cert-name example.com --reason keycompromise

sudo certbot delete --cert-name example.com

Derrière un CDN : qui détient le certificat

Une fois qu'un site se trouve derrière un CDN ou un autre proxy inverse, les visiteurs ne voient plus le certificat de votre origine. La périphérie termine le TLS avec son propre certificat, et la connexion de la périphérie vers votre origine est une poignée de main séparée. Vous pouvez garder certbot sur l'origine pour sécuriser ce second tronçon, mais le certificat que vérifie le navigateur est celui de la périphérie.

Sur CDN.com.tr, le certificat de périphérie est géré par Auto SSL : chaque certificat est un certificat Let's Encrypt validé par domaine, sans frais séparés. Pointez un nom d'hôte vers la périphérie avec un CNAME et ce nom obtient son propre certificat, validé via HTTP. Déléguez votre DNS à CDN.com.tr et la racine du domaine obtient un wildcard couvrant la racine et chaque sous-domaine de premier niveau, validé avec un enregistrement DNS. Un certificat est demandé une fois le domaine vérifié et son DNS pointant vers nous, et il est renouvelé automatiquement 30 jours avant son expiration, donc il n'y a aucun timer certbot à surveiller.

Vous déplacez un site en production ? L'assistant sans interruption émet le wildcard via un enregistrement TXT chez votre fournisseur DNS actuel avant le basculement, un peu comme une exécution DNS-01 certbot --manual, et comme cette exécution, il ne se renouvelle pas automatiquement tant que le DNS reste hors de CDN.com.tr. Et si vous détenez un certificat OV ou EV d'une autre autorité, vous pouvez le téléverser et l'attacher à un nom d'hôte ; il obtient la même politique TLS qu'un certificat automatique. Le guide TLS explique ce que négocie la périphérie, et HSTS est l'étape suivante une fois le HTTPS fiable.