Certificats Let's Encrypt de 45 jours : calendrier et comment se préparer

Introduction#

Let's Encrypt réduit la durée de validité de ses certificats de 90 à 45 jours. Le changement est déployé progressivement entre 2026 et 2028, et il ne s’agit pas uniquement d’une décision de Let's Encrypt : le CA/Browser Forum a déjà voté pour plafonner à 47 jours tout certificat TLS de confiance publique d’ici mars 2029. Pour les équipes qui gèrent des centaines ou des milliers de domaines, le renouvellement cesse d’être une tâche périodique et devient quelque chose qui doit fonctionner de manière autonome.

Si votre équipe gère encore les renouvellements SSL manuellement, la pression va bientôt se faire sentir. Ce qui représentait quatre cycles de renouvellement par an passera à huit. Ce qui était une tâche trimestrielle maîtrisable devient une charge opérationnelle continue. Le calendrier est déjà lancé, et les équipes d’infrastructure qui se préparent maintenant traverseront la transition en douceur. Celles qui ne le feront pas feront face à un risque accru d’interruption de service et à une surcharge opérationnelle croissante.

Ce guide couvre les dates exactes, ce qui change pour les renouvellements, la comparaison entre l’automatisation ACME et la gestion manuelle des certificats, ainsi qu’une checklist pour les domaines de redirection et les domaines parkés, qui sont les certificats les plus souvent oubliés.

L’annonce : Let's Encrypt passe de certificats de 90 jours à 45 jours#

En décembre 2025, Let's Encrypt a annoncé qu’elle réduira progressivement la durée de validité des certificats de 90 jours à 45 jours, ainsi que la durée pendant laquelle une validation de domaine (autorisation) peut être réutilisée. Les changements s’appliquent aux certificats nouvellement émis, vous verrez donc la durée plus courte lors de votre prochain renouvellement après chaque date.

Let's Encrypt émet des certificats de 90 jours depuis son lancement, à une époque où la plupart des certificats commerciaux duraient un an ou plus. Les durées courtes visaient à pousser tout le monde vers l’automatisation. Le passage à 45 jours poursuit cette logique et s’aligne sur le calendrier sectoriel ci-dessous.

L’impact pratique est simple : chaque domaine protégé par Let's Encrypt devra renouveler son certificat deux fois plus souvent. Pour les organisations qui ont déjà automatisé leur processus de renouvellement, la transition pourra être transparente. Pour les équipes qui s’appuient sur des processus manuels ou des workflows semi-automatisés, l’impact opérationnel sera important.

Pourquoi cela arrive : bonne pratique de sécurité — réduire la fenêtre de compromission#

Des durées de validité plus courtes pour les certificats constituent fondamentalement une amélioration de la sécurité. Chaque certificat TLS représente un vecteur d’attaque potentiel. Si la clé privée d’un certificat est compromise, un attaquant peut usurper l’identité du domaine légitime jusqu’à l’expiration ou la révocation du certificat. Plus la durée de validité du certificat est longue, plus cette fenêtre de compromission reste ouverte.

Les certificats de quarante-cinq jours réduisent cette fenêtre de moitié par rapport à la norme actuelle de 90 jours. Si une clé est compromise le premier jour, l’exposition maximale est de 45 jours au lieu de 90. En pratique, l’exposition est généralement plus courte, mais le plafond compte — surtout pour les organisations qui ne détectent pas immédiatement une compromission.

Il y a aussi un argument lié à la révocation. La révocation des certificats via les CRL et l’OCSP a historiquement été peu fiable. Les navigateurs ne vérifient pas toujours l’état de révocation de manière cohérente, et les certificats révoqués continuent parfois d’être considérés comme dignes de confiance. Des durées de vie plus courtes réduisent la dépendance à l’infrastructure de révocation. Si un certificat ne vit que 45 jours, sa révocation devient moins critique — de toute façon, il expirera bientôt.

La communauté de la sécurité plaide depuis longtemps pour des durées de vie plus courtes des certificats. La décision de Let’s Encrypt concrétise ce que les chercheurs en sécurité recommandent depuis des années.

Ce n’est pas seulement Let’s Encrypt : la règle des 47 jours du CA/Browser Forum#

En 2025, le CA/Browser Forum, l’organisme regroupant les autorités de certification et les éditeurs de navigateurs qui définit les règles des certificats TLS publics, a adopté la proposition SC-081v3. Elle réduit en trois étapes la durée de vie maximale de chaque certificat de confiance publique, pour toutes les CA, y compris DigiCert, Sectigo et GlobalSign, et raccourcit la durée pendant laquelle la validation de domaine peut être réutilisée :

