Let's Encrypt passe aux certificats de 64 jours : ce que les agences doivent vérifier

Le calendrier, les réglages de renouvellement qui vont casser, et une checklist à dérouler pour chaque site client.

Pour une agence, ce n'est pas un réglage à changer sur un serveur. C'est le même réglage sur chaque site client hébergé, sur l'hébergement mutualisé récupéré d'un ancien prestataire, sur le vieux VPS que personne n'a ouvert depuis la mise en ligne, et sur le répartiteur de charge où quelqu'un dépose encore le certificat à la main. La plupart passeront sans problème. Ceux qui casseront le feront en silence, et le premier à s'en rendre compte sera un client devant une alerte de sécurité du navigateur. Ce guide vous dit où regarder.

Le calendrier

Deux calendriers se superposent. Le CA/Browser Forum, où navigateurs et autorités de certification fixent les règles communes, plafonne la durée de vie de tous les certificats publics. Let's Encrypt, déjà bien en dessous de ces plafonds, raccourcit ses propres certificats avec un temps d'avance.

Ces dates valent pour les certificats émis à partir de ce jour-là. Chaque site recevra donc son premier certificat de 64 jours à son premier renouvellement après le 10 février 2027, pas le jour même.

Les certificats payants suivent le calendrier du CA/B Forum, pas celui de Let's Encrypt : si certains clients achètent leur certificat auprès d'une autorité commerciale, c'est l'étape des 100 jours, en mars 2027, qui les concerne.

Ce qui casse

Let's Encrypt le dit clairement : si vos renouvellements sont automatisés et que votre client gère ARI, vous n'avez rien à faire. Tout ce qui suit concerne les installations qui ne sont pas dans ce cas. Pour se repérer : les deux tiers de 64 jours, c'est environ le 43e jour, soit à peu près trois semaines de marge.

Les délais codés en dur pour 90 jours

Beaucoup de scripts datent de l'époque où tous les certificats duraient 90 jours, et comptent à partir de la date d'émission. Let's Encrypt conseille de chercher trois nombres dans les tâches cron, les scripts maison et les procédures internes : 83, 80 et 60.

• 83 ou 80 jours après l'émission. Quand le script se décide à renouveler, un certificat de 64 jours a expiré depuis 16 à 19 jours. Ces installations cassent dès le premier renouvellement après la bascule.
• 60 jours après l'émission. Ça tient encore sur le papier, avec 4 jours de marge. Un seul échec (port 80 fermé, DNS modifié, limite de requêtes atteinte) et le site tombe. En février 2028, avec des certificats de 45 jours, ça ne tient plus du tout : le certificat expire 15 jours avant la date prévue de renouvellement.

Un réglage exprimé en temps avant l'expiration vieillit mieux : renouveler quand il reste 30 jours donne, sur un certificat de 64 jours, un renouvellement au 34e jour. Un nombre fixe de jours après l'émission, non.

Le renouvellement aux deux tiers

C'est la règle que Let's Encrypt recommande aux clients sans ARI, parce qu'elle suit le certificat et non le calendrier : 60 jours sur un certificat de 90 jours, environ 43 sur un certificat de 64 jours, 30 sur un certificat de 45 jours. Un script qui lit les vraies dates notBefore et notAfter du certificat et renouvelle aux deux tiers n'a besoin d'aucune modification. Si quelqu'un a traduit « deux tiers » par une constante de 60 jours, c'est un délai codé en dur comme les autres.

Les tâches cron trop espacées

Une tâche de renouvellement lancée une fois par mois n'a qu'une ou deux chances dans une fenêtre de trois semaines. Si la seule tentative échoue, la suivante peut arriver après l'expiration. La RFC 9773, qui normalise ARI, fait le même constat : les clients lancés par cron devront sans doute tourner plus souvent, et garder alors la trace de leurs échecs pour espacer les nouvelles tentatives au lieu de boucler. Lancez la vérification au moins une fois par jour et laissez le client décider s'il faut renouveler.

Les vieux hébergements et les copies manuelles

Certains certificats ne sont pas renouvelés là où ils servent. Ils sont émis sur une machine, puis déposés à la main dans un panneau d'hébergement mutualisé, sur un CDN, un serveur de messagerie ou un boîtier réseau. Avec un renouvellement vers le 43e jour, chacun d'eux est renouvelé huit ou neuf fois par an au lieu de six environ. Chaque étape manuelle se répète d'autant, et la personne qui l'a faite la dernière fois a peut-être quitté le projet. Notre guide sur les échecs de renouvellement Let's Encrypt détaille le piège voisin : le renouvellement a eu lieu, mais rien n'a été rechargé.

Les scripts qui comptent sur la réutilisation des validations

