Depuis le 15 mars 2026, plus aucun site web ne peut recevoir un certificat SSL/TLS public valable plus de 200 jours. La règle vient du CA/Browser Forum, l’organisme qui fixe les standards du chiffrement web, et elle marque le début d’une descente programmée. Le prochain palier tombe en mars 2027, à 100 jours. Le dernier arrive en mars 2029, avec une limite fixée à 47 jours.

Cinq mois après l’entrée en vigueur du premier seuil, l’industrie du web ajuste ses processus de renouvellement. Pour les administrateurs systèmes et les responsables sécurité, la question n’est plus de savoir si l’automatisation s’impose, mais à quelle vitesse la mettre en place. Ce texte détaille le calendrier exact, les acteurs qui l’ont négocié, et ce que la réforme change pour les entreprises françaises et européennes.

La réforme SC-081v3 expliquée en trois chiffres

Le nom officiel du texte est aride : ballot SC-081v3, adopté par le CA/Browser Forum le 11 avril 2025. Cet organisme réunit les autorités de certification et les éditeurs de navigateurs. Ses décisions fixent les règles de base, les “Baseline Requirements”, que doit respecter tout certificat SSL/TLS public utilisé sur le web. Le texte a été proposé à l’origine par Apple, avant de recueillir un soutien unanime des membres votants, autorités de certification comme navigateurs confondus.

Trois chiffres résument la portée de la réforme. D’abord, 398 jours : la durée de validité maximale d’un certificat public depuis septembre 2020, et ce jusqu’au 14 mars 2026. Ensuite, 200 jours : le nouveau plafond en vigueur depuis le 15 mars 2026. Enfin, 47 jours : la limite finale prévue pour le 15 mars 2029, soit une réduction de près de 88 % par rapport au régime en place avant 2026. Entre ces bornes, un palier intermédiaire à 100 jours doit entrer en vigueur le 15 mars 2027.

Un calendrier gravé dans le marbre jusqu’en 2029

Le tableau ci-dessous résume les quatre étapes du calendrier officiel, ainsi que l’anticipation volontaire de certains émetteurs.

Date d’entrée en vigueurDurée de validité maximaleRéutilisation des données DCV (SAN)
Jusqu’au 23 février 2026398 jours398 jours
24 février 2026 (DigiCert, par anticipation)199 joursNon communiqué
15 mars 2026 (entrée en vigueur officielle)200 jours200 jours
15 mars 2027100 jours100 jours
15 mars 202947 jours10 jours

Le texte du ballot est sans ambiguïté : tout certificat public émis à partir du 15 mars 2029 ne doit pas dépasser 47 jours de validité. Cette limite est intégrée aux Baseline Requirements du CA/Browser Forum, le socle contractuel que toute autorité de certification doit respecter pour rester reconnue par les navigateurs. Une autorité qui émettrait des certificats plus longs que la limite en vigueur risquerait, en théorie, de voir sa confiance révoquée par Chrome, Safari, Firefox ou Edge.

Sur le terrain, certains émetteurs ont anticipé le mouvement. DigiCert a commencé à délivrer des certificats de 199 jours dès le 24 février 2026, trois semaines avant l’échéance officielle, pour laisser à ses clients une marge d’ajustement avant le passage en force du 15 mars.

Ce qui change aussi pour la validation de domaine

Le ballot SC-081v3 ne touche pas seulement la durée des certificats. Il réduit aussi la période pendant laquelle une autorité de certification peut réutiliser une validation de domaine déjà effectuée, ce qu’on appelle le DCV, pour “domain control validation”. Cette fenêtre de réutilisation passe de 398 à 10 jours pour les données liées au nom de domaine, et de 825 à 398 jours pour les autres types de données de validation. Concrètement, les entreprises devront revalider la propriété de leurs domaines beaucoup plus souvent, une contrainte qui pousse elle aussi vers l’automatisation complète du cycle de vie des certificats.

Qui a poussé cette réforme, et pourquoi

L’idée de comprimer la durée de vie des certificats ne date pas de 2025. Apple avait déjà forcé la main du secteur en 2020 en annonçant que Safari refuserait les certificats de plus de 398 jours, obligeant de facto toute l’industrie à s’aligner sur cette limite sous peine de voir ses sites affichés comme non sécurisés. Le ballot SC-081v3 reprend la même logique, avec un horizon plus agressif et surtout un calendrier public fixé quatre ans à l’avance.

