Certificats Let's Encrypt à 45 jours : ce qui change pour ton serveur

12 octobre 2026 par Benoit

Ou : Comment un certificat devient un abonnement que personne ne peut oublier de renouveler, sauf toi

Let’s Encrypt va diviser par deux la durée de ses certificats : de 90 jours aujourd’hui à 45 jours en février 2028, avec une étape à 64 jours dès le 10 février 2027. L’annonce date de décembre 2025, et le reste du secteur suit le même chemin, puisque autorités de certification et navigateurs ont voté un plafond de 47 jours pour 2029. Pour un serveur dont le renouvellement est vraiment automatique, rien ne change. Pour trois habitudes prises à l’époque des certificats de 90 jours, tout change : le renouvellement à intervalle fixe, l’alerte réglée sur un nombre de jours, et le certificat recopié à la main sur une autre machine. Ces trois-là ne cassent pas tout de suite. Elles cassent un dimanche.

Certificats Let’s Encrypt de 45 jours : calendrier, ARI et ce qui casse

Pourquoi tout le monde raccourcit en même temps

Le mouvement ne vient pas de Let’s Encrypt seul. Le 11 avril 2025, le CA/Browser Forum, qui réunit les autorités de certification et les éditeurs de navigateurs, a adopté un calendrier qui fait passer la durée maximale d’un certificat public de 398 jours à 47 jours, par paliers jusqu’en mars 2029¹. Let’s Encrypt va un peu plus vite et un peu plus loin.

L’argument officiel : limiter la durée pendant laquelle une clé compromise reste utilisable, parce que la révocation, Let’s Encrypt l’écrit lui-même, « is an unreliable system »². Quand une clé fuit, révoquer le certificat suppose que tous les clients aillent vérifier, et beaucoup ne le font pas. Let’s Encrypt en a tiré les conséquences : son service OCSP, qui répondait aux navigateurs demandant si un certificat était encore valide, s’est éteint le 6 août 2025, et la révocation ne passe plus que par des listes publiées³. Un certificat court, c’est une révocation qui arrive toute seule, à date fixe.

Ce que j’ai trouvé sur mon propre serveur

Avant de parler des autres, j’ai regardé le mien, le 12 octobre 2026. Le certificat de ce site vient de Let’s Encrypt, il a été émis le 17 septembre et expire le 16 décembre : 90 jours, le profil par défaut. Il ne contient plus aucune adresse OCSP, seulement l’adresse de la liste de révocation, ce qui confirme que le changement d’août 2025 est déjà passé par là.

Le renouvellement, lui, ne me concerne pas directement : c’est Caddy qui le fait. Sa documentation l’explique sans détour : au lieu d’attendre un nombre de jours fixe, il renouvelle quand il reste environ un tiers de la vie du certificat, et il suit en priorité la fenêtre suggérée par l’autorité si elle en propose une⁴. Sur un certificat de 90 jours, il renouvelle vers le soixantième jour. Sur un certificat de 45 jours, vers le trentième. Je n’ai rien à changer, et c’est exactement ce qui doit arriver.

Si ton serveur ressemble au mien, tu peux t’arrêter ici. Sinon, voici les trois endroits où ça casse.

Premier piège : renouveler à date fixe

Let’s Encrypt l’écrit en toutes lettres dans son annonce : « renewing at a hardcoded interval of 60 days will no longer be sufficient »⁵. Le calcul est vite fait. Une tâche planifiée qui force un renouvellement tous les 60 jours laissait 30 jours de marge à un certificat de 90 jours. Elle en laissera 4 à un certificat de 64 jours. Avec 45 jours, le site sera hors service quinze jours sur soixante.

La correction n’est pas de réduire l’intervalle à 30 jours, ce qui recréerait le même problème au prochain changement. C’est de lancer l’outil souvent, deux fois par jour par exemple, et de le laisser décider. Certbot le fait depuis sa version 4.0, d’avril 2025 : il renouvelle quand il reste un tiers de la durée de vie, au lieu des 30 jours fixes d’avant. Depuis la 4.1, de juin 2025, il interroge en plus l’autorité pour connaître la bonne fenêtre⁶.

Deuxième piège : l’alerte réglée sur un nombre de jours

C’est le piège le plus vicieux, parce qu’il ne casse rien. Beaucoup de supervisions alertent quand un certificat a moins de 30 jours devant lui. Avec des certificats de 90 jours, l’alerte ne se déclenche que si le renouvellement a raté. Avec des certificats de 45 jours, elle se déclenche à partir du quinzième jour de chaque certificat, alors que tout va bien : le renouvellement normal n’arrive qu’au trentième. Une alerte qui sonne la moitié du temps finit en sourdine. Et le jour où le renouvellement échoue vraiment, personne n’écoute plus.

Le filet de sécurité de Let’s Encrypt a disparu en même temps : ses e-mails d’avertissement avant expiration se sont arrêtés le 4 juin 2025⁷. La surveillance est donc ton affaire, et elle doit raisonner en proportion de la vie du certificat, pas en jours. Voici le cœur du petit programme que j’utilise :