À partir du 10 février 2027, une validation de domaine reste réutilisable 10 jours au lieu de 30, puis 7 heures en 2028. Let's Encrypt précise que la plupart des clients n'en dépendent pas. Sont concernées les installations qui valident un domaine une fois et émettent les certificats plus tard, par exemple une validation lancée à la main avant un traitement par lot.

La checklist de l'agence

À dérouler une fois par serveur ou plateforme qui renouvelle des certificats, pas une fois par site.

1. 1Recensez où se font vraiment les renouvellements. Pour chaque site client : quelle machine ou quel service renouvelle le certificat, avec quel client ACME, et où le certificat est ensuite déployé.
2. 2Cherchez les délais codés en dur. Sur chaque machine, cherchez 83, 80 et 60 dans les tâches cron, les timers systemd, les scripts et les procédures. Il y aura du bruit (*/60, ports, timeouts) : ce sont des nombres de jours que vous cherchez.

grep -rnE '\b(83|80|60)\b' /etc/cron* /etc/systemd/system /usr/local/bin 2>/dev/null

1. 3Vérifiez si votre client gère ARI. Cherchez « ARI » ou « renewal information » dans la documentation ou le journal des versions de votre client ACME. Let's Encrypt l'annonce dans son répertoire ACME sous renewalInfo.
2. 4Testez sur le staging dès maintenant. L'environnement de staging délivre, selon l'annonce, des certificats de 64 jours depuis le 14 octobre 2026. Avec Certbot, sudo certbot renew --dry-run simule un renouvellement complet sur le staging sans toucher à vos vrais certificats. Les autres clients ont une option de staging ou de test équivalente.
3. 5Contrôlez la durée de ce que vous obtenez. Sur un certificat émis après la bascule, lisez les dates et vérifiez que la logique de renouvellement tient toujours :

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

1. 6Passez la tâche en quotidien. Remplacez les renouvellements mensuels ou hebdomadaires par une vérification chaque jour, et assurez-vous qu'elle garde la trace des échecs.
2. 7Automatisez le rechargement et chaque copie. Utilisez les deploy hooks pour recharger le serveur web, et scriptez tout envoi vers un CDN, un répartiteur de charge ou un serveur de messagerie. Ce qui reste manuel devra être refait huit ou neuf fois par an et par certificat.
3. 8Commencez par les sites hérités. Les vieux panneaux d'hébergement et les installations bricolées sont ceux qui risquent le plus de casser. Traitez-les avant février, pas après la première alerte navigateur.
4. 9Gardez un œil sur le domaine lui-même. Impossible de renouveler un certificat quand le nom de domaine a expiré : voir ce qui se passe quand un domaine expire.

Ce que fait ACME ARI, et ce qu'il ne fait pas

ACME Renewal Information est une extension du protocole ACME, normalisée dans la RFC 9773. L'autorité de certification publie un point d'accès renewalInfo. Pour chaque certificat, le client lui demande une fenêtre de renouvellement suggérée (un début et une fin), choisit un moment au hasard dans cette fenêtre et renouvelle à ce moment-là. Le serveur lui indique aussi quand redemander.

C'est la réponse au problème de tout ce guide : le client n'a plus à deviner la bonne date à partir d'une durée de vie inscrite dans son code. Quand Let's Encrypt raccourcit ses certificats, ou doit faire remplacer un lot de certificats en avance après un incident, il déplace la fenêtre et les clients ARI suivent. Sur un certificat Let's Encrypt de 90 jours actuel, nous avons constaté une fenêtre qui s'ouvrait environ 30 jours avant l'expiration.

Vous pouvez consulter cette fenêtre vous-même. La requête est un simple GET sans authentification, construit à partir de l'Authority Key Identifier et du numéro de série du certificat (OpenSSL 1.1.1 ou plus récent, et Perl) :

