Les certificats de 64 jours de Let’s Encrypt remplaceront les certificats de 90 jours pour les nouvelles commandes et les renouvellements par défaut classique profilera les commandes le 10 février 2027. Les hébergeurs web et les agences doivent supprimer les intervalles de renouvellement fixes, confirmer la prise en charge d’ACME Renewal Information, automatiser le déploiement et le rechargement des services, puis tester l’ensemble du processus dans un environnement de préproduction. Les certificats existants ne seront pas révoqués, mais une automatisation fragile pourrait laisser des sites avec des certificats HTTPS expirés.
Quand les certificats de 64 jours de Let’s Encrypt entreront-ils en vigueur ?
Les certificats de 64 jours de Let’s Encrypt entreront en vigueur pour les certificats délivrés ou renouvelés avec le profil ACME classique par défaut le 10 février 2027. Selon l’annonce de Let’s Encrypt du 7 octobre 2026, les certificats existants et valides resteront valides, et l’organisation prévoit que le dernier certificat par défaut de 90 jours expirera le 11 mai 2027.
Selon la même annonce de 2026, la modification en production ne change ni les points de terminaison ACME de Let’s Encrypt ni les chaînes de délivrance des certificats. Un client ACME moderne devrait donc continuer à communiquer avec l’autorité de certification. Le risque opérationnel se situe ailleurs : calendrier des renouvellements, validation des domaines, installation des certificats, rechargement des serveurs web et alertes d’échec.
Let’s Encrypt prévoit une nouvelle réduction le 16 février 2028, lorsque les certificats par défaut classique devraient passer à 45 jours. La période de réutilisation des autorisations sera réduite de 30 jours à 10 jours le 10 février 2027, puis à sept heures le 16 février 2028. Par conséquent, davantage de renouvellements nécessiteront une nouvelle validation du domaine.
Cette évolution dépasse le cadre d’une seule autorité de certification. Les exigences du CA/Browser Forum plafonneront à 47 jours la durée des certificats de souscripteurs approuvés publiquement à partir du 15 mars 2029, tandis que Let’s Encrypt a choisi 45 jours comme objectif. Des durées de validité plus courtes réduisent la période pendant laquelle une clé compromise ou un certificat délivré par erreur reste exploitable, a déclaré Let’s Encrypt en 2026.
Pourquoi les scripts de renouvellement à intervalle fixe peuvent-ils échouer après cette modification ?
Les scripts de renouvellement à intervalle fixe peuvent échouer avec les certificats de 64 jours de Let’s Encrypt lorsqu’ils supposent que chaque certificat dure 90 jours ou attendent 60 jours avant de tenter un renouvellement. Un délai de 60 jours ne laisse que quatre jours de validité en 2027, réduisant fortement le temps disponible pour remédier à un échec de validation, de déploiement ou de rechargement du service.
Le calcul met le danger en évidence. Avec la durée de validité de 90 jours en vigueur en 2026, un renouvellement au 60e jour laisse 30 jours pour intervenir. Avec la durée de 64 jours à partir de 2027, le même calendrier ne laisse que quatre jours. Lorsque les certificats de 45 jours deviendront la valeur par défaut en 2028, un script qui attend 60 jours ne s’exécutera que 15 jours après l’expiration.
En octobre 2026, Let’s Encrypt a expressément conseillé aux responsables de parcs de rechercher dans les tâches cron, les scripts d’encapsulation et les procédures opérationnelles des valeurs codées en dur telles que 83, 80 ou 60 jours. Inspectez également les modèles de gestion de configuration, les valeurs par défaut des panneaux d’hébergement, les minuteurs systemd, les pipelines CI et la documentation copiée d’un client à l’autre. La procédure oubliée est souvent plus dangereuse que l’entrée cron visible.
Un cas particulier mérite de l’attention : une commande de renouvellement peut réussir alors que le site continue de servir l’ancien certificat. Les nouveaux fichiers peuvent avoir été écrits correctement, mais Nginx, Apache, HAProxy ou un autre point de terminaison TLS ne les chargera pas nécessairement sans rechargement réussi. Honnêtement, la surveillance des renouvellements qui ignore le certificat présenté sur le réseau ne constitue que la moitié d’un système de surveillance.
Des faiblesses de sécurité ailleurs peuvent également compliquer la gestion des parcs. Les agences qui gèrent des environnements WordPress devraient considérer l’automatisation des certificats comme une couche supplémentaire, au même titre que la correction de problèmes tels qu’une vulnérabilité d’Elementor susceptible de créer des administrateurs malveillants et la maîtrise des risques liés aux dépendances introduits par le code généré par l’IA.
Comment les clients ACME doivent-ils déterminer le moment du renouvellement ?
Les clients ACME devraient utiliser les informations de renouvellement ACME lorsqu’elles sont prises en charge, car ARI permet à l’autorité de certification de fournir une fenêtre de renouvellement suggérée. Pour les systèmes dépourvus d’ARI, les recommandations de Let’s Encrypt d’octobre 2026 préconisent un renouvellement aux alentours des deux tiers de la durée de validité réelle de chaque certificat, plutôt qu’un nombre fixe de jours avant l’expiration.
Les informations de renouvellement ACME constituent un mécanisme ACME qui permet à une autorité de certification d’indiquer à un client quand renouveler un certificat donné. ARI est devenu une norme IETF RFC 9773 suivant une procédure de normalisation en juin 2025. Il remplace les estimations fondées sur une durée supposée par un calendrier fourni par le serveur, capable de répartir la demande et d’accompagner l’évolution des politiques de certification.
Pour un certificat de 64 jours en 2027, la règle des deux tiers situe la tentative de renouvellement vers le 42,7e jour, laissant environ 21,3 jours avant l’expiration. Pour un certificat de 45 jours en 2028, la même règle donne le 30e jour et laisse 15 jours. Ces fenêtres offrent bien plus de temps pour intervenir qu’une tâche fixe exécutée au 60e jour.
| Profil ou période du certificat | Durée de validité | Moment du renouvellement aux deux tiers | Validité restante |
|---|---|---|---|
| Profil classique par défaut avant le 10 février 2027 | 90 jours | 60e jour | 30 jours |
| Profil classique par défaut à partir du 10 février 2027 | 64 jours | Environ le 43e jour | Environ 21 jours |
| Profil classique par défaut prévu à partir du 16 février 2028 | 45 jours | 30e jour | 15 jours |
| Profil shortlived opt-in documenté en septembre 2026 | Environ 160 heures | Environ 107 heures | Environ 53 heures |
Vérifiez séparément chaque version de client ACME et chaque panneau de contrôle d’hébergement. La présence d’un client moderne sur l’ordinateur d’un administrateur ne prouve pas qu’une ancienne image serveur, une appliance ou une intégration de panneau prend en charge ARI. Demandez aux fournisseurs la version exacte qui implémente RFC 9773, puis vérifiez le comportement dans les journaux plutôt que de vous fier à une case cochée.
Certbot gère-t-il la réduction de la durée de validité des certificats ?
Certbot 4.0.0 et les versions ultérieures utilisent un calendrier de renouvellement proportionnel adapté aux certificats de 64 jours de Let’s Encrypt. Selon la documentation de Certbot disponible le 13 octobre 2026, Certbot considère qu’un certificat est prêt à être renouvelé lorsqu’il reste moins d’un tiers de sa durée de validité ; les certificats d’une durée inférieure ou égale à 10 jours utilisent un seuil correspondant à la moitié de leur durée de validité.
Vous pouvez exécuter certbot renew fréquemment, car la commande vérifie l’éligibilité avant de demander un certificat. Certbot prend également en charge les pré-hooks, les post-hooks et les deploy-hooks, tandis que --dry-run effectue un test de renouvellement basé sur l’environnement de staging. Un deploy-hook est l’emplacement approprié pour les actions qui ne doivent avoir lieu qu’après un renouvellement réussi, comme le rechargement de Nginx.
Ne supposez pas que toutes les installations de Certbot sont automatiques. Les certificats créés avec le --manual plugin ne seront pas renouvelés sans intervention si des hooks d’authentification automatisés n’ont pas été configurés, selon la documentation 2026 de Certbot. Les défis DNS sont particulièrement susceptibles de comporter des étapes manuelles cachées lorsqu’un fournisseur ne dispose pas d’une intégration API ou lorsque les identifiants ont expiré.
Examinez également les limites de privilèges. Les tâches de renouvellement peuvent nécessiter l’accès aux jetons d’API DNS, aux répertoires de certificats et aux commandes de rechargement, mais des identifiants trop larges augmentent l’impact d’un hôte compromis. Le même principe s’applique aux menaces plus vastes visant les infrastructures, notamment au ciblage des hôtes Docker par le botnet Carbonato: les identifiants d’automatisation doivent disposer d’autorisations limitées et faire l’objet d’une surveillance active.
Liste de contrôle pour une migration sûre des parcs d’hébergement
Une migration sûre vers les certificats Let’s Encrypt de 64 jours doit tester la découverte, la validation, l’émission, le déploiement, le rechargement des services et la vérification externe dans le cadre d’un même processus. Let’s Encrypt prévoit de faire passer son environnement de staging aux certificats par défaut de 64 jours le 14 octobre 2026, ce qui laisse aux équipes d’hébergement le temps de tester avant la transition en production du 10 février 2027.
Utilisez la séquence suivante sur un échantillon représentatif avant d’étendre le test à tous les sites clients :
- Inventoriez les chemins d’accès aux certificats et leurs propriétaires. En 2026, consignez chaque nom d’hôte, client ACME et version, profil, type de défi, fournisseur DNS, chemin d’installation, point de terminaison TLS et équipe responsable.
- Repérez les hypothèses de calendrier fixes. Recherchez dans les scripts, les tâches cron, les minuteurs systemd, les paramètres des panneaux de contrôle et les procédures opérationnelles les calculs fondés sur 90 jours ainsi que les valeurs telles que 83, 80 ou 60 jours identifiées par Let’s Encrypt en 2026.
- Confirmez ARI ou le renouvellement proportionnel. Vérifiez la prise en charge de la RFC 9773 dans la documentation et les journaux du client. Lorsque ARI n’est pas disponible, calculez le déclenchement à partir de la durée de vie réelle du certificat.
- Testez avec l’environnement de staging. Exécutez l’intégralité du processus de validation et de déploiement après le 14 octobre 2026. Les certificats de staging de Let’s Encrypt ne sont pas approuvés publiquement et utilisent des limites de débit distinctes et plus élevées, destinées aux tests et au débogage.
- Testez les hooks de déploiement. Vérifiez les autorisations des fichiers, l’emplacement de la chaîne de certificats et la réussite des rechargements pour Nginx, Apache, HAProxy, les serveurs de messagerie, les équilibreurs de charge ainsi que tout CDN ou proxy sous votre contrôle.
- Vérifiez depuis l’extérieur de l’hôte. Connectez-vous à chaque nom d’hôte public et inspectez le certificat effectivement fourni, notamment sa date d’expiration, son émetteur et ses noms alternatifs de sujet. Les fichiers locaux ne suffisent pas à prouver le déploiement.
- Configurez des alertes en prévoyant suffisamment de temps pour la récupération. Surveillez les tâches de renouvellement ayant échoué et l’expiration des certificats fournis. Acheminez les alertes vers un canal surveillé, attribuez les responsabilités et testez l’escalade avant le 10 février 2027.
Commencez par les sites complexes, et non par les plus simples : certificats génériques, DNS à horizon partagé, proxies multirégionaux, défis DNS manuels et serveurs comportant plusieurs couches de terminaison TLS. À l’échelle d’un parc, les tests par échantillonnage ne suffisent pas si les configurations des clients diffèrent. Un site situé derrière un équilibreur de charge peut réussir une vérification locale tandis qu’un backend ou un emplacement périphérique continue de fournir des données obsolètes.
Les limites de débit ne doivent pas justifier le report de ces travaux. Let’s Encrypt a déclaré le 24 février 2026 que les renouvellements restent exemptés des limites de débit d’émission ; des durées de vie plus courtes ne nécessitent donc pas d’augmenter les quotas de débit des abonnés. L’environnement de staging reste l’endroit le plus sûr pour les débogages répétés, car ses certificats ne sont pas approuvés et ses limites sont conçues pour les tests.
Questions fréquemment posées
Les certificats Let’s Encrypt existants de 90 jours seront-ils révoqués ?
Les certificats Let’s Encrypt existants de 90 jours ne seront pas révoqués uniquement en raison de la transition de 2027 sur la durée de vie, selon l’annonce de Let’s Encrypt du 7 octobre 2026. Let’s Encrypt s’attend à ce que le dernier certificat de 90 jours du profil par défaut expire le 11 mai 2027.
Les URL ACME de Let’s Encrypt changeront-elles en février 2027 ?
Les points de terminaison ACME et les chaînes d’émission de Let’s Encrypt ne changeront pas dans le cadre du passage, le 10 février 2027, aux certificats par défaut de 64 jours, selon l’avis opérationnel 2026 de l’autorité de certification.
Quelle est la durée de validité des certificats à courte durée de vie de Let’s Encrypt ?
Let’s Encrypt a indiqué que le profil avec activation volontaire shortlived a une durée d’environ 160 heures, soit environ 6,7 jours, le 8 septembre 2026. Le profil avec activation volontaire tlsserver fournit des certificats de 45 jours.
Puis-je utiliser un certificat de staging de Let’s Encrypt sur un site web public ?
Les certificats de staging de Let’s Encrypt ne sont pas approuvés publiquement, selon le glossaire 2026 de l’organisation. Utilisez l’environnement de staging pour tester l’émission, la validation, le déploiement et l’automatisation des rechargements, puis rétablissez le client ACME dans l’environnement de production afin d’obtenir un certificat approuvé par les navigateurs.