L’argument technique avancé par ses promoteurs, Apple en tête, tient en une phrase : plus un certificat vit longtemps, plus la fenêtre est large pour exploiter une clé privée compromise ou une validation de domaine devenue obsolète. Un certificat de 47 jours limite mécaniquement la durée d’exposition en cas de faille, puisqu’il expire et doit être renouvelé bien avant qu’un usage frauduleux ne s’installe durablement. SSL.com résume cette logique en écrivant que la réduction des durées de vie “incite le secteur à adopter plus vite les standards de sécurité à jour et réduit la fenêtre de vulnérabilité”.

Le vote final n’a laissé aucune place au débat. Les membres du CA/Browser Forum, autorités de certification et navigateurs confondus, ont approuvé le texte sans voix contre, un niveau de consensus rare pour une mesure aussi contraignante sur le plan opérationnel.

Six mois après le premier palier, où en est le web

Le 14 août 2026, cela fait tout juste cinq mois que la limite de 200 jours s’applique. La transition s’est déroulée sans incident majeur rapporté, en grande partie parce que les plus gros émetteurs de certificats avaient déjà bâti leur infrastructure autour du renouvellement automatique. Let’s Encrypt, à lui seul, délivrait déjà des certificats valables 90 jours par défaut bien avant l’entrée en vigueur du ballot, une pratique qui a habitué une bonne partie du web à des cycles courts.

Le vrai test arrive avec le palier suivant. Passer de 200 à 100 jours en mars 2027 va toucher une catégorie d’organisations différente : celles qui utilisent encore des certificats à validation étendue gérés manuellement par de petites équipes IT, souvent dans des structures moins matures sur le plan de l’automatisation, comme certaines PME industrielles ou administrations locales.

Le poids de Let’s Encrypt dans l’équation

Impossible de comprendre cette réforme sans regarder qui émet réellement les certificats du web aujourd’hui. Le tableau suivant présente la répartition par autorité de certification.

Autorité de certificationPart de marché (juin 2026)
Let’s Encrypt54,5 %
Google Trust Services13,5 %
Sectigo11,2 %
Amazon Trust Services9,2 %
GoDaddy4,8 %
DigiCert3,5 %
Autres autorités3,3 %

Selon une analyse de juin 2026 fondée sur les données de transparence des certificats de Cloudflare Radar, Let’s Encrypt émet à lui seul 54,5 % des certificats web recensés, loin devant Google Trust Services et Sectigo. Cette position dominante n’est pas un hasard : l’autorité de certification à but non lucratif, lancée en 2015 par l’Internet Security Research Group, a construit tout son modèle autour de l’émission gratuite et automatisée, via le protocole ACME.

Dans son rapport annuel 2025, Let’s Encrypt indiquait servir 762 millions de sites web et avoir délivré plus de 7 milliards de certificats depuis sa création. Ce chiffre donne la mesure de l’impact d’une réforme comme SC-081v3 : quand l’acteur qui protège plus de la moitié des certificats du web a déjà bâti son activité sur des cycles courts, la bascule du reste du secteur vers le même modèle devient presque inévitable.

Let’s Encrypt vise déjà plus vite que la norme du secteur

Let’s Encrypt n’attend pas 2029. L’autorité propose déjà des certificats de courte durée optionnels, valables six jours seulement, et a annoncé son intention de faire passer sa durée de validité par défaut à 45 jours d’ici 2028, un an d’avance sur l’échéance imposée par le CA/Browser Forum. Pour une organisation qui a déjà automatisé son cycle ACME, ce changement ne demande quasiment aucun effort supplémentaire. Pour les autres, il s’agit d’un signal de plus que le statu quo n’est plus tenable.

L’automatisation ACME, désormais obligatoire dans les faits

Techniquement, rien n’oblige une entreprise à automatiser le renouvellement de ses certificats. Dans la pratique, la fenêtre de 47 jours rend le renouvellement manuel intenable pour toute organisation qui gère plus de quelques domaines. Un administrateur qui devait renouveler un certificat tous les 13 mois pouvait encore s’en sortir avec un simple rappel dans son agenda. À 47 jours, cela représente près de huit renouvellements par an et par certificat, un rythme incompatible avec un processus purement humain.

Le protocole ACME, pour “Automatic Certificate Management Environment”, popularisé par Let’s Encrypt et désormais soutenu par la quasi-totalité des grandes autorités de certification, devient de fait la voie obligée. Voici un exemple de configuration cron pour un renouvellement automatique via le client Certbot, l’un des plus utilisés :

0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Cette ligne exécute une vérification quotidienne à 3h du matin et ne renouvelle le certificat que dans les jours précédant son expiration, avant de recharger automatiquement le serveur web. Ce type d’automatisation, encore facultatif il y a cinq ans, devient la base incompressible de toute gestion de certificats à l’ère des 47 jours. Le site a déjà détaillé la marche à suivre dans son guide pour obtenir un certificat SSL gratuit avec Certbot.

