Pourquoi les certificats raccourcissent
Le CA/B Forum, l'organisme qui réunit autorités de certification et éditeurs de navigateurs, a adopté en avril 2025 le scrutin SC-081v3. Il organise la réduction progressive de deux durées : la validité des certificats et la période pendant laquelle une validation de domaine peut être réutilisée. Apple, Google, Microsoft et Mozilla ont tous voté pour. L'objectif est double : limiter l'exposition d'une clé compromise ou d'un certificat émis par erreur, et obliger les infrastructures à renouveler souvent, donc à automatiser. Un certificat valable un an est rarement révoqué à temps quand sa clé fuit ; un certificat de six semaines expire de lui-même avant d'avoir causé beaucoup de dégâts. Le secteur suit le mouvement : en 2026, AWS Certificate Manager a ouvert un point d'accès ACME qui délivre des certificats publics de 45 jours. Raccourcir la durée de vie ne réduit la surface d'attaque qu'à une condition : que le renouvellement soit fiable, automatique et surveillé. C'est ce que ce guide met en place.
Les risques concrets du renouvellement manuel
- Expiration silencieuse — un certificat renouvelé à la main dépend d'une alerte calendrier ou d'un rappel humain, deux mécanismes qui échouent régulièrement en période de charge ou lors de changements d'équipe.
- Alertes tardives — les outils de monitoring classiques signalent l'expiration à 30 jours, un seuil conçu pour des certificats d'un an ; sur un certificat de 64 jours, l'alerte tombe alors qu'il a déjà vécu plus de la moitié de sa vie.
- Plus de rappel par e-mail — Let's Encrypt a cessé d'envoyer ses e-mails d'avertissement d'expiration le 4 juin 2025 ; si rien ne surveille vos certificats, plus personne ne vous prévient.
- Paramètres cryptographiques figés — un renouvellement manuel incite à reconduire la même configuration ; l'automatisation impose au contraire une politique de clé appliquée systématiquement.
- Impact sur les engagements de service — une interruption liée à un certificat expiré engage la responsabilité contractuelle et nuit à la réputation de la plateforme.
- Charge opérationnelle croissante — en renouvelant aux deux tiers de la durée de vie, un certificat de 64 jours se renouvelle environ huit fois par an, et une douzaine de fois à 45 jours, sans aucune valeur ajoutée pour les équipes.
Le calendrier du CA/B Forum : 200, 100, puis 47 jours
Les Baseline Requirements fixent la durée maximale d'un certificat serveur public, quelle que soit l'autorité qui l'émet. Depuis le 15 mars 2026, elle est de 200 jours, contre 398 auparavant. Le 15 mars 2027, elle tombera à 100 jours. Le 15 mars 2029, elle atteindra 47 jours. La période pendant laquelle une autorité peut réutiliser une validation de domaine déjà faite suit la même pente : 200 jours, puis 100 jours, puis 10 jours seulement. Cette seconde courbe est la moins commentée et la plus contraignante : elle signifie que votre client ACME devra prouver le contrôle du domaine presque à chaque renouvellement. Si votre validation passe par un enregistrement DNS posé à la main, ou par un port 80 ouvert seulement de temps en temps, c'est elle qui cassera en premier. Les certificats commerciaux achetés aujourd'hui sont déjà plafonnés à 200 jours : le changement n'est pas à venir, il a commencé.
Let's Encrypt passe à 64 jours : les dates qui comptent
Let's Encrypt a annoncé le 7 octobre 2026 un calendrier plus rapide que le plafond réglementaire. Depuis le 14 octobre 2026, son environnement de staging délivre des certificats de 64 jours pour que vous puissiez tester. Le 10 février 2027, tout certificat émis ou renouvelé en production avec le profil par défaut, classic, aura une validité de 64 jours, et la réutilisation des autorisations passera de 30 à 10 jours. Le dernier certificat de 90 jours devrait expirer vers le 11 mai 2027. Le 16 février 2028, le profil par défaut passera à 45 jours, avec une réutilisation des autorisations ramenée à 7 heures. Des profils optionnels existent déjà : tlsserver délivre des certificats de 45 jours, shortlived des certificats d'environ six jours. Let's Encrypt précise que les certificats valides ne seront pas révoqués, que les limites de débit ne changent pas et que les points d'accès ACME comme les chaînes d'émission restent identiques.
Tableau de référence : ce qui change, et quand
Faites défiler le tableau
| Échéance | Changement | Ce que vous devez vérifier |
|---|---|---|
| 15 mars 2026 | Plafond CA/B Forum à 200 jours | Vos certificats commerciaux annuels sont déjà plafonnés |
| 14 octobre 2026 | Staging Let's Encrypt en 64 jours | Votre chaîne de renouvellement passe contre le staging |
| 10 février 2027 | Profil `classic` à 64 jours, autorisations réutilisables 10 jours | Aucun délai codé en dur à 60, 80 ou 83 jours |
| 15 mars 2027 | Plafond CA/B Forum à 100 jours | Renouvellement automatisé chez toutes vos autorités |
| 11 mai 2027 | Expiration attendue du dernier certificat Let's Encrypt de 90 jours | Plus aucun certificat de 90 jours dans l'inventaire |
| 16 février 2028 | Profil `classic` à 45 jours, autorisations réutilisables 7 heures | Validation de domaine réussie à chaque renouvellement |
| 15 mars 2029 | Plafond CA/B Forum à 47 jours, validation réutilisable 10 jours | Supervision de l'expiration sur tout le parc |
Ce qui change dans la logique de renouvellement
La règle à retenir est simple : renouvelez aux deux tiers de la durée de vie, jamais à un nombre fixe de jours. Sur 64 jours, cela donne un renouvellement vers le 43ᵉ jour, avec trois semaines de marge pour corriger une panne. Une tâche cron réglée pour « renouveler tous les 60 jours » ne laisserait que quatre jours de marge, et sur un certificat de 45 jours elle arriverait après l'expiration. Let's Encrypt recommande de chercher dans vos crontabs, scripts et procédures les valeurs codées en dur comme 60, 80 ou 83. Le second levier s'appelle ARI, pour ACME Renewal Information, standardisé par la RFC 9773 : l'autorité indique elle-même à votre client une fenêtre de renouvellement. Si votre client le prend en charge, il suit automatiquement les nouvelles durées, et il renouvelle plus tôt si l'autorité doit révoquer des certificats en masse. C'est la configuration que Let's Encrypt recommande : avec ARI actif, l'annonce des 64 jours ne demande aucune action de votre part.
Checklist d'automatisation, client par client
Inventorier les certificats en place
Recensez chaque certificat actif : domaines couverts, autorité émettrice, date d'expiration, méthode de validation (HTTP-01, DNS-01, TLS-ALPN-01) et client qui le renouvelle.
certbot certificatesliste ceux que gère certbot. Pour les autres,echo | openssl s_client -connect votre-domaine.com:443 -servername votre-domaine.com 2>/dev/null | openssl x509 -noout -issuer -datesaffiche l'émetteur et les dates de validité. Notez aussi les certificats copiés à la main vers un équilibreur de charge, un NAS ou un appareil réseau : ce sont eux qui expirent en silence.Vérifier que votre client parle ARI
certbot prend en charge ARI depuis la version 4.1.0, et
acme.shdepuis la version 3.1.4, où il est actif par défaut. Caddy l'intègre depuis la version 2.8. Vérifiez la version installée aveccertbot --versionouacme.sh --version. Une distribution ancienne peut livrer un certbot antérieur : installez alors le paquet snap recommandé par l'EFF, ou un environnement Python dédié, plutôt que de garder une version qui ignore la fenêtre proposée par l'autorité.certbot : retirer les délais codés en dur
Depuis la version 4.0.0, certbot renouvelle par défaut quand il reste un tiers de la durée de vie, et ARI peut avancer cette date. Ouvrez
/etc/letsencrypt/renewal/votre-domaine.com.confet supprimez une valeurrenew_before_expirytrop courte héritée d'un ancien tutoriel : sans elle, la règle du tiers s'applique. Vérifiez que le planificateur tourne avecsystemctl list-timers | grep certbot. Pour passer dès maintenant à 45 jours, l'option--preferred-profile tlsserverdemande ce profil à l'émission.acme.sh : laisser ARI décider
Depuis la version 3.1.4,
acme.shsuit la fenêtre ARI de l'autorité et sa tâche cron tourne toutes les six heures ;acme.sh --install-cronjobla réinstalle si elle a disparu. Attention au piège inverse : depuis la version 3.1.5, une option--daysou--valid-toexplicite l'emporte sur ARI. Une ancienne commande d'émission avec--days 60imposerait donc un renouvellement au 60ᵉ jour d'un certificat de 64 jours. Retirez-la, puis contrôlez la prochaine échéance prévue avecacme.sh --list.Caddy : vérifier le stockage et les ports
Caddy gère ACME nativement et combine ARI, la durée de vie réelle du certificat et son statut de révocation pour décider du renouvellement : aucune configuration n'est nécessaire pour absorber 64 puis 45 jours. Les deux points à contrôler sont ailleurs. Le répertoire de données de Caddy doit être persistant, sinon chaque recréation du conteneur redemande des certificats et finit par toucher une limite de débit. Et le port 80, ou le port 443 pour TLS-ALPN-01, doit rester joignable depuis Internet pour la validation.
Traefik : ne pas fausser certificatesDuration
Traefik planifie ses renouvellements à partir de l'option
certificatesDuration, exprimée en heures. Sa valeur par défaut,2160(90 jours), déclenche un renouvellement 30 jours avant l'échéance : sur un certificat de 64 jours, cela tombe vers le 34ᵉ jour, avec une marge confortable. Ne copiez pas une valeur trouvée dans un ancien tutoriel : selon la documentation, une durée déclarée entre 7 et 30 jours ne déclenche le renouvellement qu'un jour avant l'échéance. Gardez enfinacme.jsonsur un volume persistant, en mode600.nginx : automatiser le rechargement
nginx ne relit pas un certificat renouvelé tant qu'il n'est pas rechargé : un renouvellement réussi peut donc laisser servir l'ancien certificat jusqu'à son expiration. Avec certbot, placez dans
/etc/letsencrypt/renewal-hooks/deploy/un script exécutable contenantnginx -t && systemctl reload nginx, ou passez--deploy-hook "systemctl reload nginx"à l'émission. Avecacme.sh, l'option--reloadcmd "systemctl reload nginx"de--install-certenregistre la commande pour les renouvellements suivants. NGINX propose aussi un module ACME natif,ngx_http_acme_module.Tester contre le staging
Faites tourner votre chaîne contre l'environnement de staging, qui délivre déjà des certificats de 64 jours et dont les limites de débit sont bien plus larges. Avec certbot,
certbot renew --dry-runpasse par le staging sans toucher à vos certificats ; ce mode n'interroge pas ARI. Pour obtenir un vrai certificat de test, utilisez--test-certsur un domaine non critique. Avecacme.sh, ajoutez--staging. Avec Caddy ou Traefik, pointez l'autorité vershttps://acme-staging-v02.api.letsencrypt.org/directory, puis contrôlez la durée avecopenssl x509 -noout -dates -in cert.pem.Surveiller l'expiration et relier le reste du parc
Un renouvellement automatisé qui échoue sans bruit est pire qu'un renouvellement manuel. Ajoutez un hook de déploiement qui notifie un canal d'alerte à chaque renouvellement réussi, et une sonde indépendante qui mesure chaque jour les jours restants sur le certificat réellement servi. Réglez l'alerte sur une fraction de la durée de vie, par exemple moins d'un quart de validité restante, plutôt qu'à 30 jours fixes. Pour la mise en place initiale sur un VPS, notre guide sur les certificats SSL avec Let's Encrypt détaille HTTP-01, DNS-01 et les wildcards.
Ne présumez jamais qu'une configuration de renouvellement fonctionne sans l'avoir vue fonctionner. Plusieurs semaines avant le 10 février 2027, lancez certbot renew --force-renewal --cert-name votre-domaine.com sur un domaine non critique, puis vérifiez avec openssl s_client que le serveur sert bien le nouveau certificat. Le test coûte quelques minutes et élimine la panne la plus fréquente : un certificat renouvelé sur disque que personne n'a rechargé.
Dépannage : les messages d'erreur les plus fréquents
Timeout during connect (likely firewall problem)— l'autorité n'a pas pu joindre votre serveur sur le port 80 (HTTP-01) ou 443 (TLS-ALPN-01). Vérifiez le pare-feu avecufw status, les règles réseau de l'hébergeur et l'enregistrement AAAA : une adresse IPv6 publiée mais non servie suffit à faire échouer la validation.Invalid response from http://votre-domaine.com/.well-known/acme-challenge/…: 404— le fichier de défi n'est pas servi. Une redirection mal placée, un bloclocationtrop large ou un reverse proxy qui renvoie tout vers l'application en sont la cause habituelle ; exemptez/.well-known/acme-challenge/de ces règles.CAA record for votre-domaine.com prevents issuance— un enregistrement DNS CAA n'autorise pas cette autorité. Ajoutez0 issue "letsencrypt.org"à la zone, ou le nom de l'autorité que vous utilisez réellement.too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s— un script qui force le renouvellement en boucle a atteint la limite de cinq certificats identiques par semaine. Attendez l'heure indiquée aprèsretry afteret faites vos essais en staging.- Le navigateur affiche toujours l'ancienne date d'expiration — le certificat a été renouvelé sur disque, mais le serveur web n'a pas été rechargé. Vérifiez le hook de déploiement, puis comparez
openssl x509 -noout -enddatesur le fichier et sur la connexion réelle.
Pour aller plus loin
Le passage à 64 jours n'est pas un événement à préparer une fois : c'est une marche d'un escalier qui descend jusqu'à 45 jours chez Let's Encrypt et à 47 jours chez toutes les autorités. Une infrastructure qui renouvelle aux deux tiers, écoute ARI, recharge ses services et surveille le certificat réellement servi franchira toutes les marches sans intervention. Si vous démarrez avec Let's Encrypt sur un VPS, notre article sur les certificats SSL avec Let's Encrypt détaille la mise en place initiale et les cas particuliers liés aux wildcards. Pour les nouvelles infrastructures, Caddy mérite une attention particulière : son support natif d'ACME supprime entièrement la couche de gestion des certificats. Enfin, si votre validation repose sur DNS-01, limitez le jeton d'API DNS à la seule zone concernée : avec une validation réutilisable dix jours seulement, ce jeton servira presque à chaque renouvellement.
