Blog · Infrastructure
Certificats TLS — vous regardez la mauvaise date
« 47 jours en 2029 », entend-on partout. Deux choses clochent dans cette phrase. Le plafond de 200 jours est en vigueur depuis mars 2026, et le palier qui casse réellement les procédures manuelles tombe le 15 mars 2027. Il reste six mois.
Ce qui a été voté, et par qui
Le 11 avril 2025, le CA/Browser Forum — l'organisme où se rencontrent les autorités de certification et les éditeurs de navigateurs — a adopté le scrutin SC-081v3. Il installe un calendrier de réduction progressive de la durée de vie des certificats TLS publics.
Le décompte des voix mérite d'être regardé, parce qu'il indique à quel point l'affaire est close :
- Autorités de certification : 25 pour, 0 contre, 5 abstentions.
- Éditeurs de navigateurs : 4 pour, 0 contre — Apple, Google, Microsoft et Mozilla.
Aucune opposition. Y compris de la part des autorités de certification, dont le modèle économique repose pourtant sur la vente de certificats de longue durée. Quand les vendeurs votent pour raccourcir leur propre produit, il n'y aura pas de marche arrière négociée.
Le calendrier, tel qu'il figure dans les exigences
Les Baseline Requirements — le texte normatif que doit respecter toute autorité de certification reconnue par les navigateurs — portent désormais trois échéances.
Trois paliers, deux compteurs
- Depuis le 15 mars 2026 — durée de vie maximale d'un certificat : 200 jours. Réutilisation des données de validation de domaine : 200 jours. Réutilisation des informations d'identité du titulaire : 398 jours.
- À partir du 15 mars 2027 — durée de vie maximale : 100 jours. Réutilisation de la validation de domaine : 100 jours.
- À partir du 15 mars 2029 — durée de vie maximale : 47 jours. Réutilisation de la validation de domaine : 10 jours.
Première conséquence, et elle est déjà derrière nous : le certificat d'un an n'existe plus depuis six mois. Si votre procédure annuelle consistait à racheter un certificat chaque printemps, elle a cessé de fonctionner en mars dernier — soit vous vous en êtes aperçu, soit votre fournisseur a silencieusement raccourci ce qu'il vous vend.
La mauvaise date
Pourquoi 2029 n'est pas le sujet
Presque tout ce qu'on lit sur cette réforme s'organise autour du chiffre de 47 jours et de l'année 2029. C'est compréhensible : c'est le chiffre spectaculaire, et c'est celui qui fait un titre.
C'est aussi celui qui permet de remettre le sujet à plus tard. Deux ans et demi, c'est loin. On a le temps.
Sauf que la question pertinente n'est pas « à partir de quand est-ce impossible à faire à la main ? » mais « à partir de quand est-ce que ça devient déraisonnable ? » Et cette réponse-là, c'est mars 2027.
Ce que chaque palier signifie en nombre d'opérations
Prenons une organisation avec quarante certificats publics — un chiffre modeste : quelques sites, une poignée d'API, des sous-domaines de services, un ou deux portails clients.
Avant mars 2026, à 398 jours : 37 renouvellements par an, soit environ trois par mois. C'est une tâche récurrente, agaçante mais tenable à la main.
Depuis mars 2026, à 200 jours : 73 renouvellements par an, soit six par mois. On sent la différence, on ne la subit pas encore.
À partir de mars 2027, à 100 jours : 146 renouvellements par an, soit trois par semaine. À ce rythme, une procédure manuelle ne tombe plus en panne un jour — elle est en panne permanente.
L'enseignement est banal et c'est pour ça qu'on le rate : une contrainte ne devient pas insupportable le jour où elle atteint son maximum. Elle devient insupportable bien avant, au moment où elle dépasse la capacité d'attention d'une personne qui a d'autres choses à faire. Ce seuil-là est franchi en mars 2027.
Le vrai problème
Ce n'est pas la durée du certificat, c'est la revalidation du domaine
Voici la partie que les résumés escamotent presque systématiquement, et c'est celle qui décide de tout.
Le calendrier comporte deux compteurs distincts, et on ne parle que du premier.
Le premier, c'est la durée de vie du certificat : combien de temps il reste valide une fois émis. Le renouveler, c'est refaire une demande et installer le nouveau fichier. Fastidieux, mais mécanique.
Le second, c'est la durée de réutilisation des données de validation de domaine : combien de temps l'autorité de certification a le droit de se fier à la preuve que vous contrôlez bien le domaine. Passé ce délai, il faut refaire la preuve — poser un enregistrement DNS, servir un fichier à une adresse précise, répondre à un défi.
Aujourd'hui, les deux compteurs sont à 200 jours et évoluent ensemble jusqu'en 2027. Puis ils divergent brutalement :
En 2029, le certificat dure 47 jours et la preuve de contrôle en dure 10
Cela veut dire qu'il faudra reprouver le contrôle du domaine environ trois fois plus souvent qu'on ne renouvelle le certificat. Sur nos quarante certificats, on ne parle plus de 310 opérations par an, mais d'un flux de validations qui se compte en milliers.
C'est aussi ce qui explique pourquoi la réponse ne peut pas être « on achètera des certificats plus souvent ». Le problème n'est pas le rythme d'achat, c'est que la chaîne de preuve doit devenir une fonction automatisée de votre infrastructure DNS. Ce n'est pas le même chantier, ni les mêmes personnes.
La délégation, qui est la vraie sortie
Il existe une échappatoire élégante, et elle mérite d'être connue parce qu'elle évite d'ouvrir un accès d'écriture DNS à tous vos serveurs : la délégation de la validation par CNAME. On crée une fois, à la main, un enregistrement qui délègue le sous-domaine de validation vers une zone dédiée, et c'est cette zone-là que le mécanisme d'automatisation manipule. La zone principale n'est plus touchée.
C'est une demi-journée de travail, une seule fois, et ça transforme un problème de gouvernance DNS en un détail d'exploitation. Si vous ne deviez retenir qu'une chose technique de cet article, ce serait celle-là.
Pourquoi
La durée courte est le mécanisme de révocation
On présente souvent cette réforme comme une lubie de comité, ou comme une manœuvre commerciale des vendeurs d'automatisation. Elle a une raison technique, et elle est solide.
Quand une clé privée est compromise, la réponse théorique est la révocation : l'autorité de certification publie que ce certificat n'est plus valable, et les navigateurs refusent de s'y fier. Sur le papier, c'est propre.
En pratique, la révocation n'a jamais bien fonctionné. Les listes de révocation sont volumineuses et mises à jour avec retard. Le protocole de vérification en ligne pose un problème de confidentialité — il révèle à l'autorité quels sites vous visitez — et, surtout, les navigateurs ont adopté depuis longtemps un comportement dit « en échec permissif » : si la vérification n'aboutit pas, on considère le certificat valable plutôt que de bloquer l'utilisateur. Un attaquant qui peut intercepter le trafic peut donc souvent empêcher la vérification d'aboutir.
Le raisonnement du CA/Browser Forum, en une phrase
Si l'on ne peut pas retirer un certificat de la circulation de façon fiable, alors la seule protection réelle est qu'il expire vite tout seul. La durée de vie devient la limite haute de la fenêtre d'exploitation d'une clé compromise.
Et ce n'est pas nouveau
La trajectoire est régulière depuis une quinzaine d'années. Les certificats publics ont été limités successivement à cinq ans, puis trois, puis deux, puis 398 jours en 2020 — une décision prise unilatéralement par Apple à l'époque, après l'échec d'un vote au Forum, et à laquelle les autres ont dû s'aligner.
Chacun de ces paliers a suscité les mêmes objections, et chacun s'est appliqué. La différence, cette fois, c'est qu'il y a un calendrier publié à quatre ans plutôt qu'une décision unilatérale avec dix-huit mois de préavis. C'est un progrès, même s'il ne se ressent pas comme tel.
Les échappatoires qui n'en sont pas
Trois idées qui circulent, et ce qu'elles valent
« On prendra des certificats EV, ils sont plus sérieux »
Cela ne fonctionne plus. Le 14 juillet 2026, le CA/Browser Forum a adopté le scrutin SC-102, à l'unanimité là encore — 19 autorités de certification sur 19, 2 éditeurs de navigateurs sur 2. Ce scrutin supprime la mention des « 398 jours » qui figurait dans les exigences propres aux certificats à validation étendue et les aligne sur le calendrier général. Il retire par ailleurs la vérification WHOIS/RDAP du mécanisme de réutilisation de domaine.
Autrement dit : les certificats EV suivront exactement la même trajectoire, aux mêmes dates. Payer plus cher n'achète plus de durée.
« On a déjà Let's Encrypt, ça ne nous concerne pas »
C'est vrai, et c'est même le point le plus intéressant de toute l'affaire. Une organisation dont les certificats sont déjà renouvelés automatiquement tous les 90 jours ne verra strictement rien se passer en mars 2027. Le palier des 100 jours est au-dessus de ce qu'elle fait déjà.
Ce qui se prépare n'est donc pas une contrainte nouvelle pour tout le monde. C'est une migration forcée de ceux qui ne l'ont pas faite vers ce que font déjà les autres. La réforme ne coûte rien à qui est automatisé, et beaucoup à qui ne l'est pas — ce qui est, accessoirement, exactement son intention.
Une réserve tout de même, pour ceux qui se croient à l'abri : être automatisé sur ses serveurs web ne veut pas dire l'être partout. Les certificats posés sur un équilibreur de charge matériel, un pare-feu applicatif, une passerelle de messagerie, un automate industriel ou une imprimante multifonction sont souvent installés à la main, une fois, et oubliés. Ce sont ceux-là qui tomberont, et personne ne les compte dans l'inventaire.
« Nos certificats sont internes, on fait ce qu'on veut »
Celle-ci est exacte, et c'est une distinction qu'il faut poser proprement parce qu'elle est souvent confondue avec la précédente.
Les Baseline Requirements s'appliquent aux certificats délivrés par les autorités de certification reconnues publiquement — celles dont la racine est installée dans les navigateurs et les systèmes d'exploitation. Une autorité de certification interne, dont la racine est distribuée par vos soins sur vos propres machines, n'est liée par aucune de ces règles. Elle peut émettre des certificats de dix ans si elle le souhaite.
Mais c'est un piège en deux temps
D'abord, la frontière est plus poreuse qu'on ne croit. Un service « interne » consulté depuis un navigateur d'un poste non géré, depuis un téléphone personnel, ou par un prestataire extérieur, a besoin d'un certificat publiquement reconnu. On découvre souvent la liste réelle le jour où quelqu'un se plaint.
Ensuite, un certificat interne de dix ans n'est pas une bonne pratique devenue tolérable : c'est la même mauvaise pratique, sans le garde-fou. Le raccourcissement des durées n'a pas été décidé par plaisir — il vise à réduire la fenêtre pendant laquelle une clé compromise reste utilisable, dans un monde où la révocation ne fonctionne pas de façon fiable.
Ce qu'il faut faire, et dans quel ordre
Six mois, c'est suffisant — à condition de commencer par l'inventaire
L'erreur classique serait de foncer sur l'outillage. Le chantier n'est pas technique en premier lieu, il est documentaire.
Dans cet ordre
1. Compter. Combien de certificats publics, sur quels équipements, expirant quand, achetés par qui. C'est l'étape que tout le monde saute et c'est celle qui réserve les surprises — le certificat posé en 2023 sur un boîtier par un prestataire qui n'intervient plus.
2. Séparer. Ce qui est déjà automatisé, ce qui est automatisable simplement, ce qui ne l'est pas du tout parce que l'équipement ne sait pas le faire. Cette troisième catégorie est la seule qui pose un vrai problème, et elle est en général plus petite qu'on ne le craint.
3. Déléguer la validation. Le CNAME décrit plus haut, posé une fois, avant de déployer quoi que ce soit. Ça évite d'avoir à arbitrer, dans l'urgence, qui a le droit d'écrire dans la zone DNS de l'entreprise.
4. Traiter les orphelins. Pour l'équipement qui ne sait pas renouveler tout seul, les options sont connues : le placer derrière un terminateur TLS qui, lui, sait le faire ; ou accepter une intervention manuelle tous les cent jours en l'inscrivant explicitement dans un calendrier, avec un nom de responsable en face.
Une dernière remarque, qui vaut au-delà des certificats. Cette réforme a été votée à l'unanimité par des acteurs qui n'avaient pas d'intérêt commercial à la voter, quatorze mois avant son premier palier, avec un calendrier publié jusqu'en 2029. Il est rare d'avoir autant de prévenance. Les échéances qui font mal, d'ordinaire, sont celles qu'on découvre trois mois avant.
Sources, vérifiées le 18 septembre 2026 : CA/Browser Forum, scrutin SC-081v3, 11 avril 2025 — décompte des voix (25 pour, 0 contre, 5 abstentions côté autorités ; 4 pour côté navigateurs) et principe de la réduction de 398 à 47 jours. Baseline Requirements en vigueur — c'est de là que proviennent les trois paliers et les deux compteurs : 200 jours au 15 mars 2026, 100 jours au 15 mars 2027, 47 jours au 15 mars 2029, et la réutilisation des données de validation de domaine qui passe de 200 à 100 puis à 10 jours. Scrutin SC-102, adopté le 14 juillet 2026 — alignement des certificats à validation étendue sur ce calendrier, unanimité 19/19 et 2/2, et retrait de la vérification WHOIS/RDAP. Les calculs de nombre de renouvellements par an sont les miens, à partir des durées ci-dessus et d'un parc hypothétique de quarante certificats ; ils illustrent un ordre de grandeur et ne prétendent pas décrire votre situation. La portée des Baseline Requirements aux seules autorités publiquement reconnues est une lecture du champ d'application du texte, pas une citation.
Vous ne savez pas combien vous avez de certificats ?
C'est la réponse la plus fréquente, et c'est précisément le point de départ. L'inventaire prend une demi-journée et décide de tout le reste.
Demander un premier échange