2026-10-20 · RECHERCHE · L'équipe d'Offensive Technology

La règle des certificats à 200 jours a-t-elle déjà pris effet ?

Réponse courte : oui, mais strictement dans la limite requise. Le plafond fixé par le CA/Browser Forum sur la validité des certificats TLS publics est passé de 398 jours à 200 jours le 15 mars 2026, il y a sept mois. Nous avons analysé l'historique public de Certificate Transparency de 702 domaines de premier plan, soit 1,359,618 certificats dédupliqués enregistrés entre 2013 et aujourd'hui, et nous avons comparé la fenêtre de validité de chaque certificat avant et après cette date. Au cours des deux années précédant la transition, 75.3% des certificats étaient déjà d'une durée inférieure ou égale à 200 jours. Durant les sept mois qui ont suivi, cette proportion est de 99.91%, soit une conformité quasi totale dans les faits. Mais le point le plus instructif réside dans la position adoptée par chaque autorité de certification sous ce nouveau plafond. Les émetteurs gratuits et automatisés, parmi lesquels Let’s Encrypt et Google Trust Services, conservent une médiane de 90 jours, sans aucun impact de la règle puisqu'ils avaient déjà des années d'avance. Les grandes AC commerciales, comme DigiCert, Amazon, Microsoft ou GlobalSign, sont passées d'une médiane de 324 à 397 jours directement à 198 ou 199 jours : le seuil plancher désormais autorisé par la règle, pas un jour de moins. L'une d'entre elles, Sectigo, a rompu avec ce schéma. Voici l'intégralité des données, notre méthode de mesure et ce qui changera de nouveau en mars 2027.

Le calendrier, et où nous en sommes

Scrutin SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods,” a été adopté par le CA/Browser Forum le 11 avril 2025 : les émetteurs de certificats ont voté 25-0-5 (cinq abstentions) et le collège des navigateurs, Apple, Google, Microsoft et Mozilla, a voté 4-0-0 en faveur du texte. Apple en était à l'origine. Il instaure une réduction échelonnée de la durée maximale de validité des certificats TLS publics, ainsi qu'une réduction parallèle et plus stricte de la durée pendant laquelle une AC peut réutiliser une validation préalable du contrôle de domaine :

• Jusqu'au 14 mars 2026 : 398 jours de validité maximale, 398 jours de réutilisation de la validation.
• 15 mars 2026 : 200 jours de validité maximale, 200 jours de réutilisation de la validation. Cette étape est déjà franchie.
• 15 mars 2027 : 100 jours de validité maximale, 100 jours de réutilisation de la validation.
• 15 mars 2029 : 47 jours de validité maximale, 10 jours de réutilisation de la validation.

À ce jour, le palier des 200 jours est en place depuis sept mois, celui des 100 jours intervient dans environ cinq mois, et celui des 47 jours dans environ deux ans et demi. Cet article traite des changements concrets apportés par la première étape, et non du calendrier en lui-même : chaque registrar et base de connaissances d'AC détaille déjà ces dates. Nous voulions savoir si les émissions réelles sur le terrain ont évolué dès que la règle l'a imposé, et nous disposions de treize années de nos propres données CT passives pour le vérifier.

Deux catégories, une seule échéance

Commençons par une vue d'ensemble. Tous émetteurs confondus, la part des certificats nouvellement émis d'une durée de 200 jours ou moins est passée de 75.3% au cours des deux années précédant le plafond à 99.91% au cours des sept mois suivants. C'est un basculement vers la conformité quasi universel, ce qui correspond exactement à ce qu'une date butoir stricte des Baseline Requirements doit produire : manquez-la, et les navigateurs cessent d'accorder leur confiance à votre certificat. Cette partie a fonctionné comme prévu.

En y regardant de plus près, l'écosystème se scinde en deux groupes qui n'ont pas évolué de la même manière, voire pas du tout :

• Déjà là. Let’s Encrypt et Google Trust Services, de loin les deux plus grands émetteurs en volume de notre échantillon, appliquent une durée par défaut de 90 jours depuis bien avant l'apparition de cette règle, car leur système d'émission est gratuit, automatisé et pensé dès le premier jour autour d'un renouvellement fréquent. Leur médiane post-mandat est de 90 jours. Leur médiane pré-mandat était de 90 jours. Les certificats émis via ACME par Apple et la nouvelle AC orientée automatisation Certainly affichent la même tendance, avec respectivement 86 et 30 jours, stables à travers la transition. Pour ce groupe, le 15 mars 2026 n'a rien changé, car la règle n'a fait que rattraper ce qu'ils appliquaient déjà.
• Calés exactement sur le plancher. DigiCert, Amazon, Microsoft et GlobalSign ont tous enregistré une baisse marquée, mais chacun d'entre eux s'est positionné à 198 ou 199 jours, soit un jour en deçà du nouveau plafond de 200 jours, sans aller sensiblement plus bas. Avant le plafond, leur certificat type durait entre 180 et 397 jours. Après celui-ci, tous les quatre convergent à un jour près du maximum légal. C'est une conformité appliquée à la lettre d'une règle explicitement conçue pour orienter le secteur vers des certificats à durée de vie plus courte, sans en adopter la philosophie.

