Let's Encrypt passe à 64 jours le 10 février 2027 : adapter Certbot et ses scripts

Let's Encrypt a annoncé une réduction progressive de la durée de ses certificats. Le 10 février 2027, le profil par défaut passera de 90 à 64 jours. Si vous administrez un VPS ou un serveur dédié avec Nginx, Apache ou un panel derrière HTTPS, la plupart des installations Certbot continueront de fonctionner. Mais tout ce qui suppose « 90 jours » ou « renouvellement à 60 jours » dans un script, une alerte ou une documentation interne va devenir faux. Ce guide liste ce qu'il faut vérifier, avec les commandes.

Ce qui change, et quand

Les dates viennent de l'annonce officielle de Let's Encrypt From 90 to 45 (letsencrypt.org). Le calendrier s'applique à l'émission : un certificat existant n'est pas raccourci, c'est le suivant qui l'est.

Le profil shortlived (6 jours) reste un choix volontaire. Les certificats de 90 jours émis le 9 février 2027 expireront au plus tard début mai 2027 : la période de transition dure donc environ trois mois, pendant lesquels vous aurez un mélange de certificats de 90 et de 64 jours.

Définitions utiles

• ACME : le protocole d'automatisation que Certbot utilise pour demander et renouveler un certificat.
• Profil ACME : un jeu de règles d'émission proposé par l'autorité (durée, usages). Let's Encrypt en propose plusieurs : classic, tlsserver, shortlived.
• Réutilisation d'autorisation : durée pendant laquelle une validation de domaine déjà réussie dispense d'en refaire une. Elle passe de 30 à 10 jours.
• ARI (ACME Renewal Information) : mécanisme par lequel le serveur indique au client la bonne fenêtre de renouvellement. Let's Encrypt le recommande, notamment pour les clients sans logique de renouvellement fiable.
• Serveur web : logiciel qui sert les pages en HTTP et HTTPS (Nginx ou Apache, par exemple). C'est lui qui présente le certificat aux visiteurs.
• Nom de domaine : adresse lisible (exemple.fr) qui pointe vers l'adresse IP du serveur.
• Adresse IP : numéro qui identifie une machine sur le réseau.
• VPS : serveur privé virtuel, une machine virtuelle isolée sur un serveur physique partagé.
• Fichier de configuration : fichier texte qui règle le comportement d'un logiciel. Une erreur de syntaxe peut bloquer son démarrage.
• Hook : commande exécutée par Certbot avant, après ou lors d'un renouvellement réussi (rechargement du serveur web, copie de certificat).

Configurer Certbot : les fichiers à connaître

Sur un serveur web, Certbot touche à plusieurs fichiers de configuration. Le plugin (extension) Nginx de Certbot, activé avec --nginx, modifie lui aussi la configuration du serveur. Le tableau suivant liste les emplacements les plus fréquents et ce qui peut y devenir faux.

Avant de modifier un fichier de configuration, faites-en une copie. Après chaque changement, validez la syntaxe du serveur avant de le recharger, par exemple avec nginx -t pour Nginx :

nginx -t && systemctl reload nginx

Une configuration valide évite la coupure du service web, même lorsque Certbot a bien renouvelé le certificat.

Certbot : pourquoi la plupart des installations tiennent

La documentation de Certbot indique qu'un certificat est considéré prêt à être renouvelé quand il lui reste moins d'un tiers de sa durée de vie. Avant Certbot 4.0.0, le seuil était fixe, à 30 jours. Avec un certificat de 64 jours, un Certbot récent tentera donc le renouvellement environ 21 jours avant l'expiration, ce qui laisse une marge confortable. Les sources et le détail sont dans la documentation officielle.

Le risque est ailleurs : un Certbot ancien (package de distribution figé) ou un fichier de renouvellement qui force un seuil fixe. Commencez par l'inventaire, depuis la ligne de commande (avec sudo si vous n'êtes pas connecté en root).

