Let’s Encrypt réduit la durée des certificats à 64 jours et force les self-hosters à revoir leur automatisation
Le 7 octobre 2026, Let’s Encrypt annonce que tous les certificats passeront à 64 jours de validité par défaut à partir du 10 février 2027. Vérifiez dès maintenant que votre client ACME gère ARI ou que vos renouvellements ne sont pas codés en dur sur des dates figées.
Le 7 octobre 2026, Let’s Encrypt annonce que tous ses certificats passeront à 64 jours de validité par défaut à partir du 10 février 2027. Le 14 octobre 2026, l’environnement de staging bascule déjà en 64 jours pour permettre les tests. Le dernier certificat à 90 jours expirera le 11 mai 2027. Pourquoi c’est important : la plupart des self-hosters ne regardent jamais leurs logs de renouvellement tant que ça marche — c’est précisément le comportement que ce changement vient punir.
Ce qui change, concrètement
La règle est simple à retenir. À compter du 10 février 2027, tout certificat émis ou renouvelé par Let’s Encrypt aura une durée de 64 jours, sauf si vous choisissez explicitement un profil plus court — 45 jours ou 6 jours, comme annoncé dès le 2 décembre 2025. L’autorité ne révoquera aucun certificat valide en cours de route : la transition se fait par attrition, au fil des renouvellements.
Deux dates comptent pour la préparation. Le 14 octobre 2026, la staging environment passe en 64 jours : c’est la fenêtre pour tester votre chaîne de renouvellement sans risque sur la production. Le 11 mai 2027, le dernier certificat à 90 jours expire : après cette date, plus personne ne dispose d’un certificat long. Si votre automatisation est cassée, vous le découvrirez au plus tard à ce moment-là — probablement un dimanche soir.
Le motif avancé par Let’s Encrypt est limpide. Une durée plus courte réduit la fenêtre pendant laquelle une clé compromise ou un certificat mal émis reste exploitable. L’organisation y voit une mission : en tant qu’autorité à but non lucratif, elle pousse la sécurité du Web entier, y compris quand cela force ses utilisateurs à réviser leur outillage.
Pourquoi 64 jours, et pourquoi ça continue
Ce n’est pas un coup d’arrêt, mais une étape. Let’s Encrypt a déjà prévenu, le 2 décembre 2025, que la cible finale est une durée par défaut de 45 jours en 2028. Le passage à 64 jours est donc un palier intermédiaire destiné à préparer les infrastructures à des renouvellements plus fréquents, sans basculer d’un coup vers le rythme le plus agressif.
Le raisonnement technique sous-jacent vient de l’industrie. Plus un certificat vit longtemps, plus la compromission d’une clé privée reste exploitable longtemps, et plus le délai entre une émission fautive et sa détection est long. Les navigateurs et les grandes autorités poussent depuis des années vers des durées courtes ; Let’s Encrypt accélère simplement le calendrier pour l’écosystème qu’il sert.
Deux changements collatéraux accompagnent la mesure. La période de réutilisation d’une autorisation de validation passe de 30 jours à 10 jours, puis à 7 heures en 2028, pour anticiper une réduction réglementaire des durées maximales de réutilisation et supprimer le « CAA rechecking ». Les rate limits, eux, ne bougent pas. Sauf si votre client a été écrit pour exploiter la réutilisation de validation, vous n’avez rien à faire sur ce point.
D’où vient cette trajectoire
Le passage à 64 jours s’inscrit dans une compression continue de la durée des certificats. Il y a une décennie, un certificat SSL vivait couramment un à deux ans. Les navigateurs ont ensuite imposé la descente : deux ans, puis 398 jours, puis 90 jours, devenu le standard de fait grâce à Let’s Encrypt. L’étape des 64 jours prépare celle des 45 jours en 2028, déjà annoncée.
Pourquoi cette obsession des durées courtes ? Parce que le coût d’une clé compromise est proportionnel au temps pendant lequel elle reste valide. Un certificat qui vit deux ans laisse un attaquant exploiter une clé volée pendant des mois. À 64 jours, la fenêtre se referme en deux mois ; à 45 jours, en six semaines. L’automatisation ACME ayant rendu le renouvellement quasi gratuit, la durée longue ne protège plus personne : elle ne profite qu’à l’attaquant et aux installations mal configurées.
La conséquence pour le self-hoster est directe. La durée des certificats n’est plus une variable qu’on choisit, mais une contrainte qui descend. Celui qui calibre son automatisation pour 90 jours devra la recalibrer pour 64, puis pour 45. Mieux vaut adopter dès maintenant un renouvellement piloté par ARI, qui rend le client indifférent à la durée exacte du certificat.
Ce qui casse si vous ne faites rien
Le risque ne vient pas des clients bien configurés, mais des automatisations figées. Deux cas de figure dominent chez les self-hosters.
Le premier, c’est le renouvellement codé en dur sur une date fixe. Beaucoup de cron jobs, de scripts wrappers et de runbooks renouvellent « N jours avant expiration » avec des valeurs calées sur l’ancienne durée de 90 jours. Les chiffres à chercher sont 83, 80 ou 60. Avec un certificat à 64 jours, un renouvellement planifié à J-83 ne se déclenche jamais, et le certificat expire.
Le second, c’est le client qui ne gère pas ARI, l’ACME Renewal Info. ARI permet à l’autorité de dire au client quand renouveler, ce qui rend le client indifférent à la durée exacte du certificat. Si votre client supporte ARI, la bascule est transparente. Sinon, vous devez explicitement passer à un renouvellement « aux deux tiers de la durée de vie », ce qui pose les bases pour les 45 jours de 2028.
Il y a aussi un effet de bord invisible : la réutilisation de validation qui passe de 30 à 10 jours. Si un outil maison repose sur cette réutilisation pour éviter de revalider un domaine à chaque renouvellement, il risque des échecs plus fréquents. La recommandation officielle est de ne pas en dépendre.
Ce qu’il faut vérifier dès maintenant
La préparation tient en quatre gestes, dans l’ordre.
- Identifiez votre client ACME et vérifiez dans sa documentation s’il implémente ARI. Caddy, Traefik, certbot récent, Nginx Proxy Manager et la plupart des clients maintenus le font ; les scripts maison, moins.
- Cherchez les valeurs codées en dur dans vos cron jobs et scripts. Un
grep -rn "83\|80\|60"sur vos dossiers de déploiement révèle les renouvellements calés sur l’ancienne durée. - Testez en staging après le 14 octobre 2026. La staging environment émettra des certificats à 64 jours avant la production : c’est le seul moyen de valider votre chaîne sans risquer une expiration réelle.
- Ajoutez de l’alerte sur les échecs de renouvellement. Une automatisation qui échoue en silence est la cause n° 1 des expirations ; un simple cron qui envoie un email quand le certificat approche de la fin suffit.
La plupart des self-hosters qui utilisent un reverse proxy moderne ne devront rien changer. Le vrai danger est concentré sur les installations anciennes, les scripts bricolés et les services qui n’ont pas été touchés depuis des mois.
Verdict
Si votre renouvellement passe par Caddy, Traefik, certbot ou Nginx Proxy Manager à jour, et que vous n’avez rien codé en dur, la bascule vers 64 jours est une non-action : testez en staging après le 14 octobre et vérifiez que l’alerte d’échec existe. Si vous avez un script maison, un client sans ARI ou des valeurs 83/80/60 dans vos cron jobs, corrigez maintenant le renouvellement à deux tiers de durée et supprimez toute dépendance à la réutilisation de validation — sinon, le 11 mai 2027 marquera la fin de votre dernier certificat à 90 jours et, probablement, une coupure de service évitable.