Sectigo est le seul émetteur de notre échantillon qui n'entre clairement dans aucun de ces deux cas de figure. Sa médiane pré-mandat était de 366 jours, clairement positionnée dans le camp traditionnel, mais sa médiane post-mandat est tombée à 90.4 jours, avec 55.6% de ses certificats post-mandat déjà fixés à 90 jours ou moins. Il s'agit d'une réelle évolution vers les pratiques de la catégorie automatisée, et non d'un simple ajustement au nouveau plafond. Les seules métadonnées CT ne permettent pas d'en déterminer la raison ; cela concorde avec un changement de pipeline d'émission ou d'intégration ACME désormais utilisé par les clients Sectigo de notre échantillon, sans que nous puissions en confirmer le mécanisme précis.

Microsoft mérite une observation distincte car son indicateur a évolué à l'inverse de la tendance sur le papier : une médiane pré-mandat de 180 jours remontant à 198 jours après l'entrée en vigueur. Nous analysons cela comme le fait que Microsoft appliquait déjà une durée inférieure à ce que l'ancien plafond de 398 jours autorisait, pour ensuite se recentrer juste sous le nouveau seuil de 200 jours. C'est le même comportement de collage au plafond que les autres AC d'entreprise, mais en partant d'une base initiale un peu plus courte. Cela ne prouve en rien que les certificats de Microsoft sont devenus moins sûrs ; durée de validité et posture de sécurité ne relèvent pas du même axe, ce qui constitue d'ailleurs le sujet de notre section suivante.

Qui fait quoi, en chiffres

Chaque émetteur mentionné ci-dessus a respecté le plafond de 200 jours sur la quasi-totalité de ses certificats post-mandat dans notre échantillon ; nous n'avons relevé aucun manquement aux Baseline Requirements, ce qui est attendu de la part de root programs qui effectuent des audits rigoureux à ce sujet. Le constat n'est pas un défaut de conformité. Il réside dans le fait que la conformité prend deux formes distinctes, et que l'écart entre “automatisé, déjà court” et “entreprise, désormais au plancher” reste d'un facteur d'environ deux en jours réels, de 90 à 198, au sein d'une même règle que les deux groupes respectent pareillement.

Notre méthodologie de mesure

Un regard critique doit pouvoir reproduire ces résultats de zéro.

• La population. Les mêmes historiques Certificate Transparency d'environ 700 domaines de premier plan Tranco, relevés via crt.sh, que nous avions utilisés pour notre recensement des délais de journalisation CT et notre recensement des fuites de noms d'hôtes internes. Nous n'avons émis aucune nouvelle requête réseau pour cet article ; l'intégralité du jeu de données était déjà en cache à la suite de travaux antérieurs.
• La métrique. Pour chaque certificat consigné et dédupliqué, la période de validité correspond à not_after moins not_before, arrondie au jour entier le plus proche avant catégorisation, car un certificat nominal de “90 jours” équivaut souvent à 90 jours auxquels s'ajoutent quelques heures de décalage brut liées à l'horodatage de l'émission dans la journée.
• La segmentation. Nous avons classé les certificats selon que not_before se situait avant ou à compter du 15 mars 2026. Pour la comparaison par émetteur, nous avons retenu une fenêtre équivalente de deux ans précédant immédiatement la transition (du 15 mars 2024 au 14 mars 2026) plutôt que l'historique complet, afin que les anciens certificats émis dix ans plus tôt par une AC ne pénalisent pas injustement son score “avant”.
• Ce que nous n'avons pas fait. Nous n'avons jamais demandé de certificat, ne nous sommes connectés à aucun serveur web ni n'avons scanné quoi que ce soit. Lire un registre CT public relève d'une consultation, pas d'un sondage actif.
• Ce que nous avons conservé. Les totaux agrégés, médianes et percentiles par émetteur et par période. Aucun nom de domaine ou de sous-domaine ne figure dans les résultats.

Ce que cela ne prouve pas

Des limites transparentes, car un chiffre sans ses réserves relève du marketing.

