Let's Encrypt a annoncé le 7 octobre 2026 qu'à partir du 10 février 2027, tous les abonnés recevront par défaut des certificats d'une durée de 64 jours, sauf s'ils choisissent une durée encore plus courte de 45 ou 6 jours. Tout certificat émis ou renouvelé à partir de cette date sera valable 64 jours, et Let's Encrypt prévoit que le dernier certificat de 90 jours expirera le 11 mai 2027. Les certificats existants ne seront pas révoqués dans le cadre de ce changement.

Le calendrier

  • 14 octobre 2026 : l'environnement de test (staging) commence à émettre des certificats de 64 jours ; Let's Encrypt recommande d'y tester d'abord.
  • 10 février 2027 : le profil par défaut classic passe aux certificats de 64 jours, et la durée de réutilisation d'une validation de domaine déjà effectuée passe de 30 à 10 jours.
  • 16 février 2028 : le profil classic passe ensuite aux certificats de 45 jours, avec une durée de réutilisation des validations de 7 heures.

Il s'agit d'un changement à l'échelle du secteur, imposé par les exigences de base (Baseline Requirements) du CA/Browser Forum, et non d'une décision propre à Let's Encrypt. Dans notre article sur les certificats de 6 jours, nous expliquions comment opter pour des certificats plus courts ; ce changement-ci concerne tous ceux qui utilisent les réglages par défaut.

Qui doit agir

  • Clients compatibles ARI : selon Let's Encrypt, vous « should be all set », autrement dit vous êtes prêts. ARI (ACME Renewal Information) permet à l'autorité de dire à votre client quand renouveler ; consultez la documentation de votre client pour savoir s'il l'implémente.
  • Calendrier de renouvellement codé en dur, par exemple « renouveler X jours avant l'expiration » ou un intervalle cron fixe : Let's Encrypt recommande de renouveler plutôt à environ ⅔ de la durée de vie du certificat, et propose un moyen de repérer le problème : cherchez avec grep, dans les tâches cron, les scripts d'enveloppe et les procédures d'exploitation, des valeurs codées en dur courantes comme 83, 80 ou 60.
  • Dépendance à la réutilisation des validations : sauf si votre client a été conçu spécifiquement autour de cette réutilisation, rien ne change pour vous.
  • Les limites de débit ne changent pas, pas plus que les points d'accès ACME ou les chaînes de certificats.

Plus le certificat est court, plus un renouvellement raté se fait sentir vite. Let's Encrypt suggère aussi de profiter de l'occasion pour automatiser les rechargements et le déploiement, et pour ajouter des alertes en cas d'échec du renouvellement. Côté Nginx, voir configurer un certificat SSL Let's Encrypt ; si vous émettez des certificats génériques avec la validation DNS (dns-01), la partie DNS est traitée dans faire pointer un domaine vers votre VPS.

Une nouvelle option en vue : Cloudflare veut devenir une autorité de certification publique

Le 29 septembre, Cloudflare a annoncé son intention de devenir une autorité de certification publique. L'entreprise a déposé sa candidature auprès des programmes de racines de Chrome, Apple, Microsoft et Mozilla, et a signé un accord pour acquérir une racine GlobalSign largement reconnue depuis 2012. Elle précise qu'elle n'émet pas encore de certificats. Deux des règles qu'elle a publiées rejoignent ce changement : l'émission passe d'abord par ACME, si bien que quitter une autre autorité gratuite revient à changer une URL de répertoire, et elle n'émettra que pour les clients compatibles ARI. Quelle que soit l'autorité retenue, confier le moment du renouvellement à ARI est la direction à prendre. L'autre garde-fou de l'émission de certificats est l'enregistrement CAA — voir notre article sur les détournements de registres ccTLD.