Certificats de 47 jours : la feuille de route CA/Browser jusqu'en 2029

Le débat est tranché, et une partie en est déjà la réalité du terrain : depuis le 15 mars 2026, les certificats TLS publiquement reconnus ne peuvent plus dépasser 200 jours de validité, contre 398 auparavant. C’est le premier palier d’une feuille de route que le CA/Browser Forum a adoptée en avril 2025 avec le scrutin SC-081v3 : à l’unanimité, par 29 voix pour et aucune voix contre. Au terme de cette feuille de route, la durée de vie maximale tombera à 47 jours.

Quiconque commande encore ses certificats à la main et les note dans un agenda devrait considérer les trois prochaines années comme un chantier de transformation, et non comme une série d’échéances isolées.

La feuille de route en chiffres

La validité maximale décroît selon des paliers aux dates clairement fixées :

• jusqu’au 14 mars 2026 : 398 jours (l’ancien standard)
• à partir du 15 mars 2026 : 200 jours (en vigueur aujourd’hui)
• à partir du 15 mars 2027 : 100 jours
• à partir du 15 mars 2029 : 47 jours

En parallèle, et c’est la partie la plus exigeante sur le plan opérationnel, la réutilisabilité de la validation de domaine (Domain Control Validation, DCV) se réduit. Une fois le contrôle d’un domaine vérifié, sa « réutilisation » sera désormais possible sur une durée nettement plus courte avant qu’une nouvelle confirmation ne soit requise :

• à partir du 15 mars 2026 : 200 jours
• à partir du 15 mars 2027 : 100 jours
• à partir du 15 mars 2029 : 10 jours

Pour les certificats OV et EV, la réutilisabilité des données d’organisation vérifiées (Subject Identity Information) passe en outre de 825 à 398 jours au 15 mars 2026.

Les 47 jours ne sont donc que le titre accrocheur. Les 10 jours de réutilisation DCV à partir de 2029 sont le véritable rythme imposé : à compter de cette date, il faudra de fait prouver tous les dix jours que le domaine est toujours sous votre contrôle.

Pourquoi cette réduction s’impose

Cette évolution repose sur une logique de sécurité simple. Un certificat est une déclaration de confiance assortie d’une date d’expiration. Plus sa validité est longue, plus une émission erronée, une clé compromise ou un paramètre cryptographique obsolète continue de produire ses effets. Le contre-mécanisme classique, la révocation via CRL et OCSP, fonctionne de manière peu fiable en pratique : les listes de révocation ne sont pas évaluées en temps utile partout, et OCSP est de plus en plus abandonné. Les durées de vie courtes remplacent la révocation par l’expiration. Un problème se résorbe de lui-même, parce que le certificat concerné devient de toute façon bientôt invalide.

Le deuxième moteur est l’agilité cryptographique. En renouvelant régulièrement ses certificats, on peut changer d’algorithmes, de longueurs de clés et de profils en cours d’exploitation : une condition indispensable à la migration imminente vers les procédés post-quantiques. À l’inverse, des durées de vie longues figent le statu quo.

Ce que cela implique pour l’exploitation

La conséquence centrale est aussi banale qu’inéluctable : le renouvellement manuel ne passe plus à l’échelle. Un certificat de 47 jours sera remplacé, avec une marge raisonnable, environ tous les 30 jours. Sur un parc de taille moyenne, ce n’est plus une entrée d’agenda, mais un processus qui doit s’exécuter sans intervention humaine.

Trois capacités déterminent la réussite de cette transformation :

L’automatisation. ACME (RFC 8555) est le standard établi pour l’émission et le renouvellement automatiques, non seulement pour Let’s Encrypt, mais aussi, de plus en plus, pour les CA commerciales et internes. Là où ACME ne s’applique pas, il faut des flux de renouvellement pilotés par API avec validation, afin de préserver les contrôles de conformité.

La découverte. On ne peut automatiser que ce que l’on connaît. La panne typique de 2029 ne sera pas le certificat bien entretenu du système principal, mais celui que l’on a oublié sur un point d’accès d’équilibreur de charge, sur une appliance ou dans un compte cloud que plus personne ne surveille. Les scans réseau actifs et la découverte cloud passive sont la condition pour que des durées de vie courtes ne se transforment pas en pannes à court terme.

La propriété. Chaque certificat doit avoir un responsable clairement désigné, une CA identifiée et une procédure de renouvellement consignée. Un inventaire qui tient ces trois informations par certificat constitue la véritable assurance face à la réalité des 47 jours.

C’est précisément ce schéma, la découverte d’abord, puis l’automatisation indépendante de la CA avec validation, qui sous-tend notre module NextPKI. L’orientation réglementaire en est indépendante : qui rend son parc visible et automatise le renouvellement est prêt, quel que soit l’outil employé.

Ce qui est pertinent dès maintenant

Trois ans, cela peut sembler beaucoup, mais le palier des 200 jours est déjà en cours. Concrètement, il vaut la peine dès maintenant : d’établir un inventaire complet de tous les certificats TLS à travers le réseau, le cloud et les points d’accès ; d’identifier tous les endroits où le renouvellement se fait encore à la main aujourd’hui ; de lancer un pilote de renouvellement automatique basé sur ACME sur des services non critiques ; et de déterminer quels systèmes internes pourront techniquement supporter, d’ici 2029, une revalidation de domaine tous les dix jours.

Les 47 jours n’arrivent ni par surprise ni d’un seul coup. Ils arrivent par paliers, et le premier est déjà là.