La durée de vie des certificats TLS publics tombe à 47 jours d'ici mars 2029. On en parle comme d'un sujet de renouvellement. C'est une erreur : le vrai goulot d'étranglement, c'est la validation de domaine (DCV) — et sa fenêtre de réutilisation tombe, elle, à 10 jours. Voici le calendrier exact, les calculs, et la méthode pour automatiser sans casser un seul service.
Le calendrier officiel : de 398 à 47 jours
Le CA/Browser Forum a acté la réduction. Elle est progressive, ce qui vous laisse une fenêtre pour vous préparer — pas pour attendre.
| Date | Durée max. du certificat | Réutilisation de la validation de domaine (DCV) |
|---|---|---|
| Aujourd'hui | 398 jours | 398 jours |
| 15 mars 2026 | 200 jours | 200 jours |
| 15 mars 2027 | 100 jours | 100 jours |
| 15 mars 2029 | 47 jours | 10 jours |
Deux paramètres baissent, pas un seul. La durée du certificat et la durée pendant laquelle une preuve de contrôle de domaine reste valable. C'est ce second point que la plupart des guides oublient — et c'est celui qui fait le plus mal.
Pourquoi c'est un problème d'exploitation, pas de sécurité
Un certificat plus court n'est pas « plus dangereux ». Le risque se déplace : il passe de la cryptographie vers l'exploitation.
Faisons le calcul pour un parc modeste de 500 certificats :
- Aujourd'hui (~398 jours) : environ 460 renouvellements par an.
- À 47 jours :
500 × (365 / 47) ≈3 900 renouvellements par an.
Soit 8 à 9 fois plus d'opérations, chacune avec sa fenêtre d'erreur. Or la cause n°1 des interruptions de service liées aux certificats n'est pas une faille cryptographique — c'est une expiration non anticipée. Multiplier les renouvellements par 8 sans automatisation, c'est multiplier mécaniquement le risque de panne.
La gestion manuelle — un tableur, un rappel dans l'agenda, un ticket — devient tout simplement insoutenable bien avant 2029.
Le vrai goulot : la validation de domaine (DCV)
Émettre un certificat TLS public suppose de prouver que vous contrôlez le domaine. C'est la DCV (Domain Control Validation), réalisée typiquement par :
- DNS-01 : publier un enregistrement TXT dans la zone DNS du domaine.
- HTTP-01 : exposer un fichier à une URL précise du domaine.
Tant que la réutilisation de la DCV était de ~398 jours, on validait une fois et on n'y pensait plus pendant un an. À partir de mars 2029, la preuve de contrôle n'est valable que 10 jours. Autrement dit : sur un certificat de 47 jours, vous devrez re-prouver le contrôle du domaine plusieurs fois par cycle.
Une DCV manuelle — poser un TXT à la main, attendre la propagation, vérifier — ne passe pas à cette échelle. L'automatisation de la validation de domaine devient le point critique de toute la chaîne.
Les trois piliers d'une automatisation qui tient
Automatiser « le renouvellement » ne suffit pas. Il faut les trois étages, sinon la chaîne casse au maillon manquant.
- Inventaire & découverte. On n'automatise que ce qu'on voit. Un inventaire centralisé de tous les certificats — par CN, autorité, algorithme, date d'expiration, propriétaire — est le prérequis. Les pannes viennent presque toujours d'un certificat que personne ne surveillait.
- Émission & renouvellement automatisés. Via des protocoles standards : ACME (RFC 8555) pour le web, EST (RFC 7030) et SCEP pour les équipements et l'IoT, CMP pour l'industriel, ou une API REST. Le renouvellement doit se déclencher avant l'expiration, sans intervention humaine.
- Validation de domaine automatique et pré-validée. C'est le pilier que tout le monde sous-estime. Il ne suffit pas de valider au moment du renouvellement : il faut maintenir le domaine « prêt à émettre » en permanence, en re-validant en continu avant que la fenêtre de 10 jours n'expire.
Automatiser la DCV : DNS-01, multi-fournisseurs, pré-validation
DNS-01 plutôt que HTTP-01, quand c'est possible
Le challenge DNS-01 est généralement le meilleur choix pour un parc :
- il couvre les certificats wildcard (
*.exemple.com), impossibles en HTTP-01 ; - il n'expose aucun service web (pas de fichier à publier sur chaque serveur) ;
- il se pilote entièrement par l'API du fournisseur DNS.
Sa contrepartie : il faut un connecteur pour chaque fournisseur DNS de votre parc.
Le multi-fournisseurs DNS n'est pas optionnel
Peu d'organisations ont un seul DNS. Entre OVH, Azure DNS, Cloudflare, Google Cloud DNS, Gandi et les zones internes, une automatisation DCV crédible doit parler toutes ces API — sinon les domaines orphelins retombent en gestion manuelle, et c'est exactement là que la panne arrivera.
Pré-valider, ne pas valider dans l'urgence
La bonne architecture ne valide pas au moment du renouvellement (où une erreur de propagation DNS bloque l'émission). Elle pré-valide en continu : un worker vérifie et rafraîchit la preuve de contrôle avant l'expiration de la fenêtre DCV, de sorte que le renouvellement effectif soit instantané et sans risque. C'est la différence entre « ça marche en démo » et « ça tient sur 3 900 renouvellements par an ».
Checklist de préparation (à démarrer maintenant)
- Inventorier tout le parc (y compris les certificats hors CA publique et les wildcard).
- Identifier les propriétaires de chaque domaine et chaque certificat.
- Cartographier vos fournisseurs DNS et vérifier que chacun est couvert par un connecteur DCV.
- Choisir la méthode DCV par domaine (DNS-01 par défaut, HTTP-01 en secours).
- Mettre en place le renouvellement automatique (ACME/EST/SCEP/CMP/API) avec un seuil déclenché bien avant l'expiration.
- Activer la pré-validation continue pour absorber la future fenêtre DCV de 10 jours.
- Brancher supervision et alertes sur les échecs de validation et les expirations approchant.
Faites-le sur la marche à 200 jours (mars 2026), pas à 47 : chaque palier réduit votre marge de manœuvre.
Où se place PKIFactor
PKIFactor est un CLM souverain conçu pour exactement ce problème. Il pré-valide vos domaines en continu et automatise la DCV en DNS-01 et HTTP sur OVH, Azure, Cloudflare, GCP et Gandi, avec un connecteur générique en secours. Le renouvellement est piloté nativement en ACME, EST, SCEP et CMP, sur toutes vos autorités existantes (Vault, ADCS, EJBCA, DigiCert, ZetaCA) derrière une console unique — sans migration. Et comme l'échéance de 47 jours arrive en même temps que la transition post-quantique, la même plateforme émet aussi en ML-DSA et hybride : voyez notre guide hybride vs composite pour DSI et l'avis de l'ANSSI sur la migration.
Vous voulez savoir où en est votre parc aujourd'hui ? L'outil gratuit audit.zetacert.com analyse la santé cryptographique de vos certificats, sans compte.
FAQ
Quand la limite de 47 jours entre-t-elle réellement en vigueur ?
Le 15 mars 2029. Mais la baisse commence dès le 15 mars 2026 (200 jours), puis 100 jours en 2027. Il faut se préparer sur ces paliers, pas attendre 2029.
Qui est concerné ?
Tous les émetteurs de certificats TLS publics (serveurs web, API, load balancers exposés). Les PKI internes ne sont pas soumises au CA/B Forum, mais adoptent souvent les mêmes bonnes pratiques.
ACME suffit-il ?
ACME automatise l'émission et une partie de la DCV, et c'est un excellent point de départ. Mais il ne couvre ni l'inventaire multi-CA, ni la pré-validation anticipée, ni les parcs multi-fournisseurs DNS hétérogènes — c'est le rôle d'un CLM.
Et les certificats wildcard ?
Ils imposent la validation DNS-01 : raison de plus pour automatiser la DCV via l'API de vos fournisseurs DNS.
La réduction concerne-t-elle aussi la validation d'organisation (OV) ?
Le paramètre le plus contraignant est la réutilisation de la DCV (10 jours en 2029). La validation d'identité d'organisation suit ses propres règles, mais l'automatisation DV/OV reste la bonne réponse dans les deux cas.
À retenir : l'échéance des 47 jours ne se gagne pas en renouvelant plus vite, mais en automatisant la validation de domaine — de façon pré-validée et multi-fournisseurs — avant que la fenêtre ne se referme. Commencez à 200 jours.
