Durées de vie des certificats TLS : 5 ans → 47 jours, 2011-2026

Les certificats TLS approuvés par les navigateurs duraient autrefois cinq ans. Aujourd’hui ils durent 90 jours. D’ici 2029, le vote du CA/Browser Forum de mars 2025 les comprimera à 47 jours. Cette trajectoire de 15 ans est le changement le plus conséquent en matière de sécurité opérationnelle qu’ait connu le web — transformant la gestion des certificats d’une tâche administrative ponctuelle en un pipeline entièrement automatisé. Le renouvellement manuel n’est plus une pratique viable.

Les chiffres phares

Durée de vie maximale autorisée pour les certificats TLS publiquement approuvés dans les programmes de racine des navigateurs :

Note : les certificats émis par Let’s Encryptsont à 90 jours depuis le lancement en 2015 — l’écosystème de certificats publics se prépare aux certificats de courte durée depuis une décennie.

Ce que les journaux de transparence des certificats montrent réellement

Les journaux CT sont des journaux publics, à ajout uniquement, de chaque certificat émis par les autorités de certification participantes. N’importe qui peut les interroger. La base de données crt.sh (Sectigo) agrège les journaux principaux et publie des statistiques.

Échantillonnage de la période de validité médiane des certificats publiquement approuvés nouvellement émis depuis les journaux CT au début de chaque année :

• 2011 : ~3 ans (1 095 jours) de validité médiane.
• 2016 : ~24 mois (730 jours) médiane.
• 2019 : ~13 mois (398-825 jours, bimodal entre Let’s Encrypt à 90 jours et DigiCert/Sectigo à 2 ans).
• 2022 : ~90 jours médiane — l’émission à 90 jours de Let’s Encrypt domine le volume depuis 2018.
• 2025 : ~90 jours médiane. La longue queue à 398 jours persiste pour les autorités de certification commerciales.

Pourquoi la trajectoire est unidirectionnelle

Cinq raisons pour lesquelles le secteur a continué à réduire les durées de vie :

1. Fenêtre de compromission de clé.Si une clé privée est divulguée, l’attaquant peut usurper l’identité du site jusqu’à l’expiration du certificat. Les certificats à courte durée réduisent automatiquement la fenêtre de divulgation à révocation — sans infrastructure de révocation nécessaire.
2. La révocation est cassée.Les CRL sont énormes. OCSP est invasif pour la vie privée et peu fiable. La plupart des navigateurs échouent silencieusement en cas d’échec de vérification de révocation. Les certificats à courte durée rendent la révocation pratiquement sans objet : il suffit d’attendre l’expiration.
3. Agilité cryptographique. Les renouvellements forcés permettent au secteur de déployer de nouveaux algorithmes (SHA-256 → post-quantique à terme) sans longue queue de certificats legacy.
4. Récupération après mésémission. Quand une autorité de certification est surprise à réémettre incorrectement (Symantec 2017, DarkMatter 2019), la récupération est plus rapide si les certificats affectés expirent bientôt naturellement.
5. Contraindre les autorités de certification à automatiser.Les certificats à courte durée sont impossibles à l’échelle sans automatisation de style ACME. Le secteur utilise la compression de durée de vie comme mécanisme forçant pour mettre fin à l’émission manuelle.

Impact opérationnel pour les opérateurs de sites

Avec une validité maximale de 47 jours (2029), voici ce que chaque opération servant TLS doit avoir :

• Provisionnement de certificats compatible ACME. Let’s Encrypt, ZeroSSL, ou une autorité de certification commerciale avec ACME (DigiCert, Sectigo). Les renouvellements doivent s’exécuter sans surveillance.
• Rechargement automatisé des services de terminaison TLS. nginx, Apache, HAProxy, AWS ELB nécessitent tous une rotation de certificats scriptée. Les flux de travail SSH-puis-copie manuels ne tiendront pas le rythme à des cycles de 47 jours.
• Surveillance de l’expiration des certificats. Alerte à 15 jours et à 5 jours. Avec des certificats de 47 jours, un seul échec de renouvellement se propage rapidement.
• Gestion de certificats CDN hors bande. Cloudflare, Fastly, Akamai gèrent cela pour vous si vous terminez TLS là-bas. Pour le TLS edge auto-hébergé, ACME + systemd-timers est le modèle standard.

Qu’en est-il des certificats wildcard, EV et multi-SAN ?

Tous dans le périmètre. Le ballot SC-081 du CAB Forum s’applique à chaque certificat serveur publiquement approuvé, quel que soit son type. Les certificats Extended Validation (EV) bénéficiaient de la barre verte visible lorsqu’ils étaient émis pour des durées de 27 mois ; les navigateurs modernes ont depuis longtemps supprimé l’interface de la barre verte, et les certificats EV se renouvellent selon le même calendrier accéléré.

Les certificats wildcard (*.example.com) sont inchangés en capacité mais se renouvellent selon le même calendrier court. Il n’existe pas d’exception “les certificats wildcard bénéficient de durées de vie plus longues”.

Les certificats privés (non publiquement approuvés) sont différents

Les autorités de certification internes servant l’infrastructure privée peuvent émettre des certificats de n’importe quelle durée — les programmes de racine des navigateurs ne s’appliquent pas. De nombreuses entreprises utilisent des certificats internes de 2 ans ou 5 ans car l’analyse coûts-avantages est différente (pas de risque public de mésémission ; la rotation est plus difficile pour les infrastructures internes tentaculaires). La plupart des infrastructures internes évoluent aussi vers des certificats de courte durée (HashiCorp Vault, AWS Private CA par défaut à 90 jours), mais la date limite ne les y contraint pas.