1
2
3
4
5
6
7
8

// lifeLeft is the share of the certificate's lifetime that remains, between 0 and 1.
func lifeLeft(notBefore, notAfter, now time.Time) float64 {
	return notAfter.Sub(now).Seconds() / notAfter.Sub(notBefore).Seconds()
}

// A healthy client renews with about a third of the lifetime left.
// Below a sixth, renewal has been failing for a while, whatever the lifetime.
const alertBelow = 1.0 / 6

Le reste du programme ouvre une connexion TLS vers chaque site passé en argument, lit le certificat et applique ce calcul. Le seuil d’un sixième laisse au client la moitié de sa fenêtre normale pour réessayer avant de te réveiller. Le test qui l’accompagne vérifie la seule propriété qui compte : l’alerte dépend de la durée de vie, pas du nombre de jours.

1
2
3
4
5
6

{"90-day cert, 20 days left", 90 * day, 70 * day, false},
{"90-day cert, 10 days left", 90 * day, 80 * day, true},
{"45-day cert, 20 days left", 45 * day, 25 * day, false},
{"45-day cert, 7 days left", 45 * day, 38 * day, true},
{"6-day cert, 2 days left", 6 * day, 4 * day, false},
{"6-day cert, 12 hours left", 6 * day, 6*day - 12*time.Hour, true},

Les six cas passent sous Go 1.27.1, et le programme, lancé le 12 octobre sur ce site, sur letsencrypt.org et sur go.dev, répondait 73 %, 58 % et 76 % de vie restante, sans alerte. La dernière ligne du tableau n’est pas théorique : Let’s Encrypt délivre depuis le 15 janvier 2026, sur demande, des certificats de six jours². Une alerte à 30 jours n’a aucun sens pour eux. Une alerte à un sixième de leur vie, si.

Troisième piège : la copie manuelle et le service jamais rechargé

Le dernier piège ne concerne pas le certificat du site, mais ses copies. Le même certificat recopié à la main sur un répartiteur de charge, un serveur de messagerie ou un boîtier réseau. Ou, plus sournois, renouvelé sur le disque par Certbot, mais servi par un logiciel qui ne relit ses fichiers qu’au démarrage. Le nouveau certificat est là, l’ancien est en mémoire, et il expire en silence.

Avec des certificats de 90 jours renouvelés vers le soixantième jour, ces copies se refaisaient six fois par an, assez rarement pour qu’on s’en charge à la main. Avec 45 jours, il faudra les refaire tous les mois. Chaque copie doit donc avoir son automatisation : un script de déploiement déclenché après le renouvellement, que Certbot sait lancer avec son option --deploy-hook, et un rechargement du service concerné.

Les sept heures qui changent la validation

La dernière colonne du tableau mérite qu’on s’y arrête. Aujourd’hui, une fois ton domaine validé, Let’s Encrypt réutilise cette preuve pendant 30 jours. En février 2028, ce sera 7 heures. En pratique, chaque renouvellement devra prouver à nouveau que tu contrôles le domaine. Pour une validation par HTTP, le serveur doit donc répondre à chaque fois ; pour une validation par DNS, l’outil doit pouvoir écrire dans ta zone à chaque fois, avec des identifiants d’API qui traînent forcément quelque part.

Let’s Encrypt prépare une réponse, une validation DNS « persistante » où l’enregistrement reste en place d’un renouvellement à l’autre. Annoncée pour le deuxième trimestre 2026, elle n’est pas en production : l’équipe a suspendu son déploiement le 25 juin 2026, en attendant que la spécification de l’IETF règle une question de sécurité⁸. D’ici là, chaque renouvellement repasse par la validation complète.

Il y a enfin le mécanisme qui rend tout ça supportable, l’extension ARI, normalisée en juin 2025 dans la RFC 9773⁹. Le client demande à l’autorité quand renouveler, au lieu de le décider seul. L’autorité peut ainsi étaler la charge, et surtout demander un renouvellement anticipé le jour où elle doit révoquer des certificats en masse. Caddy et Certbot l’interrogent déjà. Un script maison qui ignore ARI renouvellera quand même, mais il sera le dernier informé quand ça compte.

DevOps Dave : J’ai lu l’annonce. J’ai changé ma tâche planifiée : renouvellement tous les 30 jours au lieu de 60.

Security Sarah : Et quand on passera à 6 jours ?

DevOps Dave : Je changerai la tâche.

Security Sarah : Tu viens de découvrir pourquoi on raccourcit les certificats. Ce n’est pas pour la sécurité de ton site. C’est pour que plus personne ne puisse renouveler à la main, même par l’intermédiaire d’une tâche planifiée qui fait semblant d’être automatique.

Un certificat de 45 jours n’est pas plus difficile à gérer qu’un certificat de 90 jours. Il est simplement moins indulgent. Avec 90 jours, une automatisation à moitié faite tenait un trimestre avant de casser, et quelqu’un finissait par s’en souvenir. Avec 45 jours, elle tiendra un mois. Et en 2029, avec 47 jours partout, il n’y aura plus de bonne autorité vers qui fuir.

À lire aussi