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.
Mis à jour le 18 août 2026 : ajout de la validation persistante (SC-088v3 / DNS-PERSIST-01), de son état d'adoption réel, des certificats 6 jours de Let's Encrypt et de l'extinction des validations e-mail et téléphone (SC-090).
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) |
|---|---|---|
| Jusqu'au 14 mars 2026 | 398 jours | 398 jours |
| Depuis le 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.
Le marché va déjà plus vite que la contrainte
Pendant que le CA/B Forum planifie 47 jours pour 2029, Let's Encrypt délivre depuis le 15 janvier 2026, en disponibilité générale, des certificats de 160 heures — un peu plus de six jours — ainsi que des certificats pour adresses IP. Le profil ACME shortlived doit être activé explicitement côté client ; les certificats IP sont obligatoirement à durée courte et n'acceptent que les challenges http-01 et tls-alpn-01. Let's Encrypt recommande de renouveler ces certificats environ tous les trois jours.
Six jours, quand le mandat fixe 47 jours pour 2029 : une organisation qui dimensionne son automatisation pour « tenir 2029 » prépare en réalité un régime déjà dépassé. La bonne cible n'est pas le minimum réglementaire — c'est un pipeline où la durée de vie du certificat devient un paramètre libre.
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 :
- Sous l'ancien régime des ~398 jours : environ 460 renouvellements par an.
- Depuis mars 2026, à 200 jours : environ 910 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. Et ce ne sont pas les failles cryptographiques qui coupent les services : c'est un certificat qui expire sans que personne l'ait vu venir. Multiplier les renouvellements par 8 sans automatisation, c'est multiplier mécaniquement les occasions de rater une échéance.
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.
Depuis novembre 2025, DNS-01 n'est d'ailleurs plus la seule méthode DNS : DNS-PERSIST-01 (voir plus bas) en conserve les avantages — wildcards, aucun service web exposé — et supprime en plus le besoin d'un accès en écriture permanent aux API DNS. C'est un argument de sécurité autant que d'exploitation : les identifiants d'API DNS comptent parmi les secrets les plus sensibles d'une infrastructure.
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.
La validation persistante ne supprime pas ce besoin : elle le déplace. Il ne s'agit plus d'écrire dans chaque zone à chaque cycle, mais de poser une fois puis surveiller l'enregistrement persistant sur chacune d'elles. Le multi-fournisseurs reste non négociable — pour une raison différente.
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 ».
C'est la stratégie de référence tant que votre AC ne propose pas de validation persistante — ce qui, à l'été 2026, est le cas de la grande majorité des AC publiques (voir la section suivante).
La réponse du CA/B Forum : DNS-PERSIST-01
Depuis fin 2025, le problème décrit ci-dessus a une réponse normative. Le ballot SC-088v3, proposé par Amazon Trust Services et endossé par Google Chrome, DigiCert et Sectigo, a été adopté le 9 octobre 2025 et est entré en vigueur le 10 novembre 2025. Il ajoute aux Baseline Requirements TLS la section 3.2.2.4.22, « DNS TXT Record with Persistent Value » : les AC peuvent utiliser cette méthode depuis cette date — son implémentation reste à leur discrétion.
Le mécanisme : un enregistrement TXT à portée de compte, publié une seule fois au label _validation-persist.[domaine], qui identifie le compte du demandeur chez l'AC (URI de compte au sens de la RFC 8657, expiration optionnelle). L'AC revalide contre ce même enregistrement, sans modification DNS à chaque cycle.
Côté ACME, le challenge correspondant s'appelle dns-persist-01 (draft IETF draft-ietf-acme-dns-persist, adopté par le groupe de travail mi-octobre 2025 — encore à l'état de brouillon, on y revient plus bas).
Le format, concrètement
_validation-persist.example.com. IN TXT (
"letsencrypt.org;"
" accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890;"
" policy=wildcard"
)
| Élément | Rôle |
|---|---|
letsencrypt.org | Nom de domaine de l'émetteur — permet d'autoriser plusieurs AC (un enregistrement par AC) |
accounturi | Liaison au compte ACME (RFC 8657). Obligatoire. Survit à la rotation de clé du compte. |
policy=wildcard | Optionnel : couvre les sous-domaines et l'émission wildcard. Absent, seul le FQDN exact est couvert. |
persistUntil | Optionnel : horodatage UNIX bornant la validité de l'autorisation |
Deux pièges d'exploitation à connaître :
- si
persistUntilest utilisé, il faut surveiller et mettre à jour l'enregistrement avant l'échéance, faute de quoi le renouvellement échoue silencieusement. La charge de gestion de cette expiration peut annuler le bénéfice du « poser une fois » — à peser ; - le TTL de l'enregistrement compte : s'il est plus court que la période de réutilisation de l'AC, c'est lui qui devient la période effective (et un TTL de 0 interdit toute réutilisation).
Ce que la méthode change — et ce qu'elle ne change pas
Précision importante, car on lit tout et son contraire : la section 3.2.2.4.22 impose son propre plafond de réutilisation de 10 jours, applicable dès aujourd'hui — là où les autres méthodes DCV bénéficient encore de 200 jours jusqu'en mars 2027. Le texte des BR est explicite : « CAs MUST consider 10 days as the maximum validation data reuse period for validations completed using this method ».
Autrement dit, DNS-PERSIST-01 ne contourne pas la réduction des fenêtres de réutilisation : il la rend indolore. L'AC revérifie l'enregistrement au moins tous les 10 jours, mais cette vérification ne demande plus aucune écriture DNS. Le compromis est explicite — on échange de la preuve de fraîcheur contre de la simplicité d'exploitation. C'est précisément la « pré-validation continue » décrite plus haut, déplacée de votre outillage vers la norme.
À noter : le ballot SC-091 (adopté en novembre 2025, en vigueur depuis décembre) étend la méthode aux adresses IP, via un enregistrement _ip-validation-persist posé dans la zone inverse .arpa (section 3.2.2.5.8 des BR).
Où en est l'adoption (août 2026)
Le standard est voté et en vigueur côté Baseline Requirements, mais la spécification ACME n'est pas stabilisée et aucun déploiement grand public n'est en production. Le calendrier réglementaire avance plus vite que l'outillage.
| Acteur | État au 18 août 2026 |
|---|---|
| Spécification IETF | draft-ietf-acme-dns-persist-01 (mars 2026). Une révision -02 est attendue ; points ouverts : peuplement des métadonnées (issuer-domain-names, caaIdentities), confidentialité de accounturi, validation wildcard, exigences DNSSEC. |
| Let's Encrypt | Staging uniquement (support du draft-01 depuis fin avril 2026). Production annoncée pour le T2 2026, calendrier glissé ; déploiement suspendu fin juin dans l'attente d'une clarification de la spécification. Pas de date ferme. |
| Sectigo | Disponible dans Certificate Manager depuis mai 2026 — premier support commercial. |
| Clients ACME | lego : implémenté depuis la v5.0.0 (mai 2026). cert-manager et Caddy : demandes ouvertes, pas d'implémentation — attente de la stabilisation de la spécification. |
Le draft est co-écrit par des ingénieurs de Fastly et d'Amazon Trust Services ; leurs AC respectives n'ont pas annoncé publiquement de support à ce jour.
Conséquence pratique : vérifiez ce que vos AC supportent, posez les enregistrements persistants là où c'est possible, et gardez un repli DNS-01 automatisé partout ailleurs — c'est l'objet de la checklist ci-dessous.
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.
- Vérifier si vos AC supportent DNS-PERSIST-01 (l'implémentation est à leur discrétion).
- Poser les enregistrements
_validation-persistsur les zones dont l'AC le permet — et surveillerpersistUntille cas échéant. - Prévoir un repli en DNS-01 pour les AC qui ne l'implémentent pas encore.
- Identifier les domaines encore validés par e-mail ou téléphone et planifier leur migration : le ballot SC-090 éteint la validation par téléphone au 15 mars 2027 et par e-mail au 15 mars 2028.
- Brancher supervision et alertes sur les échecs de validation et les expirations approchant.
Vous êtes déjà sur la marche des 200 jours depuis mars 2026. La suivante, 100 jours au 15 mars 2027, est celle qu'il faut préparer maintenant, pas celle de 2029 : 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. La validation persistante déplace d'ailleurs le problème sans le supprimer : savoir quels domaines portent un enregistrement persistant, lesquels n'en ont pas, quelle AC le supporte, et gérer le repli — c'est un problème d'inventaire et de couverture, pas d'écriture DNS, et c'est exactement ce que l'inventaire PKIFactor est fait pour montrer. 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 a commencé le 15 mars 2026 (200 jours), et la prochaine marche, 100 jours, tombe le 15 mars 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. ACME évolue d'ailleurs lui-même — une quatrième méthode de challenge, dns-persist-01, est en cours de normalisation à l'IETF. L'automatisation n'est pas un état stable : c'est un chantier continu.
Et les certificats wildcard ?
Ils imposent une validation par DNS : DNS-01 aujourd'hui, ou DNS-PERSIST-01 avec policy=wildcard quand votre AC le supporte. 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.
