Let’s Encrypt raccourcit les certificats à 64 jours en février 2027, puis à 45 jours en 2028

10 février 2027. Let’s Encrypt fait passer la durée de vie par défaut des certificats de 90 à 64 jours. 14 octobre 2026. L’environnement de staging émet déjà des certificats de 64 jours pour permettre les tests. 16 février 2028. Le défaut tombe à 45 jours. Pourquoi c’est important : quiconque renouvelle encore ses certificats avec un cron à date fixe va voir ses sites tomber en erreur de certificat, sans exception.

Le calendrier précis, pour ne pas être surpris

Let’s Encrypt a publié le 7 octobre 2026 un calendrier sans ambiguïté. À compter du 10 février 2027, tout certificat émis ou renouvelé aura une validité de 64 jours par défaut — sauf à choisir explicitement un profil plus court, 45 ou 6 jours, déjà annoncé fin 2025.

Le dernier certificat de 90 jours expirera le 11 mai 2027. Aucune révocation de certificat valide n’est prévue : la transition est douce, elle ne casse rien par elle-même. Puis, le 16 février 2028, le défaut descendra à 45 jours, ce qui achève le mouvement engagé de longue date.

L’environnement de staging a basculé en 64 jours dès le 14 octobre 2026. C’est le point d’entrée pour tester votre chaîne de renouvellement avant le passage en production, sans risque sur vos certificats réels.

Pourquoi 64 jours, et pourquoi ça vous concerne

La motivation est simple et assumée par Let’s Encrypt : réduire la fenêtre de risque en cas de compromission de clé ou de mauvaise émission. Un certificat de 64 jours qui fuit a une valeur d’exploitation plus courte qu’un certificat de 90 jours. C’est la même logique qui a poussé Apple puis l’écosystème vers des durées raccourcies, et elle va devenir la norme pour l’ensemble des autorités, pas seulement Let’s Encrypt.

La conséquence concrète touche d’abord les auto-hébergeurs. Sur un NAS, un VPS ou un serveur maison, le renouvellement est souvent un cron écrit une fois puis oublié. Tant que le certificat durait 90 jours, un renouvellement « 30 jours avant expiration » laissait une marge confortable. À 64 jours, puis 45, la marge disparaît et les scripts à date fixe sortent du cycle.

Le second changement est celui de la période de réutilisation d’autorisation : elle passe de 30 à 10 jours dès maintenant, puis à 7 heures en 2028. Sauf si votre client ACME a été conçu pour dépendre de cette réutilisation, vous n’avez rien à faire — mais c’est un signal supplémentaire que tout le flux de validation se resserre.

Ce qui casse, et ce qui ne casse pas

L’annonce distingue nettement les deux populations. Si vos renouvellements sont automatisés et que votre client supporte ARI (ACME Renewal Info), vous êtes déjà prêt : Let’s Encrypt indique à votre client quand renouveler, et la durée de vie du certificat devient un détail d’implémentation.

Si vos renouvellements sont codés en dur sur une date, vous devez agir avant février 2027. Let’s Encrypt recommande de renouveler à environ deux tiers de la durée de vie du certificat, et de chercher les nombres figés dans vos scripts : 83, 80 ou 60 jours sont les valeurs typiques à remplacer.

# Audit rapide des crons qui renouvellent à date fixe
grep -rE "(83|80|60)" /etc/cron* /etc/systemd/system 2>/dev/null

Le bon réflexe est de remplacer toute logique « renouveler N jours avant expiration » par un déclencheur fondé sur ARI ou, à défaut, par un renouvellement fréquent et idempotent — certbot renew et les clients modernes sont déjà conçus pour tourner plusieurs fois par jour sans effet de bord.

Ce qui ne change pas : les limites de débit, les endpoints ACME et les chaînes d’émission. Vous ne changez ni d’URL, ni de chaîne racine, ni de quota. Seule la durée de validité se contracte.

Ce que ça change sur un NAS ou une box