Donc, si vous achetez aujourd’hui des certificats commerciaux d’un an, ils sont déjà plafonnés à 200 jours, et ils suivront la même trajectoire jusqu’à 47 jours. Les durées de vie courtes sont désormais la règle pour l’ensemble du Web, et non plus une particularité d’une seule CA gratuite.

Chronologie de Let’s Encrypt : les dates à retenir#

Chaque changement arrive dans l’environnement de préproduction de Let’s Encrypt environ un mois avant la production, afin que vous puissiez d’abord tester votre configuration avec celui-ci.

La réutilisation des autorisations pendant 7 heures est le changement qui surprend les gens. Aujourd’hui, un domaine validé une fois peut être réémis pendant des semaines sans nouvelle validation. À partir de 2028, presque chaque renouvellement nécessitera une nouvelle validation, donc l’enregistrement DNS ou le défi HTTP devra toujours fonctionner au moment du renouvellement, et pas seulement le jour où vous avez configuré le domaine.

Let's Encrypt propose également un profil de courte durée avec des certificats de 6 jours pour les équipes qui souhaitent aller plus loin.

Le délai pratique est votre calendrier de renouvellement. Let's Encrypt indique qu'un intervalle fixe de renouvellement de 60 jours n'est plus suffisant. Utilisez les informations de renouvellement ACME (ARI) si votre client le prend en charge, ce qui permet à l'autorité de certification de vous indiquer quand renouveler ; sinon, renouvelez à environ les deux tiers de la durée de vie du certificat.

Ce que signifient réellement 45 jours : 8 cycles de renouvellement par an contre 4 actuellement#

Le calcul est simple, mais l'impact opérationnel ne l'est pas. Passer de certificats de 90 jours à 45 jours signifie :

La fréquence de renouvellement double. Au lieu de quatre cycles de renouvellement par an et par domaine, vous en gérez huit. Pour une équipe gérant 100 domaines, cela représente 800 événements de renouvellement par an au lieu de 400. Pour les équipes gérant des milliers de domaines, les chiffres deviennent ingérables sans automatisation complète.

Les fenêtres de renouvellement se réduisent. Avec des certificats de 90 jours, renouveler 30 jours avant l'expiration laisse une marge confortable. Avec des certificats de 45 jours, renouveler aux deux tiers de la durée de vie laisse environ 15 jours pour détecter et corriger une défaillance.

La tolérance aux défaillances diminue. Avec des certificats de 90 jours, un échec de renouvellement vous laisse des semaines pour enquêter et résoudre le problème avant l'expiration. Avec des certificats de 45 jours, vous n'avez que quelques jours. Chaque échec de renouvellement devient plus urgent, et votre surveillance doit être plus réactive.

Le contrôle de débit devient une préoccupation. Let's Encrypt applique des limites de débit sur l'émission des certificats. Doubler la fréquence de renouvellement signifie que vous consommez deux fois plus de budget de limite de débit. Les équipes proches de leurs limites avec des certificats de 90 jours peuvent les atteindre avec des certificats de 45 jours et devront ajuster leurs schémas d'émission.

En bref : les processus de renouvellement manuels ou semi-automatisés qui fonctionnaient à peine avec des délais de 90 jours échoueront à 45 jours. L'automatisation complète n'est plus facultative.

Qui est le plus concerné : les équipes gérant plus de 100 domaines avec des processus SSL manuels#

L’ère des certificats de 45 jours n’affecte pas tout le monde de la même façon. Voici qui ressent l’impact le plus fort :

Les investisseurs en domaines et les gestionnaires de portefeuilles. Les équipes qui gèrent des centaines ou des milliers de domaines stationnés, redirigés ou monétisés font face à la plus grande charge opérationnelle. Chaque domaine a besoin de son propre certificat. À cette échelle, le renouvellement manuel était déjà pénible avec des durées de 90 jours. À 45 jours, ce n’est pas viable.

Les agences qui gèrent les domaines de leurs clients. Les agences numériques gèrent souvent le SSL pour des dizaines ou des centaines de domaines clients. Chaque client peut utiliser une infrastructure différente, des processus de renouvellement différents et des niveaux d’automatisation différents. Le délai de 45 jours amplifie chaque incohérence dans leurs flux de renouvellement.

Les plateformes de commerce électronique avec plusieurs vitrines. Les opérations e-commerce multi-marques utilisent des domaines distincts pour chaque marque, chaque région et chaque campagne. Le nombre de certificats augmente rapidement, tout comme la charge de renouvellement.

