Let’s Encrypt, l’autorité de certification la plus utilisée dans le monde pour HTTPS, se prépare à réduire à nouveau la durée de vie de ses certificats de moitié.
D’ici 2028, tous les certificats standard de Let’s Encrypt auront une longueur maximale de validité de 45 jours, contre 90 jours actuellement.
Ce n’est pas une expérience isolée de Let’s Encrypt, mais une tendance adoptée par l’ensemble de l’industrie. Ce changement est impulsé par le CA/Browser Forum, l’organisme qui définit les règles entre navigateurs et autorités de certification. Suite à une proposition initiale d’Apple, le forum a convenu que les certificats publics (sauf les certificats racine) aient une durée maximale de 47 jours. Let’s Encrypt s’aligne sur cette exigence et renforce également certaines de ses propres politiques.
Pour les opérateurs, équipes DevOps et SRE, la conclusion est claire :
Les certificats à cycle de vie court sont l’avenir, et la gestion automatisée de leur renouvellement n’est plus optionnelle.
De 90 à 45 jours : feuille de route du changement
Actuellement, Let’s Encrypt délivre des certificats avec une validité de 90 jours. Cette durée sera progressivement réduite en plusieurs phases, laissant à tout l’écosystème le temps de s’adapter :
Phase 1 – Profil d’essai optionnel (13 mai 2026)
- Le profil ACME
tlsservercommencera à délivrer des certificats d’une validité de 45 jours. - Ceci est un profil optionnel, destiné aux premiers adopteurs et aux environnements de test souhaitant vérifier leurs outils avant que cette limite ne devienne la norm
Phase 2 – Validité réduite pour le profil classique (10 février 2027)
- Le profil ACME par défaut, le profil “classic”, commencera à délivrer des certificats d’une durée de 64 jours.
- La reutilisation des validations (le délai pendant lequel une validation de domaine peut être réutilisée) sera réduit à 10 jours.
Phase 3 – Limite définitive de 45 jours (16 février 2028)
- Le profil classique sera à nouveau ajusté pour délivrer des certificats de 45 jours.
- Le délai de réutilisation des validations sera drastiquement réduit à 7 heures.
À partir de cette date, tout nouveau certificat de Let’s Encrypt aura, de facto, une durée de vie courte. Les utilisateurs constateront la nouvelle durée selon leur prochain cycle de renouvellement après chaque échéance.
Autorisation de domaine : de 30 jours à seulement 7 heures
Ce n’est pas seulement la durée de validité des certificats qui diminue. Let’s Encrypt va également réduire la période pendant laquelle la preuve de contrôle d’un domaine peut être réutilisée.
Situation actuelle :
- Lorsqu’un client prouve qu’il contrôle un domaine (via HTTP-01, TLS-ALPN-01 ou DNS-01), cette autorisation peut être réutilisée pendant 30 jours pour émettre d’autres certificats pour ce domaine.
Situation en 2028 :
- Ce délai de reutilisation sera réduit à seulement 7 heures.
En pratique, cela signifie que :
- Si le client ACME valide un domaine mais n’émets pas son certificat dans ces 7 heures, il devra revalider le domaine.
- Toute opération d’émission fragile ou manuelle sera rapidement mise en évidence, puisqu’elle ne pourra pas s’étendre sur une durée plus longue.
Pour les clients ACME modernes, fonctionnant de façon continue et automatisée, cela ne pose pas de problème. Pour des déploiements manuels ou semi-manuels, c’est une alerte à prendre en compte.
Pourquoi l’industrie penche vers des certificats plus courts
Du point de vue de la sécurité et de la PKI, réduire la durée de vie des certificats résout plusieurs problèmes chroniques :
- Moindre impact en cas de compromission de la clé privée
En cas de vol d’une clé privée, l’usurpation du site ne peut durer aussi longtemps. Avec des certificats plus courts, cette fenêtre est limitée par conception, même si les mécanismes de révocation échouent ou sont peu efficaces. - Moins de dépendance aux mécanismes de révocation peu fiables
CRL et OCSP sont sous surveillance depuis des années : ils sont complexes, lents, et tous les clients ne respectent pas toujours leur signalement. avec des certificats qui expirent rapidement, la pression sur ces systèmes diminue, et la circulation des « certificats zombies » après intrusion est réduite. - La rotation fréquente des clés devient la norme
Avec des certificats de 45 jours, la rotation est quasi continue. Ceci s’adapte aux bonnes pratiques actuelles dans le cloud et les microservices, où les identifiants sont perçus comme éphémères plutôt que comme des ressources statiques.
En résumé, cette évolution demande plus d’opérations mais offre une sécurité renforcée pour le web public.
ACME Renewal Information (ARI) : que le CA vous dise quand renouveler
Pour éviter que ces nouvelles limites entraînent une prolifération de certificats expirés, Let’s Encrypt promeut l’utilisation de ACME Renewal Information (ARI).
Avec ARI, l’autorité de certification peut indiquer au client ACME quand il doit renouveler un certificat précis, plutôt que d’utiliser une règle fixe du type « renouveler tous les 60 jours ».
Dans un contexte où la durée de vie est de 45 jours, ce type de logique statique devient risqué :
- Un intervalle de renouvellement de 60 jours n’a plus de sens : le certificat aura expiré avant.
- La meilleure approche consiste à renouveler à peu près à deux tiers de la durée de vie (environ le jour 30 pour un certificat de 45 jours), ou encore mieux, en suivant les indications envoyées par le CA via ARI.
Les tâches pour les opérateurs sont :
- Vérifier si leur client ACME (Certbot, acme.sh, intégrations dans des panneaux de contrôle, etc.) supporte déjà ARI.
- Activer ARI dès que possible et abandonner les intervalles rigides conçus pour des certificats de 90 jours.
Les renouvellements manuels : une pratique vouée à disparaître
Let’s Encrypt est formel : les renouvellements manuels ne sont pas recommandés, et avec ces changements, ce sera encore plus le cas.
Avec des certificats de 45 jours et des fenêtres de validation plus courtes, les processus manuels deviennent :
- Plus fréquents.
- Plus sujets à erreur humaine.
- Plus susceptibles de conduire à des certificats expirés en production.
En pratique, un environnement dépendant d’un administrateur qui doit manuellement « renouveler le certificat » est désormais très exposé aux messages de type « votre connexion n’est pas privée » dans le navigateur.
La seule stratégie viable à l’avenir repose sur :
- Une émission et un renouvellement entièrement automatisés, y compris le déploiement des certificats sur les serveurs web, équilibrages de charge, proxies et APIs.
- Une surveillance et des alertes spécifiques sur la date d’expiration et les échecs de renouvellement, pour anticiper plutôt que de réagir après coup.
DNS-PERSIST-01 : automatiser le défi DNS avec moins de friction
L’un des défis majeurs de l’automatisation ACME a toujours été la validation de contrôle du domaine. Les méthodes actuelles exigent que le client interagisse en temps réel avec l’infrastructure :
- HTTP-01 : servir un token précis via HTTP.
- TLS-ALPN-01 : effectuer un handshake TLS spécifique.
- DNS-01 : créer ou mettre à jour des enregistrements TXT dans DNS.
Pour les organisations qui ne veulent pas donner aux clients automatiques un accès étendu aux serveurs web ou à la gestion DNS, cela peut poser problème.
Pour réduire cette friction, Let’s Encrypt et d’autres travaillent sur une nouvelle méthode appelée DNS-PERSIST-01 :
- Reposant sur un enregistrement TXT persistant en DNS pour prouver la maîtrise du domaine.
- Ce registre ne nécessite pas d’être modifié à chaque renouvellement.
- Une fois configuré, il permettra de renouveler automatiquement des certificats sans modifications DNS répétées.
Let’s Encrypt prévoit que DNS-PERSIST-01 sera disponible vers 2026, facilitant ainsi l’adoption d’une automatisation complète pour des environnements plus conservateurs, tout en limitant l’impact d’un accès DNS étendu.
Implications pour les opérateurs et plateformes
Pour un public technique — hébergeurs, plateformes SaaS, équipes DevOps, ingénieurs plateforme — les conclusions sont assez simples :
- Si vous utilisez déjà l’émission et le renouvellement automatisés avec ACME, vous êtes sur la bonne voie, mais il est conseillé de :
- Vérifier que votre logique de renouvellement ne dépend pas de cycles de 60 jours.
- Suivre de près la prise en charge de ARI dans votre client et l’activer dès que possible.
- Si vous utilisez encore des renouvellements manuels ou des processus semi-automatiques, vous devrez vous préparer : la combinaison de certificats de 45 jours et d’autorisations réutilisables limitées à 7 heures révélera rapidement toutes failles dans ces flux.
- Pour gérer une plateforme qui automatise HTTPS pour ses clients, il faudra :
- Vérifier que vos clients ACME supportent bien les cycles plus courts et les fenêtres de validation plus strictes.
- Renforcer la surveillance et les alertes sur l’état des certificats et leur renouvellement.
Le bon côté de cette évolution est qu’une fois l’écosystème adapté, la couche TLS du web sera plus robuste, moins exposée à des compromissions sur le long terme, et plus facile à sécuriser.
En résumé, le passage de Let’s Encrypt à des certificats de 45 jours n’est pas qu’un simple ajustement de configuration : c’est un changement fondamental dans la manière dont la confiance, l’identité et le chiffrement sont gérés à grande échelle dans le web.