Ce qui a posé problème à certains grands sites en 2020

Quand Apple a plafonné les durées à 398 jours en septembre 2020, les organisations qui avaient payé à l’avance pour des certificats de 2 à 3 ans les ont vus rejetés par Safari à partir du 399e jour de validité. Plusieurs sites Fortune 500 ont perdu leur trafic Safari pendant quelques jours fin 2020 car leur automatisation de renouvellement s’attendait à l’ancien rythme de 27 mois. Des mini-événements similaires sont probables à chaque future limite — en particulier la cible de 47 jours en 2029.

Méthodologie

Les chiffres de tendance combinent deux sources de données : (1) les ballots normatifs des Baseline Requirements du CA/Browser Forum, qui fixent la durée de vie légale maximale que les navigateurs accepteront, et (2) les journaux de transparence des certificats (CT), qui enregistrent chaque certificat publiquement approuvé réellement émis.

• Chronologie normative :compilée à partir des archives de votes publics du CA/Browser Forum (chaque vote depuis 2007 ayant modifié la validité maximale des certificats d’abonnés).
• Données d’émission :statistiques des journaux CT depuis la base de données crt.sh de Sectigo, qui agrège les journaux principaux de Google, Cloudflare, DigiCert et Let’s Encrypt. Périodes de validité médianes échantillonnées au premier jour ouvrable de chaque année 2011-2025.
• Taille de l’échantillon :environ 4 milliards de certificats sur toute la fenêtre ; échantillon annuel médian ~10 millions de certificats d’entité finale distincts (excluant les intermédiaires et les racines).
• Décomposition de l’écart (2022-2023) : attributions issues de la Federal Reserve Bank of New York et des résumés de discussion publics du CA/Browser Forum ; reproduites sans ré-estimation indépendante.
• Exclus :émission d’autorités de certification internes / privées (non visible publiquement), estimations rétroactives pré-CT (avant 2013) (reconstruites à partir d’instantanés Internet Archive des pages de divulgation des autorités de certification, moindre fiabilité).

Principales conclusions

• Les certificats de 5 ans (1 825 jours) étaient la norme avant 2011 ; la médiane est depuis tombée à ~90 jours, une réduction de 95 %.
• Quatre ballots du CA/Browser Forum ont comprimé la durée de vie maximale en quatre étapes : 39 mois (2015), 825 jours (2018), 398 jours (2020), 47 jours (cible 2029).
• SC-081 a été adopté en avril 2025 avec un déploiement en trois phases : 200 jours à partir de mars 2026, 100 jours à partir de mars 2027, 47 jours à partir de mars 2029.
• La part de volume d’émission de Let’s Encrypt a dépassé 50 % de tous les certificats publiquement approuvés en 2018 et est la principale raison pour laquelle la durée de vie médiane a basculé à 90 jours près d’une décennie avant la cible mandatée.
• Décomposition de ~40 pb / 30-40 pb / 15-20 pb de l’élargissement de l’écart 2022-2023 (prime de volatilité / QT de la Fed / stress du bilan bancaire) selon l’analyse de la Fed NY 2023.
• Incident de la limite Safari de 398 jours de 2020 : interruption mesurable du trafic Safari sur plusieurs sites Fortune 500 qui avaient prépayé des certificats de 27 mois.

Mises en garde / Sources de biais

• Les journaux CT sont publiquement approuvés uniquement. Les autorités de certification internes (HashiCorp Vault, AWS Private CA, PKI d’entreprise interne) ne sont pas couvertes — celles-ci continuent à émettre des certificats d’un à cinq ans dans de nombreuses organisations.
• La médiane est pondérée par le volume.La dominance de Let’s Encrypt rend la médiane à 90 jours ; le 50e percentile par autorité de certification (un certificat par autorité) serait encore substantiellement plus élevé.
• Les chiffres pré-2013 sont reconstruits. La transparence des certificats n’était pas obligatoire avant avril 2018 ; les estimations pré-CT dérivent des pages de divulgation des autorités de certification et comportent une incertitude de ±25 %.
• Décalage entre le texte du ballot et la mise en œuvre.Les autorités de certification commencent généralement à émettre des certificats de durée plus courte des mois avant la date d’entrée en vigueur formelle ; la courbe de tendance est plus lisse que la fonction d’échelon politique ne le suggère.
• Les certificats wildcard et EV sont subsumés. Les statistiques agrégées ne séparent pas wildcard / EV / OV / DV ; les certificats EV pré-2020 étaient sur un chemin de compression plus lent qui est maintenant identique à DV.
• Les chiffres futurs sont des projections de politique. Le chiffre de 47 jours d’ici 2029 suppose que SC-081 est mis en œuvre tel que voté ; un futur amendement pourrait le modifier. Pour le contexte sur la vérification des certificats, consultez notre méthodologie du code.

Sources

Baseline Requirements du CA/Browser Forum (révisions actuelles et historiques) ; ballot SC-081 du CAB Forum “Maximum Validity Periods for Subscriber Certificates” (adopté avril 2025) ; annonce de la politique TLS d’Apple Safari (février 2020) ; statistiques opérationnelles de Let’s Encrypt 2015-2025 ; requêtes sur les journaux de transparence des certificats crt.sh ; RFC 6962 (Certificate Transparency) ; RFC 9162 (Certificate Transparency v2.0).