Résumé
- La durée maximale est de 200 jours dans la période actuelle du CA/Browser Forum, puis de 100 jours à partir de mars 2027 et de 47 jours à partir de mars 2029.
- Un renouvellement n’est achevé que lorsque chaque point de terminaison prévu sert réellement le certificat approuvé et laisse une marge suffisante pour corriger un échec.
Une plateforme centrale peut terminer une commande ACME et afficher un statut vert alors qu’une passerelle régionale ou un serveur de messagerie présente encore l’ancien certificat. L’autorité de certification a bien émis le remplacement ; l’exploitation ne l’a pas fini. Deux réalités coexistent alors : l’état de la commande et l’état du parc.
La réduction des durées rend cet écart plus coûteux. Les exigences actuelles du CA/Browser Forum limitent à 200 jours les certificats d’abonné émis entre le 15 mars 2026 et le 15 mars 2027. Le plafond descend ensuite à 100 jours, puis à 47 jours en 2029. La réutilisation des données de validation de domaine ou d’adresse IP tombe également jusqu’à dix jours en 2029.
Ces plafonds ne sont pas des durées obligatoires. Let’s Encrypt propose déjà, depuis mai 2026, un profil ACME tlsserver de 45 jours pour les utilisateurs qui souhaitent tester le modèle. L’organisation prévoit d’écourter ensuite son profil par défaut et demande aux abonnés de vérifier leur automatisation.
Le certificat plus court accélère toute la chaîne
Chaque cycle exige une identité connue, une méthode de validation disponible, un compte ACME encore maîtrisé, un client capable de commander, un chemin de distribution, un service qui recharge correctement et une observation extérieure du résultat.
La RFC 8555 automatise une grande partie de ce parcours, mais elle rend aussi l’autorité visible. Le client signe les requêtes avec une clé de compte. Dans le périmètre de ce compte, la possession de cette clé peut permettre l’émission, la révocation, la modification du compte et le changement de clé. L’automatisation concentre donc une capacité opérationnelle qui mérite une garde explicite.
L’émission ne connaît pas nécessairement le parc à déployer. Le nouveau certificat peut atteindre le coffre de secrets sans parvenir à tous les reverse proxies, contrôleurs d’entrée, équipements, bords CDN ou services de messagerie. Un processus ancien peut continuer à présenter le prédécesseur. Un point de terminaison oublié peut même manquer à l’inventaire.
Ces situations doivent rester des états distincts. Les fondre dans un seul voyant vert empêche de savoir quelle équipe doit intervenir.
ARI déplace la fenêtre, pas la responsabilité
La RFC 9773 définit ACME Renewal Information. Une autorité compatible peut indiquer une fenêtre de renouvellement recommandée et le client peut préciser quel certificat le nouvel ordre remplace. Ce mécanisme répartit la charge et permet d’avancer un remplacement lors d’une circonstance exceptionnelle.
Il évite aussi de figer une règle devenue absurde. « Renouveler trente jours avant l’expiration » n’a pas le même sens pour une durée de 398 jours et pour une durée de 45 jours. Une fenêtre dynamique sépare le calendrier du code client.
ARI ne prouve pourtant ni l’installation, ni la chaîne servie, ni la couverture de tous les bords, ni la réussite d’une poignée de main depuis Internet. Il coordonne le début de l’opération. La fin reste un état observé du parc.
Le guide d’intégration de Let’s Encrypt recommande donc de consulter ARI au moins deux fois par jour, de conserver un seuil de secours fondé sur la durée restante, de fractionner les très grands parcs et de randomiser les horaires. Son retour de 2026 sur Shopify décrit des fenêtres stockées et interrogées régulièrement. C’est un exemple attribué, non une preuve universelle.
La ressource rare est la marge de reprise
Une durée plus courte limite la période pendant laquelle un identifiant périmé reste accepté. Elle réduit aussi le temps disponible pour découvrir et corriger une validation DNS cassée, une clé de compte inutilisable, une synchronisation de secret incomplète, un rechargement défaillant ou un point de terminaison absent.
La mesure décisive est la marge de reprise : le temps qui subsiste entre le premier échec et l’expiration, après détection, attribution, réparation, nouveau déploiement et vérification indépendante.
Un parc renouvelé tôt, par petits groupes, avec des relances bornées et une preuve extérieure peut absorber la nouvelle cadence. Un parc renouvelé en bloc, qui confond commande et déploiement, peut transformer un contrôle prévu en panne synchronisée.
Les sources publiques ne décrivent aucun parc privé particulier. Elles ne donnent ni inventaire, ni taux d’échec, ni garde des comptes, ni budget de temps. Elles ne prouvent pas non plus que la brièveté remplace la révocation. Elles établissent seulement que la qualité de la preuve de remplacement devient plus importante à mesure que les hypothèses vieillissent plus vite.
Sources
- https://cabforum.org/working-groups/server/baseline-requirements/requirements/
- https://letsencrypt.org/2025/12/02/from-90-to-45
- https://letsencrypt.org/2026/03/17/acme-renewal-information-ari
- https://letsencrypt.org/ca/docs/integration-guide/
- https://www.rfc-editor.org/info/rfc8555/
- https://www.rfc-editor.org/info/rfc9773/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
