- 03/06/2026
Certificats SSL : pourquoi leur durée de vie s'effondre à 47 jours d'ici 2029
- Par Maéva MARMIN
- 10 min
- EXPERTISE & ÉDUCATION
Pendant des années, un certificat SSL/TLS pouvait rester valide jusqu'à 398 jours. C'était gérable manuellement, avec une alerte email et un renouvellement annuel. Cette époque est révolue. Apple, Google, Mozilla et Microsoft ont voté à l'unanimité en avril 2025 : d'ici mars 2029, la durée de vie maximale d'un certificat HTTPS sera réduite à 47 jours.
Ce qui ressemble à un détail technique est en réalité un séisme pour toutes les équipes IT qui gèrent encore leurs certificats manuellement. Décryptage de la décision, de ses raisons, et des solutions concrètes pour ne pas se faire rattraper.
Certificat SSL/TLS : Fichier numérique émis par une autorité de certification qui authentifie un site web et chiffre les échanges HTTPS. CA/Browser Forum : Consortium réunissant autorités de certification et éditeurs de navigateurs (Apple, Google, Mozilla, Microsoft) dont les votes définissent les standards SSL/TLS.
Le vote unanime d'avril 2025
Tout a commencé en octobre 2024 lors d'une réunion du CA/Browser Forum. Apple y a présenté le projet de scrutin Ballot SC-081v3, visant à réduire progressivement la durée maximale des certificats SSL publics jusqu'à 47 jours. Le vote s'est clôturé le 11 avril 2025 : aucune voix contre.
Google avait déjà annoncé son intention de limiter les certificats à 90 jours dans son programme "Moving Forward, Together". Apple est allé plus loin et Google a voté pour immédiatement. La première échéance concrète, la réduction à 200 jours, est entrée en vigueur le 15 mars 2026.
Le calendrier officiel des réductions
La réduction se fait en quatre paliers échelonnés sur trois ans. Chaque palier double approximativement la fréquence de renouvellement obligatoire, ce qui suppose d'avoir automatisé ses processus avant chaque échéance. Le texte complet du vote est consultable sur le site officiel du CA/Browser Forum.
Le chiffre de 47 jours n'est pas arbitraire : il correspond à 42 jours (6 semaines) de durée effective, auxquels s'ajoutent 5 jours de fenêtre de renouvellement anticipé.
Pourquoi raccourcir la durée de vie ?
La motivation est avant tout sécuritaire. Un certificat compromis représente un vecteur d'attaque ouvert pendant toute sa durée de validité restante. Réduire cette fenêtre limite mécaniquement le rayon de dommages en cas d'incident.
Si une clé privée est volée, l'attaquant ne peut l'exploiter que pendant le temps de validité restant. Avec 47 jours au lieu de 398, cette fenêtre est réduite de plus de 88 %.
Un certificat mal émis expire naturellement bien plus vite, sans dépendre d'une révocation que les navigateurs ne vérifient pas toujours en temps réel.
Des cycles courts permettront de migrer vers de nouveaux algorithmes sans gérer des certificats "anciens" encore actifs des années après l'obsolescence des standards actuels.
Les mécanismes de révocation (CRL, OCSP) sont rarement vérifiés en temps réel par les navigateurs. Raccourcir la durée de vie est une approche plus robuste : le certificat devient inutilisable naturellement, sans dépendre d'une infrastructure de révocation parfois défaillante.
Les pannes célèbres causées par des certificats expirés
L'expiration de certificats n'est pas un risque théorique. Les plus grandes entreprises du monde en ont fait les frais, avec des équipes IT dédiées et des outils de monitoring en place.
Teams est tombé pendant 3 heures pour des millions d'utilisateurs en plein pic de télétravail Covid. Cause : un certificat d'authentification non renouvelé. Le post-mortem a pointé des lacunes dans le monitoring des certificats d'infrastructure interne.
Un certificat logiciel expiré a provoqué une panne dans plus de 11 pays. Au Royaume-Uni, 32 millions d'abonnés ont perdu leur signal 4G et SMS. Le PDG d'Ericsson a dû s'excuser publiquement.
Un certificat wildcard expiré sur des centaines de services back-end a paralysé les jeux d'Epic. Le certificat a été renouvelé en une heure, mais les effets en cascade ont pris 5h30 à résorber, montrant comment un seul certificat peut provoquer des défaillances systémiques.
Aucune de ces entreprises ne manquait de ressources. Avec des certificats à 47 jours, la probabilité de rater un renouvellement manuel est mécaniquement 8 fois plus élevée qu'avec les 398 jours actuels.
La double contrainte oubliée : certificats et validation de domaine
Presque toutes les communications sur le sujet passent sous silence une seconde contrainte tout aussi décisive : la validation de domaine (DCV). En 2029, deux horloges tourneront en parallèle.
Se préparer : l'automatisation comme seule réponse
Le consensus du secteur est clair : l'automatisation via le protocole ACME (Automated Certificate Management Environment) n'est plus une option. C'est une nécessité opérationnelle non négociable à horizon 2027-2029.
- ~400 renouvellements par an
- Équivalent d'un poste à plein temps
- Risque d'oubli multiplié par 8
- Panne inévitable sans process robuste
- Renouvellements déclenchés automatiquement
- Zéro intervention manuelle nominale
- Compatible 47 jours sans surcoût humain
- Monitoring du déploiement en production
Attention aux intervalles codés en dur. Des configurations "renouveler tous les 60 jours" deviendront obsolètes avec 47 jours. L'approche recommandée est le protocole ARI (ACME Renewal Information), qui laisse la CA calculer dynamiquement la fenêtre de renouvellement.
| Environnement | Outil principal | Point de vigilance |
|---|---|---|
| Kubernetes | cert-manager + ARI | Recharger l'Ingress après rotation du Secret |
| AWS (managé) | ACM (automatique) | EC2 hors périmètre ACM → Certbot + SSM |
| Azure | Key Vault + DevOps Pipeline | App Service : Certbot non persistant |
| CDN / Multi-régions | API CA + webhook | Surveiller la propagation sur les edge nodes |
| Serveurs classiques | Certbot (Let's Encrypt) | Activer ARI, supprimer les cron à intervalle fixe |
Les 3 étapes prioritaires dès maintenant
La prochaine réduction, 100 jours en mars 2027, arrive dans moins d'un an.
Cartographiez tous vos certificats actifs : domaines, sous-domaines, environnements internes. Beaucoup d'organisations découvrent des certificats oubliés sur des services secondaires.
Certbot (Let's Encrypt), cert-manager (Kubernetes), ou une plateforme CLM intégrée. Activez le protocole ARI pour des fenêtres de renouvellement dynamiques.
Distinguez "certificat renouvelé" de "certificat servi en production". Dans les architectures distribuées, ces deux états peuvent diverger sans surveillance externe.
FAQ · Questions fréquentes sur les certificats SSL
Le passage à 200 jours (mars 2026) est-il rétroactif ?
Non — les certificats existants ne sont pas invalidés.
Les certificats émis avant le 15 mars 2026 restent valides jusqu'à leur expiration naturelle. La limite s'applique uniquement aux nouvelles émissions à partir de la date d'entrée en vigueur de chaque palier.
Que se passe-t-il concrètement si un certificat expire ?
Les navigateurs bloquent l'accès immédiatement.
Chrome, Firefox et Safari affichent un écran d'avertissement pleine page. Les API HTTPS rejettent les connexions, les flux OAuth s'effondrent, et les robots des moteurs de recherche peuvent signaler le site comme non sécurisé. Conséquences immédiates : perte de trafic, rupture de confiance, risques de non-conformité (PCI DSS, ISO 27001).
Let's Encrypt est-il déjà compatible avec ces nouvelles règles ?
Oui — Let's Encrypt délivre déjà des certificats de 90 jours.
Les utilisateurs Let's Encrypt sont moins impactés à court terme. En revanche, la réduction du délai DCV à 10 jours en 2029 concernera tout le monde. Let's Encrypt recommande d'utiliser ARI plutôt que des intervalles codés en dur.
Pourquoi 47 jours précisément, et pas 30 ou 60 ?
C'est un équilibre entre sécurité et faisabilité opérationnelle.
Le chiffre correspond à 42 jours (6 semaines) de durée effective + 5 jours de fenêtre de renouvellement anticipé. Six semaines réduit la fenêtre d'exploitation d'un certificat compromis tout en laissant une marge raisonnable pour les systèmes d'automatisation.
Les certificats internes (PKI privée) sont-ils concernés ?
Non — le Ballot SC-081v3 ne concerne que les certificats publics.
Les certificats d'infrastructure interne (PKI privée, VPN, inter-serveurs) ne sont pas directement régis par le CA/Browser Forum. Cela dit, la majorité des experts recommande d'aligner les pratiques internes sur les standards publics.
Certificats SSL à 47 jours :
passez à l'automatisation avant 2027.
D'ici mars 2027, vos certificats devront être renouvelés tous les 100 jours et tous les 47 jours en 2029. La gestion manuelle devient structurellement incompatible avec ces échéances. La mise en place d'une chaîne ACME automatisée, de l'inventaire de vos certificats jusqu'au monitoring du déploiement en production, est la seule réponse viable.
Vous souhaitez en savoir plus sur l'impact de ces changements pour votre infrastructure ?
ÉCHANGER AVEC UN EXPERT