Vers la fin programmée de RSA ? Le boulevard pour ECDSA et Ed25519

La réforme SC-081v3 ne dit rien, explicitement, sur les algorithmes de signature utilisés dans les certificats. Mais la pression qu’elle exerce en faveur de l’automatisation profite mécaniquement aux courbes elliptiques. Un certificat ECDSA occupe une empreinte plus légère qu’un certificat RSA de niveau de sécurité comparable, ce qui réduit la taille des échanges lors de la négociation TLS, un avantage qui compte davantage quand les poignées de main se répètent toutes les six semaines plutôt qu’une fois par an.

Les infrastructures automatisées modernes, construites autour d’ACME, sont aussi celles qui adoptent le plus naturellement les clés ECDSA ou Ed25519 par défaut, les bibliothèques récentes privilégiant ces algorithmes pour les nouveaux déploiements. Le site a déjà chiffré l’écart de performance entre ces deux familles de signatures dans son comparatif ECDSA vs RSA, où les signatures ECDSA se montrent plusieurs fois plus rapides à générer que leur équivalent RSA à sécurité comparable.

Contexte historique : dix ans de course à la réduction

La tendance ne date pas de 2025. Pendant longtemps, un certificat SSL commercial pouvait rester valable plusieurs années. Le CA/Browser Forum a progressivement resserré la vis au fil des ballots successifs, avant qu’Apple ne porte le coup le plus dur en 2020 : à partir de septembre de cette année-là, Safari a refusé tout certificat public dépassant 398 jours de validité, forçant l’ensemble de l’industrie à s’aligner en quelques mois à peine.

Ce précédent de 2020 éclaire la mécanique actuelle. Un acteur du marché, souvent un éditeur de navigateur en position de force, impose une contrainte technique par le biais des règles du CA/Browser Forum plutôt que par la loi. Cette fois, la contrainte est étalée sur quatre ans, ce qui laisse davantage de temps aux entreprises pour s’organiser que le changement plus brutal de 2020. C’est aussi ce qui distingue SC-081v3 : un calendrier public, connu à l’avance, plutôt qu’un couperet soudain.

Quel impact pour la France et l’Europe

Le calendrier du CA/Browser Forum s’applique à l’échelle mondiale, sans exception géographique. Tout certificat public utilisé par un site accessible depuis un navigateur grand public y est soumis, qu’il s’agisse d’une entreprise française, allemande ou américaine. Aucune déclaration officielle de l’ANSSI ou de l’ENISA concernant spécifiquement le calendrier SC-081v3 n’a été identifiée à ce jour, mais la réforme s’inscrit dans un climat réglementaire européen qui pousse, par d’autres canaux, dans la même direction : hygiène cryptographique renforcée et automatisation des processus de sécurité.

L’ANSSI a par exemple annoncé le 16 juin 2026 qu’elle cesserait de certifier, à partir de 2027, les produits de sécurité dépourvus de chiffrement résistant aux ordinateurs quantiques. Cette mesure est distincte de la réforme des certificats TLS, mais elle révèle la même tendance de fond : régulateurs et organismes de normalisation resserrent, de tous côtés, les exigences cryptographiques imposées aux entreprises. Pour une PME française qui gère son propre parc de certificats, la combinaison de ces échéances, courte durée de vie TLS d’un côté, migration post-quantique de l’autre, plaide pour une remise à plat complète de la gestion des clés plutôt que pour des ajustements ponctuels.

Ce que risquent les entreprises qui traînent des pieds

Le risque le plus immédiat n’est pas juridique, il est opérationnel. Un certificat expiré bloque purement et simplement l’accès au site pour l’utilisateur, avec un message d’avertissement affiché dans le navigateur. Avec un cycle de 47 jours, l’écart entre “tout fonctionne” et “le site est inaccessible” devient beaucoup plus étroit qu’avec un cycle annuel.

Les organisations qui gèrent leurs certificats manuellement, via des tickets internes ou des feuilles de suivi, s’exposent à un nombre d’incidents potentiels multiplié par huit par rapport au régime actuel à 398 jours. Les secteurs les plus exposés restent ceux où l’achat de certificats passe encore par des circuits centralisés et lents : administrations, grands groupes avec des parcs fragmentés entre plusieurs équipes, ou sites hérités maintenus sans outillage moderne. Selon CyberSecurityNews, la compression du calendrier jusqu’à des renouvellements quasi mensuels rend l’automatisation incontournable pour éviter les interruptions de service.

