Pourquoi les renouvellements Let's Encrypt échouent

Les cinq causes les plus fréquentes et comment les détecter au plus tôt.

Les certificats Let's Encrypt ont une durée de vie de 90 jours et les clients habituels (Certbot, acme.sh, Caddy, Traefik, cert-manager) les renouvellent automatiquement environ 30 jours avant leur expiration. Lorsque le renouvellement défaille, rien ne vous prévient jusqu'à ce que les navigateurs affichent une erreur plein écran : Let's Encrypt a cessé d'envoyer des e-mails de rappel d'expiration en 2025, et la durée de validité des certificats ne cesse de se raccourcir, entraînant des renouvellements plus fréquents et davantage d'occasions d'échec.

Une règle empirique utile s'en dégage : un certificat ACME disposant de moins de 30 jours de validité correspond déjà à un renouvellement ayant échoué au moins une fois. Voici les causes les plus fréquemment observées, accompagnées de la commande permettant de confirmer chacune d'elles.

1. Le fichier de validation est inaccessible

La validation HTTP exige que le domaine serve un jeton sous /.well-known/acme-challenge/ sur le port 80. Une redirection vers un autre hôte, un pare-feu bloquant le port 80, une règle de CDN ou de WAF (pare-feu applicatif), un géoblocage, une authentification HTTP de base ou une page de maintenance placée devant le site provoquent l'échec de tout renouvellement.

curl -i http://harborgoods.com/.well-known/acme-challenge/test

L'obtention d'un code 404 de la part de votre propre serveur Web constitue la réponse attendue. Une redirection vers un autre domaine, un code 403, un dépassement de délai (timeout) ou une page de connexion signifient que l'autorité de certification reçoit exactement la même chose. Rediriger vers HTTPS sur le même hôte ne pose en revanche aucun problème.

2. Le DNS a bougé, mais pas le certificat

Suite à une migration, le domaine pointe vers un nouveau serveur, un CDN ou un répartiteur de charge (load balancer) tandis que la tâche de renouvellement continue de s'exécuter sur l'ancienne machine. L'ancien serveur ne peut plus prouver qu'il contrôle le domaine, et le nouveau sert éventuellement un certificat que personne ne renouvelle.

dig +short A harborgoods.com
dig +short AAAA harborgoods.com

Un enregistrement AAAA pointant vers une adresse ne répondant plus constitue un piège récurrent : Let's Encrypt privilégie l'IPv6 lorsque les deux versions coexistent. En cas de recours à la validation DNS, vérifiez que le jeton d'API utilisé par le client pour créer l'enregistrement TXT n'a pas expiré ou perdu ses permissions.

3. Un enregistrement CAA interdit l'émetteur

Un enregistrement CAA liste les autorités de certification autorisées à émettre pour le domaine. Si vous changez de fournisseur ou laissez un CDN émettre des certificats en votre nom sans le mettre à jour, l'émission est refusée.

dig +short CAA harborgoods.com

L'absence de réponse signifie que toutes les autorités sont autorisées. Si des enregistrements existent, l'un d'eux doit obligatoirement contenir letsencrypt.org pour que Let's Encrypt puisse émettre. Les enregistrements CAA sont hérités des domaines parents, pensez donc à vérifier l'apex lorsqu'un sous-domaine échoue.

4. Le renouvellement a eu lieu, mais rien n'a été rechargé

Le certificat a bien été renouvelé sur le disque, mais le serveur Web a conservé l'ancien en mémoire car personne ne l'a rechargé. La même situation se produit lorsque le certificat est copié sur un répartiteur de charge, un CDN ou un serveur de messagerie par un script qui s'est arrêté de fonctionner.

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

Comparez la date notAfter avec celle du fichier présent sur le disque. Certbot propose des hooks de déploiement à cet effet : --deploy-hook "systemctl reload nginx" recharge le serveur à l'issue de chaque renouvellement réussi.

5. La tâche de renouvellement s'est arrêtée

La tâche cron ou le timer systemd a été supprimé lors d'une mise à jour, le serveur a été reconstruit à partir d'une image en étant dépourvu, ou le conteneur l'exécutant n'existe plus.

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

L'exécution à blanc (dry-run) simule l'intégralité du processus de validation auprès de l'environnement de staging sans modifier vos certificats : si elle échoue, le prochain vrai renouvellement échouera de la même manière, avec le même message d'erreur.

Et les limites de débit (rate limits)

Des tentatives infructueuses répétées, un script sollicitant un nouveau certificat à chaque déploiement, ou un grand nombre de sous-domaines émis un par un s'heurtent aux limites de débit de Let's Encrypt : les validations en échec sont limitées par nom d'hôte et par heure, et les nouveaux certificats par domaine enregistré et par semaine. Une fois la limite atteinte, il faut patienter. Corrigez d'abord la cause à l'aide de l'option --dry-run, et regroupez les sous-domaines apparentés au sein d'un même certificat.

Des durées de vie raccourcies à venir

Les navigateurs et autorités de certification se sont mis d'accord pour raccourcir par étapes la durée de vie maximale des certificats publics : 200 jours à compter de mars 2026, 100 jours à partir de mars 2027 et 47 jours dès mars 2029. Let's Encrypt, déjà positionné à 90 jours, a également annoncé des certificats plus courts. Les renouvellements manuels ne survivront pas à un tel calendrier, et chaque renouvellement automatisé s'exécutera nettement plus souvent qu'aujourd'hui.

En pratique, cela signifie que chaque faiblesse recensée ci-dessus se manifestera plus tôt. Un parcours de validation qui défaille une fois par an aujourd'hui pourrait rompre chaque mois demain. Traitez le renouvellement de certificat comme une sauvegarde : automatisez-le, testez-le via une exécution à blanc après chaque modification d'infrastructure, et surveillez le résultat de l'extérieur plutôt que de faire aveuglément confiance aux journaux de la tâche elle-même.

Détecter le problème avant les visiteurs

1. 1Conservez des alertes de certificat à J-14 et J-7 : avec une fenêtre de renouvellement de 30 jours, une alerte à J-14 signifie que le renouvellement a échoué pendant deux semaines.
2. 2Soyez attentif aux certificats dont l'émetteur change de manière inattendue : cela révèle souvent un CDN ou un hébergeur ayant pris le relais.
3. 3Une fois la correction apportée, lancez le renouvellement manuellement et vérifiez le certificat servi à l'aide de la commande openssl présentée plus haut.
4. 4Documentez l'emplacement de renouvellement et de déploiement de chaque certificat, afin que la prochaine migration emporte la tâche de renouvellement en même temps que le site.
5. 5Surveillez de la même façon le domaine lui-même : un certificat ne peut plus être renouvelé une fois le nom expiré (voir que se passe-t-il quand un nom de domaine expire).