certbot --version
certbot certificates
grep -H renew_before_expiry /etc/letsencrypt/renewal/*.conf

La dernière commande ne renvoie rien si vous n'avez jamais personnalisé le seuil, ce qui est le cas le plus sain. Si elle renvoie une valeur en jours, comparez-la à 64 : une valeur supérieure ou égale à 64 déclencherait un renouvellement à chaque exécution. Une valeur de 30 jours reste valable, mais n'oubliez pas qu'elle réduira l'écart avec les 45 jours de 2028.

Si vous découvrez Certbot, commencez par notre guide Certbot et Let's Encrypt sur VPS Linux, puis revenez ici pour les ajustements.

Mettre Certbot à jour

L'ARI est gérée par Certbot depuis la version 4.1.0 : certbot renew consulte alors les informations du serveur et peut renouveler plus tôt si Let's Encrypt le demande (annonce de la version). Si le serveur ne renvoie rien, la configuration locale s'applique. Une version récente est donc le meilleur investissement.

Sur un VPS Linux (Ubuntu, Debian ou une autre distribution Unix), privilégiez l'installation qui reste à jour (snap ou environnement Python isolé, selon votre distribution) plutôt qu'un paquet gelé de plusieurs années. Après mise à jour, relancez l'inventaire ci-dessus. Le choix de la distribution et de son cycle de paquets compte ici : voir quelle distribution Linux pour un VPS.

Vérifier la planification du renouvellement

Certbot recommande d'exécuter certbot renew -q deux fois par jour, avec un délai aléatoire, car la commande ne touche que les certificats proches de l'échéance. Vérifiez qu'un timer ou un cron existe réellement et qu'il s'exécute. Les logs (journaux) du service, lisibles avec journalctl, gardent la trace des échecs passés.

systemctl list-timers | grep -i certbot
journalctl -u certbot.service --since "30 days ago" | tail -n 50
ls /etc/cron.d/ | grep -i certbot

Un cron mensuel, un timer désactivé après une migration ou un conteneur sans planificateur sont les cas classiques. Avec 64 jours, un renouvellement qui n'est tenté qu'une fois par mois laisse peu de tentatives avant l'expiration, et plus encore avec 45 jours en 2028. Pour choisir entre les deux mécanismes, voir cron ou timers systemd sur un VPS Linux.

Un exemple de cron conforme à la recommandation de Certbot :

0 0,12 * * * root sleep $((RANDOM % 3600)) && certbot renew -q

Dans un fichier de /etc/cron.d, $RANDOM n'est pas toujours disponible selon le shell utilisé : si vous constatez que le délai ne s'applique pas, déclarez SHELL=/bin/bash en tête du fichier.

Validation de domaine : l'effet des 10 jours

La réutilisation d'autorisation tombe à 10 jours. Avant, deux renouvellements rapprochés pouvaient s'appuyer sur la même validation. Désormais, chaque renouvellement devra presque toujours refaire un défi complet. Ce détail casse des montages qui « marchaient par chance ».

• HTTP-01 : le port 80 doit rester joignable depuis Internet, sur l'adresse IP publique du serveur, à chaque tentative. Vérifiez votre pare-feu (firewall), vos redirections et les règles de filtrage éventuelles de votre hébergeur. Une règle qui n'ouvre le port 80 que ponctuellement fera échouer des renouvellements.
• DNS-01 : le plugin ou le script qui crée l'enregistrement TXT sera appelé à chaque renouvellement. Contrôlez l'authentification (validité du jeton d'API, droits accordés) et le délai de propagation.
• Reverse proxy : si Nginx redirige tout vers HTTPS, le chemin /.well-known/acme-challenge/ doit rester servi en HTTP. Voir Nginx en reverse proxy sur VPS Linux.

Testez la chaîne complète sans consommer de certificat réel :

certbot renew --dry-run

Cette commande passe par l'environnement de test de Let's Encrypt. Les hooks de pré et post-validation s'exécutent par défaut, mais pas les hooks de déploiement, sauf si vous ajoutez --run-deploy-hooks.

Corriger les scripts et les hooks

Les scripts maison sont la source n°1 de pannes. Cherchez les valeurs codées en dur.

grep -rnE '(^|[^0-9])(90|60|30)([^0-9]|$)' /usr/local/bin /etc/cron.d /etc/cron.daily 2>/dev/null | grep -iE 'cert|ssl|tls|letsencrypt'
grep -rn 'letsencrypt' /etc/systemd/system /etc/cron.* /usr/local/bin 2>/dev/null

Ce que vous cherchez :

• un renouvellement « forcé » tous les 60 jours (--force-renewal dans un cron) : à supprimer, laissez Certbot décider ;
• un seuil d'alerte à 30 jours qui deviendra bruyant ou trop tardif, selon votre calendrier ;
• un test qui compare l'âge du fichier fullchain.pem à 60 ou 80 jours ;
• une documentation d'exploitation qui promet « 90 jours de marge ».

Hooks de déploiement

Les certificats seront renouvelés plus souvent, donc vos hooks s'exécuteront plus souvent. Placez le rechargement du service dans /etc/letsencrypt/renewal-hooks/deploy/, qui ne s'exécute qu'après un renouvellement réussi, plutôt que dans un post-hook qui s'exécute même sans renouvellement.

#!/bin/sh
# /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
set -eu
nginx -t && systemctl reload nginx

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Utilisez reload et non restart (redémarrer) pour éviter de couper les connexions. Si vous copiez le certificat vers un autre service (messagerie, base de données comme MySQL, MariaDB ou PostgreSQL, panel d'administration), faites-le dans ce même hook, avec les bons droits.

Superviser l'expiration, pas seulement le renouvellement

Un renouvellement silencieusement en échec se découvre le jour de l'expiration. Ajoutez un contrôle indépendant de Certbot : il lit le certificat réellement servi.

#!/bin/sh
# Alerte si le certificat expire dans moins de 14 jours
HOST="exemple.fr"
if ! echo | openssl s_client -connect "$HOST:443" -servername "$HOST" 2>/dev/null \
  | openssl x509 -noout -checkend 1209600; then
  echo "Certificat de $HOST : expiration sous 14 jours" | logger -t cert-check
fi

L'option -checkend prend un nombre de secondes (1 209 600 = 14 jours) et renvoie un code d'erreur si le certificat expire avant. Pour afficher les dates : openssl x509 -noout -dates. Notre guide pour vérifier un certificat TLS avec OpenSSL détaille ces commandes.

Choisissez un seuil adapté aux nouvelles durées : avec 64 jours, 14 jours restent raisonnables. Avec 45 jours, en 2028, descendez-le plutôt vers 10 jours, tout en gardant assez de temps pour intervenir. Reliez l'alerte à votre outil habituel : Uptime Kuma est un exemple d'outil de supervision, et le guide sur les alertes de monitoring décrit les canaux de notification.

Profils : tester maintenant, sans risque

Certbot permet de demander un profil précis avec --preferred-profile (repli sur le profil par défaut si le profil est absent) ou --required-profile (échec si le serveur le refuse). Le profil tlsserver, déjà à 45 jours, permet de simuler l'avenir sur un domaine non critique.

certbot certonly --nginx -d test.exemple.fr --preferred-profile tlsserver

Observez ensuite la durée obtenue avec certbot certificates. Si votre domaine de test se renouvelle sans intervention pendant plusieurs semaines, votre chaîne est prête pour 2028. N'utilisez pas --required-profile en production sans plan de repli : une indisponibilité du profil ferait échouer le renouvellement.

Serveurs de jeu, panels et conteneurs

Les certificats servent aussi aux panels web, aux API de serveurs de jeu et aux reverse proxies devant Docker. Trois pièges reviennent :

• Conteneur sans planificateur : Certbot dans un conteneur doit être lancé par un timer de l'hôte ou une tâche dédiée.
• Volume non persistant : sans volume sur /etc/letsencrypt, chaque recréation du conteneur perd les certificats et les fichiers de renouvellement.
• Service qui ne relit pas le certificat : sans rechargement, le service continue de présenter l'ancien certificat jusqu'à son expiration, même si Certbot a bien renouvelé.

Le principe général de publication est décrit dans publier un service sur un VPS Linux en HTTPS. Pour piloter tout cela, il faut un accès root : c'est le cas sur un VPS Linux ou un serveur dédié. Sur une offre de serveur de jeu gérée par le panel Pterodactyl, sans accès SSH root, la gestion des certificats se fait en amont, sur un VPS ou un dédié qui fait office de proxy.

Checklist avant le 10 février 2027

1. Relever la version de Certbot et la mettre à jour (4.1.0 ou plus pour l'ARI).
2. Lister les certificats avec certbot certificates et chercher les renew_before_expiry personnalisés.
3. Confirmer qu'un timer ou un cron lance certbot renew deux fois par jour.
4. Vérifier le port 80 ou le hook DNS-01 pour chaque nom de domaine.
5. Supprimer les --force-renewal et les valeurs « 60 » ou « 90 jours » codées en dur.
6. Placer les rechargements de service dans renewal-hooks/deploy.
7. Ajouter une alerte d'expiration indépendante de Certbot.
8. Lancer certbot renew --dry-run, puis tester un domaine en tlsserver.
9. Mettre à jour votre documentation d'exploitation.

Pensez enfin à faire une sauvegarde (backup) de /etc/letsencrypt : les clés et fichiers de renouvellement s'y trouvent, et une restauration sans eux oblige à tout reconfigurer. Les sauvegardes d'ElypseCloud sont une option à ajouter selon vos besoins ; consultez la page de l'offre concernée.

La bascule de 2027 est un test grandeur nature avant celle de 2028. Les installations bien automatisées n'y verront rien. Les autres ont trois mois, de février à mai 2027, pour corriger avant que tous les certificats soient passés à la nouvelle durée.