Comparaison avec les autres grands chantiers cryptographiques de 2026

SC-081v3 n’est qu’un chantier parmi plusieurs qui redessinent la cryptographie appliquée cette année. À l’échelle française, l’ANSSI mène en parallèle sa propre bascule vers la cryptographie post-quantique, avec une échéance de certification fixée à 2027. Ces deux réformes n’ont pas la même origine : l’une vient du secteur privé via le CA/Browser Forum, l’autre d’une agence d’État. Elles convergent pourtant vers un même message adressé aux équipes techniques, celui d’une cryptographie qui ne peut plus être figée pour des années sans intervention.

La comparaison la plus frappante concerne le rythme. Là où l’ANSSI fixe une échéance ferme unique, 2027 pour la certification et 2030 pour les achats, le CA/Browser Forum impose un calendrier en paliers successifs qui laisse le temps aux acteurs de s’adapter, de 200 à 100 puis à 47 jours. Les deux approches partagent cependant un même diagnostic : une infrastructure cryptographique figée pendant des années représente un risque que ni les régulateurs ni les navigateurs ne sont plus prêts à tolérer. Notre dossier sur la certification post-quantique de l’ANSSI détaille ce second chantier plus en profondeur.

Cinq prédictions pour la suite

  1. D’ici mars 2027, la plupart des grandes entreprises européennes auront basculé leurs certificats publics vers une gestion ACME entièrement automatisée, ne serait-ce que pour éviter les interruptions de service.
  2. La part de marché de Let’s Encrypt devrait continuer de progresser au-delà de ses 54,5 % actuels, portée par son avance sur les cycles courts et la gratuité du service.
  3. Les éditeurs d’outils de gestion des identités machine devraient voir leurs ventes accélérer en Europe entre 2026 et 2028, les équipes IT cherchant à centraliser le suivi de parcs de certificats à rotation rapide.
  4. Le palier de mars 2027, à 100 jours, révélera probablement les premiers vrais points de friction, notamment chez les administrations et PME qui n’auront pas anticipé la bascule vers l’automatisation.
  5. La pression combinée du calendrier SC-081v3 et de la migration post-quantique poussée par l’ANSSI devrait accélérer, en France, l’adoption d’outils de gestion centralisée du cycle de vie cryptographique, une catégorie encore peu développée dans les PME comparée aux grands groupes.

Foire aux questions

Qu’est-ce que le ballot SC-081v3 ?

C’est le texte adopté par le CA/Browser Forum le 11 avril 2025 qui réduit progressivement la durée de validité maximale des certificats SSL/TLS publics, de 398 jours jusqu’à 47 jours d’ici le 15 mars 2029.

Quelle est la durée de validité maximale d’un certificat SSL/TLS en août 2026 ?

Depuis le 15 mars 2026, la limite est de 200 jours. Elle passera à 100 jours le 15 mars 2027, puis à 47 jours le 15 mars 2029.

Pourquoi réduire la durée de vie des certificats ?

Un certificat à courte durée de vie réduit la fenêtre pendant laquelle une clé privée compromise ou une validation de domaine obsolète peut être exploitée. Il force aussi les organisations à automatiser leur gestion, ce qui limite les oublis de renouvellement.

Faut-il obligatoirement utiliser Let’s Encrypt ?

Non. Toute autorité de certification publique reconnue par les navigateurs, DigiCert, Sectigo, Google Trust Services ou GoDaddy entre autres, doit respecter le même calendrier. Let’s Encrypt reste l’option gratuite la plus utilisée, avec 54,5 % des certificats émis selon les données de juin 2026.

Comment automatiser le renouvellement de mes certificats ?

Le protocole ACME, via des clients comme Certbot, permet d’automatiser entièrement la demande, la validation et le renouvellement des certificats. La plupart des grandes autorités de certification, dont Let’s Encrypt, DigiCert et Sectigo, proposent une intégration ACME native.

Cette réforme concerne-t-elle les certificats internes d’entreprise ?

Pas directement. SC-081v3 s’applique aux certificats émis par des autorités publiques reconnues par les navigateurs. Les certificats internes signés par une autorité privée ne sont pas soumis à cette limite, sauf si l’organisation choisit de s’aligner volontairement sur les mêmes bonnes pratiques.

Cette réforme a-t-elle un lien avec la cryptographie post-quantique ?

Pas directement. SC-081v3 porte sur la durée de vie des certificats, pas sur les algorithmes post-quantiques. Les deux chantiers avancent en parallèle et concernent souvent les mêmes équipes techniques, ce qui explique pourquoi ils sont fréquemment évoqués ensemble.

Sur le même sujet