L’écosystème des certificats numériques va connaître une transformation profonde dans les prochaines années. Le CA/Browser Forum — l’organisme rassemblant les principales autorités de certification (AC) et les fabricants de navigateurs — a approuvé un plan visant à réduire progressivement la durée maximale de validité des certificats TLS, qui sera limitée à seulement 47 jours à partir de 2029.
Ce changement repose sur une idée simple mais forte : les certificats long-lasting deviennent de moins en moins fiables et, pour garantir la sécurité sur le web, il faut revalider plus fréquemment… et automatiser entièrement leur gestion.
Un changement historique porté par Apple et soutenu par les géants
La proposition de réduire encore la durée de validité des certificats TLS a été présentée par Apple lors du CA/Browser Forum sous le nom de “Ballot SC-81”. Le calendrier prévoit une réduction progressive, culminant en 2029 avec une durée maximale de 47 jours. La votation a été approuvée en avril 2025 après plusieurs mois de débats avec les fabricants de navigateurs et les autorités de certification.
Google, qui préconisait auparavant une limite de 90 jours, a soutenu la proposition d’Apple quasi immédiatement, consolidant un consensus clair parmi les acteurs clés du secteur des navigateurs et des systèmes d’exploitation.
Pour le secteur, le message est sans équivoque : la gestion manuelle du cycle de vie des certificats touche à sa fin.
Calendrier de réduction : de 398 jours à seulement 47
Jusqu’à présent, la durée maximale de validité d’un certificat TLS serveur était de 398 jours. Cela représentait déjà une réduction par rapport aux durées historiques de 3 ou 5 ans. Avec la nouvelle réglementation, le CA/Browser Forum fixe le calendrier suivant :
| Période | Validité maximale du certificat TLS | Réutilisation maximale de la validation de domaine/IP | Réutilisation des données SII (données d’entreprise en OV/EV) |
|---|---|---|---|
| Jusqu’au 15/03/2026 | 398 jours | 398 jours | 825 → 398 jours (limite raccourcie) |
| À partir du 15/03/2026 | 200 jours | 200 jours | 398 jours |
| À partir du 15/03/2027 | 100 jours | 100 jours | 398 jours |
| À partir du 15/03/2029 | 47 jours | 10 jours | 398 jours |
Source : résumé du ballot SC-81 et communications des CAs commerciales.
Concrètement, cela implique qu’à la fin de cette décennie :
- Un certificat TLS ne pourra plus avoir une durée supérieure à 47 jours.
- La validation du contrôle de domaine ou IP (DCV) utilisée par la CA pour émettre le certificat ne pourra être réutilisée que 10 jours.
Autrement dit, toute organisation considérant encore “une seule rénovation annuelle” sera hors-jeu.
Les raisons derrière cette réduction drastique de la durée de vie des certificats
Apple et d’autres promoteurs du changement avancent plusieurs arguments fondamentaux :
- Les informations contenues dans le certificat se démodent rapidement
La propriété ou la gestion d’un domaine, l’infrastructure associée ou encore le responsable du service peuvent évoluer vite. Plus une validation est réutilisée longtemps, plus elle deviendra obsolète. - La révocation n’est pas aussi efficace qu’elle devrait
Les systèmes traditionnels de révocation (CRL et OCSP) sont problématiques : de grosses listes, des défaillances de communication, et de nombreux navigateurs qui ignorent ou atténuent la vérification de révocation pour préserver performance et expérience utilisateur. Réduire la durée de validité limite la fenêtre durant laquelle un certificat compromis peut être accepté. - L’expérience avec des certificats courts est positive
En 2023, le CA/Browser Forum lui-même a amorcé la voie vers des certificats de très courte durée (par exemple, 7 jours) qui ne nécessitent même pas de CRL ou OCSP. Cette expérimentation confirme que certificats plus courts + automatisation avancée fonctionnent mieux que l’approche longue + révocation traditionnelle. - Le marché évolue vers l’automatisation
Des fournisseurs comme Let’s Encrypt ont démontré la faisabilité d’émettre en masse des certificats de 90 jours en utilisant le protocole ACME, rendant la protection plus économique et automatisée pour des millions de sites.
Dans ce contexte, la réduction à 47 jours n’est pas une lubie mais l’aboutissement d’une tendance : certificats de plus en plus courts et gestion toujours plus automatisée.
Le rôle cruciale de l’automatisation : d’une option à une nécessité absolue
Les documents de différentes CAs commerciales reconnaissent que, avec ce calendrier, la gestion manuelle sera rapidement impossible bien avant 2029.
ACME et autres solutions de gestion du cycle de vie
Le standard ACME (Automatic Certificate Management Environment) a été créé pour automatiser l’émission et le renouvellement des certificats, en validant le contrôle du domaine et en déployant de nouvelles clés sans intervention humaine, via des clients comme Certbot, acme.sh ou avec des intégrations dans serveurs web et dispositifs réseau.
En plus des solutions “gratuites” et open source, les grandes autorités de certification ont intégré leurs propres outils d’automatisation :
- Plateformes de gestion du cycle de vie des certificats (CLM) avec inventaire centralisé.
- Intégrations ACME pour certificats DV, OV et même EV, comme proposé par DigiCert via ses solutions d’entreprise.
- APIs dédiées pour déployer et renouveler automatiquement sur des load balancers, proxies TLS, WAFs ou objets connectés IoT.
Ceux qui ne disposent pas encore d’une automatisation de base (déploiement et renouvellement) de leurs certificats sur serveurs ou dispositifs critiques devront s’y atteler, au plus tard avant 2027… voire bien plus tôt.
Impacts pour les entreprises, hébergeurs et administrateurs systèmes
Ce changement ne se limite pas à “programmer un cron pour renouveler”. Il impacte aussi les processus, outils et responsabilités.
1. Inventaire et visibilité
Nombre d’organisations ignorent encore leur parc complet de certificats : sous-domaines oubliés, services internes, API exposées… Avec un cycle de 47 jours, tout certificat mal suivi ou perdu peut entraîner une panne garantie en quelques semaines si aucune plateforme centralisée de gestion n’est en place.
2. Intégration aux infrastructures critiques
La renouvellement automatique sur un serveur web est simple. Le vrai défi concerne :
- Les load balancers et proxies de couche 7
- Les appareils réseaux et firewalls terminant TLS
- Les applications legacy ou appliances où l’importation du certificat reste manuelle
Chacun de ces points doit pouvoir recevoir de nouveaux certificats de façon automatisée (via API, scripts, intégration native ou procédures soigneusement orchestrées).
3. OV/EV et conformité réglementaire
Pour les certificats OV et EV, la réduction de la réutilisation de la SII de 825 à 398 jours n’est pas aussi agressive que pour les domaines, mais nécessite une révision des processus internes de conformité, KYC et gestion documentaire.
Les entreprises émettant de nombreux certificats OV/EV doivent s’assurer que :
- Leur documentation d’entreprise soit toujours à jour.
- Les processus de revalidation avec la CA soient efficaces et, dans la mesure du possible, partiellement automatisés.
4. Culture du “short-lived by design”
Enfin, cette évolution encourage à adopter une conception où tout ce qui concerne les identifiants et crédentiels doit être de courte durée :
- Certificats externes de 47 jours max.
- Tokens, clés API et secrets également renouvelés fréquemment.
- Pipeline CI/CD et déploiements traitant le renouvellement comme un événement standard, non exceptionnel.
Que doivent faire les organisations dès aujourd’hui ?
Même si l’impact maximal intervient en 2029, les premières mesures doivent être prises dès 2026. Voici quelques recommandations clés :
- Auditer tous les certificats existants
- Domaines, sous-domaines, services internes, VPN, APIs, load balancers…
- Responsables et CA émettrice pour chaque certificat.
- Adopter ACME ou solutions équivalentes
- Pour sites publics, commencer par ACME avec une CA adaptée.
- Pour OV/EV, étudier les options d’automatisation offertes par la CA actuelle (ACME entreprise, agents, connecteurs…).
- Centraliser la gestion et la surveillance
- Utiliser une plateforme de gestion du cycle de vie des certificats ou, à minima, un système d’alerte anticipée pour éviter toute expiration inattendue.
- Redéfinir les processus internes
- Intégrer le renouvellement et l’émission dans le cycle classique de gestion des changements.
- Former les équipes développement, sécurité et opérations à cette nouvelle réalité.
- Communiquer avec les CA et fournisseurs
- Découvrir leurs outils d’automatisation (ACME, API, agents).
- Vérifier les contrats et abonnements pour anticiper l’impact des renouvellements fréquents sur les coûts.
Questions fréquentes sur la réduction de la durée de validité des certificats TLS
Comment la nouvelle limite de 47 jours impactera-t-elle une PME avec peu de ressources techniques ?
Même les petites structures seront amenées à abandonner la gestion manuelle annuelle. La bonne nouvelle : des solutions gratuites ou commerciales, basées sur ACME, existent pour automatiser presque totalement l’émission et le renouvellement, limitant ainsi le risque d’expirations inopinées sans nécessiter d’investissements lourds.
Quels outils utiliser pour automatiser le renouvellement des certificats TLS sur serveurs web et équilibrateurs de charge ?
Le protocole ACME est supporté par de nombreux clients (Certbot, acme.sh, Lego, etc.) et par de nombreuses CA, gratuites ou payantes. La majorité des serveurs web, reverse proxies et load balancers récents comprennent déjà des intégrations ou plugins pour communiquer avec une CA via ACME ou API, permettant une automatisation complète.
En quoi la gestion des certificats DV, OV et EV différera-t-elle avec ces nouveaux délais ?
Les certificats DV seront plus impactés par la réduction de la réutilisation de la validation de domaine, ce qui obligera à automatiser totalement le contrôle. Pour OV et EV, en plus de cette validation, les organisations devront maintenir à jour leur documentation d’identité corporate, car l’information SII ne pourra être réutilisée que 398 jours, imposant des contrôles plus fréquents.
Peux-je continuer à utiliser des certificats wildcard avec ces nouveaux délais ?
Oui, à condition que la CA les propose et que les processus de validation soient respectés. La différence : leur durée maximale sera aussi réduite (200, 100 ou 47 jours), ce qui nécessitera leur renouvellement régulier et, par conséquent, leur gestion automatisée, comme l’ensemble des certificats TLS.
Sources :
CA/Browser Forum Ballot SC-81 ; documentation d’Apple et Google sur la réduction de durée ; articles techniques de Digicert et autres fournisseurs sur l’automatisation et ACME ; docs officielles ACME et Let’s Encrypt ; références Wikipédia et portails spécialisés en PKI et TLS.
Typologies de centres de données en 2025 : de l’hyperéchelle à la frontière edge, ce qu’ils construisent, comment ils sont exploités et ce que réclament les projets