Let’s Encrypt délivre des certificats pour quatre-vingt-dix jours et les renouvelle automatiquement, raison pour laquelle on cesse d’y penser une semaine après la mise en place. L’ennui est que le renouvellement automatique casse en silence : personne ne voit les erreurs, et trois mois plus tard le site accueille ses visiteurs avec un avertissement du navigateur. Depuis 2025, Let’s Encrypt n’envoie plus de courriels d’expiration — le dernier rappel extérieur a donc disparu lui aussi.

Voici les raisons pour lesquelles le renouvellement cesse de fonctionner, par fréquence décroissante.

1. Le certificat a été renouvelé, le service ne l’a jamais relu

La plus fréquente. certbot renew a fonctionné, le nouveau fichier est sur le disque, et nginx ou Apache gardent l’ancien en mémoire — le livrant aux visiteurs jusqu’au rechargement de la configuration. Formellement tout va bien, en réalité le site a un certificat expiré.

Le remède est un crochet exécuté après un renouvellement réussi :

sudo certbot renew --deploy-hook "systemctl reload nginx"

Cela s’écrit une fois dans le fichier de renouvellement (/etc/letsencrypt/renewal/example.com.conf, section [renewalparams], ligne renew_hook) et fonctionne ensuite tout seul.

2. Le serveur web a changé, la validation non

La validation HTTP-01 exige qu’un fichier de /.well-known/acme-challenge/ soit servi en HTTP simple. On la casse d’ordinaire ainsi :

  • une redirection inconditionnelle de HTTP vers HTTPS a été ajoutée — la validation part dans la redirection et échoue ;
  • une règle location ~ /\. avec deny all est apparue, fermant tous les répertoires contenant un point, .well-known compris ;
  • la racine du site a déménagé alors que les réglages de certbot gardent l’ancien --webroot-path ;
  • un blocage par pays ou une authentification basique a été activé et a happé le serveur de validation avec le reste.

Le bon ordre dans la configuration : d’abord un location dédié à /.well-known/acme-challenge/, et seulement ensuite la redirection générale.

3. La minuterie est éteinte

Le renouvellement est lancé par une minuterie systemd ou une tâche cron, et l’une comme l’autre peut être désactivée par mégarde lors d’un débogage ou perdue lors d’un déménagement de serveur.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

La seconde commande exécute un cycle de renouvellement complet en mode test sans consommer votre quota. C’est la seule vérification qui répond d’avance à « est-ce que cela se renouvellera dans un mois » plutôt qu’après coup.

4. Un domaine ne pointe plus ici

Le certificat couvre cinq domaines, l’un d’eux a déménagé chez un autre hébergeur, le DNS a changé. La validation de ce domaine cesse de passer, et certbot ne renouvelle pas le certificat entier — les quatre domaines fonctionnels compris. Les domaines en trop doivent être retirés du certificat, non ignorés avec le message.

5. Vous avez atteint les limites

Let’s Encrypt limite le nombre de certificats par domaine et par semaine. C’est d’ordinaire la conséquence d’une boucle « ça n’a pas marché, je réessaie » pendant le débogage. Pour les expériences il existe un serveur de test (--dry-run ou --test-cert), et il faut s’en servir avant d’avoir épuisé la limite, pas après.

Vérifiez ce qui est livré, pas ce qui est stocké

Toute vérification fondée sur les fichiers a le même défaut : le fichier peut être frais tandis que le visiteur reçoit l’ancien certificat. Regardez du côté du client :

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

L’option -servername est indispensable : sans elle, sur un serveur hébergeant plusieurs sites, vous obtiendrez le certificat du premier hôte virtuel venu et non celui que vous visiez. Dans la sortie, notAfter est la véritable date d’expiration.

Profitez-en pour vérifier la chaîne :

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

S’il n’y a qu’un certificat, l’intermédiaire n’est pas livré. Les navigateurs pardonnent généralement cette configuration — ils reconstruisent la chaîne eux-mêmes —, mais curl, les applications mobiles et les clients Java échoueront à la validation. C’est le classique « chez moi tout s’ouvre et chez le client cela ne marche pas ».

Combien de jours d’avance

Trente jours sont un premier seuil raisonnable : c’est aussi ce qui reste quand certbot commence ses tentatives de renouvellement — si rien ne s’est passé d’ici là, le mécanisme est cassé. Quatorze jours sont le deuxième signal, celui qui exige d’agir aujourd’hui. Sept jours sont une urgence.

L’important est de suivre tous les certificats à la fois, y compris ceux qui ne viennent pas de Let’s Encrypt : ceux achetés pour un an sont les plus sûrement oubliés, parce qu’en un an tout le monde a oublié et eux, et sur quelle boîte aux lettres arrivent les notifications. Une page avec les domaines, les dates et les jours restants clôt entièrement la question — comme dans la démonstration ci-dessous.