Sur un NAS Synology, UGREEN ou une box auto-hébergée, le renouvellement passe souvent par le panneau de contrôle du constructeur ou par un conteneur Docker dédié. La bascule à 64 jours ne demande rien de particulier si le client ACME embarqué supporte ARI ou renouvelle à intervalle court. Mais deux pièges guettent les installations plus anciennes : des tâches planifiées écrites pour un certificat de 90 jours, et des scripts personnels qui copient le certificat vers un service — reverse proxy, client VPN — sans recharger ce service après renouvellement.

Le test en staging est exactement fait pour ça : déroulez une émission complète, puis vérifiez que le service qui consomme le certificat le recharge effectivement. Un certificat renouvelé mais pas rechargé est un incident qui n’apparaît qu’à l’expiration — et avec des durées plus courtes, il apparaîtra plus vite.

Qui supporte ARI, et comment le vérifier

La variable qui décide de tout, c’est le support d’ARI (ACME Renewal Info), le mécanisme par lequel Let’s Encrypt signale à votre client le bon moment pour renouveler. Les clients majeurs l’ont intégré de longue date : certbot, acme.sh, lego, Caddy — qui renouvelle nativement en arrière-plan — et Traefik via son provider ACME. La vérification tient en une commande ou en une lecture de version.

Le bon réflexe n’est pas de deviner, mais de consulter la documentation de votre client pour confirmer qu’ARI est implémenté dans votre version précise. Si c’est le cas, vous êtes prêt pour le passage à 64 jours sans toucher à rien : le client suivra le calendrier annoncé par l’autorité. Si ce n’est pas le cas, basculez vers un client qui le supporte, ou forcez un renouvellement fréquent et idempotent.

Le contexte plus large va dans le même sens. Apple proposait déjà en 2023 des certificats de 47 jours, et le CA/Browser Forum pousse depuis des années vers des durées plus courtes. Let’s Encrypt ne fait qu’aligner son calendrier sur une trajectoire que les navigateurs ont déjà validée : à terme, les certificats de longue durée deviendront l’exception, pas la norme.

Ce qu’il faut faire maintenant

L’annonce laisse du temps, mais le travail est du type « une heure maintenant, une panne évitée en février ».

• Vérifier le support ARI. Consultez la documentation de votre client ACME (certbot, acme.sh, lego, Caddy, Traefik…). S’il supporte ARI, vous n’avez rien à changer : le client suivra automatiquement le nouveau calendrier.
• Traquer les dates codées en dur. Cherchez 83, 80 et 60 dans les crons, les scripts d’enveloppe et les runbooks. Remplacez-les par un renouvellement à deux tiers de la durée de vie, ou mieux, par un déclencheur ARI.
• Tester en staging. L’environnement de staging émet déjà des certificats de 64 jours depuis le 14 octobre 2026. Validez votre chaîne complète — émission, déploiement, rechargement du service — avant février 2027.
• Automatiser le rechargement et l’alerte. Profitez de l’occasion pour automatiser le redéploiement du certificat et ajouter une alerte en cas d’échec de renouvellement. Un certificat expiré est un incident évitable, pas un événement météo.

Verdict

Si vous auto-hébergez des services en HTTPS, ouvrez votre gestionnaire de tâches aujourd’hui et remplacez toute règle « renouveler à date fixe » par ARI ou un renouvellement fréquent : à 64 jours puis 45 jours, la marge manuelle n’existe plus. Si votre client ACME supporte déjà ARI, vous n’avez littéralement rien à faire — et c’est précisément le but : des durées plus courtes ne sont tenables que si le renouvellement devient un automatisme que plus personne ne surveille à la main.

Références

• Let’s Encrypt — 64-Day Certificate Lifetimes Coming Feb 2027 (7 octobre 2026)
• Let’s Encrypt — From 90 to 45 days (2 décembre 2025)
• Let’s Encrypt — Documentation des profils de certificats
• Let’s Encrypt — Documentation de l’environnement staging