• Une validité de certificat plus courte ne correspond pas à une durée de vie plus courte de la clé privée. Une AC ou un abonné peut renouveler indéfiniment un certificat avec la même paire de clés tous les 90 ou 200 jours ; les métadonnées de base sur crt.sh n'exposent pas l'empreinte de la clé publique du sujet, de sorte que nous ne pouvons pas déduire de ces données si le matériel cryptographique est réellement renouvelé en même temps que le certificat. Le bénéfice de sécurité d'une validité plus courte dépend de ce renouvellement effectif ; nous ne l'avons pas mesuré ici.
• Sept mois de données post-mandat constituent une lecture précoce. Cela suffit pour identifier la tendance initiale de conformité, mais pas pour affirmer qu'il s'agit de l'équilibre permanent du secteur sous un plafond de 200 jours. Nous prévoyons de faire un nouveau point lors de la prochaine étape, en mars 2027.
• Tous les émetteurs ne présentent pas un tableau avant-après fiable. Plusieurs AC présentes dans notre cache, notamment GoDaddy et quelques émetteurs plus modestes ou régionaux, comptaient un échantillon post-mandat trop faible au sein de notre panel de 700 domaines pour tirer des conclusions fiables ; nous n'avons retenu que les émetteurs disposant d'un échantillon solide sur les deux périodes.
• La population est biaisée en faveur des domaines à fort trafic. La tête du classement Tranco s'appuie sur des organisations disposant de moyens importants et sur de grands CDN. Le comportement d'émission pour la longue traîne des sites plus modestes, souvent hébergés derrière ces mêmes grandes AC via d'autres modes d'automatisation, peut être différent.
• Cette étude mesure les autorités de certification, pas directement le risque lié aux attaquants. Un plafond plus court réduit la fenêtre maximale durant laquelle un certificat reste valide en cas d'anomalie, mais ce n'est qu'un élément au sein d'une chaîne plus large comprenant la révocation, l'hygiène des clés et la surveillance.

Pourquoi cela compte

Tout l'argument en faveur de la réduction de la durée de vie des certificats repose sur la fenêtre d'exposition : un certificat compromis ou émis par erreur qui aurait subsisté pendant 398 jours sous l'ancienne règle ne dure plus, au maximum, que 200 jours, puis durera au maximum 100 jours, puis 47 jours, au fil du calendrier. Cet argument ne porte ses fruits que si l'écosystème évolue concrètement vers des durées plus courtes, sans se contenter de rester juste sous le plafond légal en vigueur. Après sept mois, les données confirment ces deux constats. La règle a joué son rôle de plancher strict : la conformité est passée de trois quarts à la quasi-totalité, du jour au lendemain à l'échelle du secteur. En revanche, l'essentiel du volume qui s'est déplacé ne l'a fait que dans la stricte limite requise par le nouveau seuil, en se fixant à un jour de 200 plutôt qu'aux alentours de 90. Les émetteurs appliquant déjà des durées courtes, dont le modèle économique repose sur un renouvellement automatisé, économique et fréquent, n'ont pas été affectés, car ils avaient anticipé cette architecture des années avant qu'un vote du Forum ne la rende obligatoire. C'est le même constat que nous avions dressé lors de notre analyse sur la rapidité de journalisation des certificats dans CT : les pans de cet écosystème soumis à une obligation stricte avancent exactement à la vitesse exigée par la contrainte, pas plus vite.

La règle des certificats à 200 jours a-t-elle pris effet : réponses rapides

Quand la règle des certificats à 200 jours a-t-elle débuté ?

Le 15 mars 2026, dans le cadre du scrutin SC-081v3 du CA/Browser Forum, adopté le 11 avril 2025. Il a réduit la validité maximale des certificats TLS publics de 398 à 200 jours. La prochaine réduction, à 100 jours, est prévue le 15 mars 2027 ; une réduction finale à 47 jours est fixée au 15 mars 2029.

Les certificats existants doivent-ils être réémis selon la nouvelle limite ?

Non. Le plafond ne concerne que les certificats émis à compter de la date d'effet. Un certificat émis sous l'ancienne règle des 398 jours poursuit son cycle de validité initial.

La période de réutilisation de la validation de domaine sera-t-elle également réduite ?

Oui, selon le même calendrier : de 398 à 200 jours lors de l'étape de mars 2026, puis 100 jours en mars 2027 et 10 jours d'ici mars 2029, imposant une revérification plus fréquente du contrôle de domaine, indépendamment de la validité du certificat lui-même.

Quand la règle des certificats à 47 jours entrera-t-elle en vigueur ?

Le 15 mars 2029, dernière étape du calendrier SC-081v3 : 398 jours jusqu'au 14 mars 2026, 200 jours à partir du 15 mars 2026, 100 jours à partir du 15 mars 2027, 47 jours à partir du 15 mars 2029.

Comment ces mesures ont-elles été établies ?

De manière passive. Nous avons analysé l'historique public CT, via crt.sh, d'environ 700 domaines du top-1,000 Tranco, en calculant la durée de validité de chaque certificat selon la formule NotAfter moins NotBefore. Aucun hôte n'a été contacté, résolu ou scanné. Le résultat porte sur 1,359,618 entrées de journal dédupliquées entre 2013 et octobre 2026.

Lectures recommandées

• Délai de journalisation Certificate Transparency : ce que révèlent 1.3M de certificats.
• Comment les registres Certificate Transparency font fuiter des sous-domaines internes.
• Ce que prouvent les certificats.