Les plateformes SaaS avec des domaines personnalisés. Les produits SaaS qui permettent aux clients d’apporter leurs propres domaines gèrent généralement le provisionnement SSL dans le cadre de l’intégration. Avec des certificats de 45 jours, l’infrastructure de renouvellement doit être irréprochable — l’échec du renouvellement du domaine d’un client signifie que son site affiche un avertissement de sécurité.

Les équipes disposant d’un renouvellement entièrement automatisé basé sur ACME peuvent ne pas ressentir du tout ce changement. La durée de vie du certificat est abstraite par une infrastructure qui renouvelle automatiquement. La ligne de partage, c’est l’automatisation — si votre processus de renouvellement implique qu’une personne consulte un tableau de bord ou exécute un script, vous êtes du mauvais côté.

L’écart de préparation des entreprises#

De nombreuses équipes ont automatisé les certificats il y a des années et n’y ont jamais repensé. Les lacunes apparaissent aux mêmes endroits :

des certificats suivis dans un tableur au lieu d’être surveillés, des scripts de renouvellement qu’il faut déclencher manuellement, des alertes d’expiration envoyées à une boîte de réception que personne ne lit, et des domaines qui ne font que rediriger, si bien que personne ne pense qu’ils ont un certificat.

L’écart de préparation est le plus large dans les organisations qui ont adopté Let’s Encrypt très tôt sans jamais automatiser بالكامل leur chaîne de renouvellement. Elles ont installé Certbot sur quelques serveurs il y a cinq ans, ajouté une tâche cron, et n’ont plus revu la configuration depuis. Ces tâches cron peuvent s’exécuter tous les 60 jours — ce qui ne sera pas assez fréquent pour des certificats de 45 jours.

Faites un audit maintenant, tant que vous avez encore des certificats de 90 jours comme marge de sécurité : listez chaque certificat, vérifiez que chacun se renouvelle automatiquement, et testez ce qui se passe lorsqu’un renouvellement échoue.

ACME contre la gestion manuelle des certificats#

Liste de contrôle pour les domaines de redirection et les domaines parqués#

Les domaines qui redirigent uniquement sont faciles à oublier, mais un visiteur qui saisit https:// a tout de même besoin d’un certificat valide avant que la redirection puisse se faire. Avant les dates de 2027 et 2028 :

1. Dressez la liste de tous les domaines qui redirigent, y compris les anciennes marques, les domaines comportant des fautes de frappe et les domaines de campagne, ainsi que la racine et le www.
2. Pour chacun, notez qui délivre son certificat et comment il est renouvelé. Le « transfert » proposé par le registrar signifie souvent l’absence totale de HTTPS.
3. Vérifiez que chaque client ACME prend en charge l’ARI ou renouvelle aux deux tiers de la durée de vie, et non selon une tâche cron fixe à 60 jours.
4. Assurez-vous que la validation fonctionne toujours au moment du renouvellement : le DNS pointe toujours vers l’endroit où le défi HTTP est traité, ou bien les identifiants du défi DNS fonctionnent toujours.
5. Mettez en place une surveillance des expirations qui alerte un canal partagé, et non la boîte de réception d’une seule personne.
6. Testez avec l’environnement de test de Let’s Encrypt avant chaque changement en production.

Ou retirez complètement les domaines de redirection de votre liste en les transférant vers une plateforme de redirection qui émet et renouvelle le HTTPS pour chaque domaine qu’elle dessert.

Conclusion#

L’ère des certificats de 45 jours arrive, et il ne s’agit pas seulement d’un changement de politique de Let’s Encrypt — c’est une évolution à l’échelle du secteur vers des durées de vie de certificats plus courtes, motivée par les meilleures pratiques de sécurité. Pour les équipes d’entreprise, la ligne de partage entre celles qui ressentent l’impact et celles qui ne le ressentent pas est simple : l’automatisation.

Si votre pipeline de renouvellement SSL est entièrement automatisé via ACME — si les certificats se renouvellent, s’installent et se vérifient sans intervention humaine — vous ne remarquerez peut-être pas du tout ce changement, si ce n’est la mise à jour d’un paramètre de configuration. Si votre processus de renouvellement comporte des étapes manuelles, des tableurs ou des scripts déclenchés par des humains, le délai de 45 jours mettra en évidence chaque faille de votre infrastructure.

Les étapes pratiques sont simples : auditez votre inventaire de certificats, vérifiez la couverture de l’automatisation, testez les scénarios d’échec du renouvellement et assurez-vous que la surveillance détecte les expirations avant que les utilisateurs ne voient des avertissements du navigateur. Les équipes qui le font maintenant — avant que le délai ne se réduise — traverseront la transition sans incident.

Vous gérez des domaines de redirection ? Consultez comment rediriger un domaine en HTTPS sans erreur de certificat.