host=example.com
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null | openssl x509 > cert.pem
hex2b64url() { tr -d ' :\n' | perl -pe 's/([0-9a-fA-F]{2})/chr hex $1/ge' | openssl base64 -A | tr '+/' '-_' | tr -d '='; }
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | tail -n1 | sed 's/.*keyid://' | hex2b64url)
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
[ $(( ${#serial} % 2 )) -eq 1 ] && serial="0$serial"
case "$serial" in [89A-Fa-f]*) serial="00$serial";; esac
curl -s "https://acme-v02.api.letsencrypt.org/acme/renewal-info/$aki.$(printf %s "$serial" | hex2b64url)"

Ce qu'ARI ne fait pas, c'est confirmer que quelque chose s'est passé. Il dit au client quand renouveler. Il ne vérifie ni que le renouvellement a réussi, ni que le nouveau certificat a été déployé sur chaque serveur, ni que le site le sert bien. Un certificat « en renouvellement automatique » n'est pas forcément un certificat renouvelé. Ce trou existait déjà ; il reste simplement moins de temps pour le voir.

Comment surveiller

Le seul signal fiable, c'est le certificat que reçoit réellement le visiteur. Les journaux de la tâche de renouvellement disent que la tâche a tourné ; ils ne disent pas ce que sert le CDN placé devant le site. Vérifiez donc de l'extérieur :

1. 1Alertez sur le certificat servi, pas sur le fichier du disque. Lisez la date d'expiration sur le site en ligne, comme le ferait un navigateur.
2. 2Réglez les alertes sur la nouvelle durée de vie. Si le renouvellement a normalement lieu environ 21 jours avant l'expiration, une alerte à J-14 signifie qu'il échoue depuis une semaine, et J-7 est le dernier moment confortable pour corriger. Une alerte à J-60 n'a aucun sens pour un certificat de 64 jours.
3. 3Repérez un changement de durée ou d'émetteur. Un certificat qui vient soudain d'une autre autorité, ou qui dure encore 90 jours en avril 2027, signale que quelque chose a changé dans l'installation.
4. 4Envoyez l'alerte à quelqu'un qui travaille encore sur le projet. Pour chaque client, vérifiez qui la reçoit aujourd'hui.

C'est ce que fait Lapsentry pour les agences : il lit le certificat servi par chaque domaine client, à côté de la date d'expiration du domaine, et prévient les bonnes personnes par e-mail, Slack, Teams ou SMS avant que l'un ou l'autre n'expire.

Essayer gratuitement pendant 14 jours : sans carte bancaire.

Sources

• Let's Encrypt, 64-Day Certificate Lifetimes Coming Feb 2027, 7 octobre 2026 (en anglais).
• Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days, 2 décembre 2025 (en anglais).
• Let's Encrypt, documentation Profiles (classic, tlsserver, shortlived).
• IETF, RFC 9773 : ACME Renewal Information (ARI) Extension.
• CA/Browser Forum, Baseline Requirements, section 6.3.2, et ballot SC-081v3.

FAQ

Quand les certificats Let's Encrypt passent-ils à 64 jours ?

Le 10 février 2027, pour tout certificat émis ou renouvelé à partir de cette date avec le profil par défaut. Chaque site reçoit son premier certificat de 64 jours à son premier renouvellement après cette date. L'environnement de staging en délivre, selon l'annonce, depuis le 14 octobre 2026, pour les tests.

Mes certificats de 90 jours actuels vont-ils être révoqués ?

Non. Let's Encrypt indique qu'il ne révoquera aucun certificat valide dans le cadre de ce changement. Ils restent valables jusqu'à leur échéance normale, et les derniers devraient expirer vers le 11 mai 2027.

Qu'est-ce qu'ACME ARI ?

ACME Renewal Information (RFC 9773) permet à l'autorité de certification d'indiquer à votre client ACME quand renouveler chaque certificat, sous la forme d'une fenêtre de temps suggérée. Un client compatible ARI n'a pas besoin d'un délai de renouvellement écrit dans sa configuration : la baisse de la durée de vie ne demande donc aucune modification.

Que changer si mon client ne gère pas ARI ?

Renouvelez aux deux tiers environ de la durée de vie du certificat, calculée à partir de ses vraies dates, et lancez la vérification au moins une fois par jour. Supprimez les délais fixes comme 60, 80 ou 83 jours après l'émission.

Le réglage par défaut de Certbot, « renouveler 30 jours avant l'expiration », fonctionne-t-il encore ?

Oui pour les certificats de 64 jours : le renouvellement a lieu vers le 34e jour, avec un mois de marge. Il fonctionne aussi avec les certificats de 45 jours en 2028, le renouvellement arrivant alors au 15e jour. L'important est que la tâche tourne assez souvent pour réessayer en cas d'échec.

Les certificats SSL payants sont-ils concernés ?

Oui, selon un autre calendrier. Le CA/Browser Forum plafonne tous les certificats publics à 200 jours depuis le 15 mars 2026, puis à 100 jours à partir du 15 mars 2027 et à 47 jours à partir du 15 mars 2029. Les autorités commerciales appliquent ces limites aux certificats qu'elles vendent.

À quelle fréquence chaque certificat sera-t-il renouvelé ?

Avec un renouvellement aux deux tiers de 64 jours, environ tous les 43 jours, soit huit ou neuf fois par an, contre six environ avec des certificats de 90 jours. Les renouvellements automatiques ne verront pas la différence. Les étapes manuelles, comme déposer un certificat dans un panneau d'hébergement, si.

Autres guides

• Pourquoi les renouvellements Let's Encrypt échouent
• Que se passe-t-il quand un nom de domaine expire ?
• Sous-domaines orphelins : ce que c'est et comment les trouver
• À qui doit appartenir un domaine client ?