blacksloth.fr

Certificats TLS : de 398 à 47 jours, cinq questions pour comprendre la bascule

Sur le Web, le petit cadenas du navigateur repose sur un certificat TLS : un document signé par une autorité de certification, qui lie un nom de domaine à une clé cryptographique. Ce document a une date d’expiration, et celle-ci est en train de raccourcir fortement. Un vote du CA/Browser Forum, l’instance où siègent autorités de certification et éditeurs de navigateurs, a fixé en 2025 une trajectoire qui mène de 398 jours à 47 jours. Le 7 octobre 2026, Let’s Encrypt a ajouté sa propre échéance, plus rapprochée. Voici cinq questions pour s’y retrouver, en partant des textes plutôt que des commentaires.

1. Que décide exactement le ballot SC-081v3 ?

Le ballot SC-081v3 a été soumis au vote du 4 au 11 avril 2025. Côté autorités de certification, 25 ont voté pour, aucune contre, et 5 se sont abstenues (Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems et TWCA). Côté « utilisateurs » de certificats, Apple, Google, Microsoft et Mozilla ont voté pour. Le quorum, fixé à 16, était atteint. La proposition est portée par Clint Wilson (Apple), avec le soutien de représentants de Sectigo, de Google Chrome et de Mozilla.

Le texte modifie les « Baseline Requirements », le règlement commun des certificats TLS de serveur de confiance publique. Dans la version du texte jointe au ballot (un brouillon daté du 1er mars 2025, publié pour la période de revue), la section 6.3.2 fixe des plafonds selon la date d’émission du certificat :

Certificat émis… Durée de validité maximale
avant le 15 mars 2026 398 jours
du 15 mars 2026 au 14 mars 2027 200 jours
du 15 mars 2027 au 14 mars 2029 100 jours
à partir du 15 mars 2029 47 jours

Le texte ajoute une nuance : la limite stricte (« MUST NOT ») est d’un jour supérieure à la limite recommandée (« SHOULD NOT »), soit 47 jours pour la première et 46 pour la seconde en 2029. Il précise qu’un jour se compte en 86 400 secondes, et que les autorités ne devraient pas émettre par défaut la durée maximale permise. On peut en déduire que les autorités auront intérêt à rester un peu en dessous du plafond. Selon ce calendrier, la première étape, à 200 jours, est déjà en vigueur à la date de cet article.

2. Il n’y a pas que la durée du certificat : la validation raccourcit aussi

Avant d’émettre un certificat, l’autorité vérifie que le demandeur contrôle bien le domaine. Le ballot encadre aussi la durée pendant laquelle cette vérification peut être réutilisée. Selon la section 4.2.1 du même texte, la réutilisation d’une validation de nom de domaine ou d’adresse IP suit la même échelle que la validité : 398 jours avant le 15 mars 2026, 200 jours ensuite, 100 jours à partir du 15 mars 2027, puis 10 jours à partir du 15 mars 2029.

Les informations d’identité de l’organisation relèvent d’une autre règle : leur durée de réutilisation passe de 825 à 398 jours pour les certificats émis à partir du 15 mars 2026. Cette distinction compte pour les certificats qui affichent une identité d’entreprise, mais le gros du changement, pour la plupart des sites, tient aux deux échelles de la validité et de la validation de domaine.

3. Pourquoi raccourcir ?

La page du ballot avance un argument central sur la révocation, le mécanisme qui permet d’invalider un certificat avant son terme. Selon cette page, s’en remettre à la seule révocation est « untenable for a number of reasons » (« intenable pour plusieurs raisons », traduit par nos soins). À l’inverse, elle juge que « Certificate validity periods, and their enforcement by relying parties, are incredibly reliable » : une date d’expiration, elle, est respectée de façon très fiable par les navigateurs et les autres clients.

Raccourcir la durée de vie limite donc mécaniquement le temps pendant lequel un certificat volé ou émis par erreur reste exploitable. Dans son compte rendu du vote, The Register rapporte que les partisans de la mesure parlent de quelques jours ou semaines d’exposition, contre plusieurs mois auparavant. Un second argument figure dans la liste des bénéfices du ballot : des durées plus courtes facilitent la transition d’une cryptographie vers une autre, puisque tous les certificats se renouvellent plus vite. Enfin, la réduction de la réutilisation de validation répond à une logique voisine : une preuve de contrôle d’un domaine, vieille de plusieurs mois, peut ne plus refléter la réalité.

On peut y voir une conséquence assumée : la sécurité du Web public se déplace de la correction d’incidents vers l’automatisation du renouvellement. C’est une lecture, non une citation, mais elle se retrouve dans la couverture : la presse spécialisée, comme IT-Connect en avril 2025, souligne que sans automatisation la gestion deviendrait ingérable pour les administrateurs.

4. Qui est concerné, et que fait Let’s Encrypt ?

Le titre du document modifié par le ballot vise les « certificats de serveur TLS de confiance publique » (« Publicly-Trusted TLS Server Certificates »). Les sources lues ne détaillent pas plus ce périmètre : si votre cas relève d’une autorité privée, reportez-vous au texte des Baseline Requirements.

Let’s Encrypt n’attend pas 2029. Dans son billet du 7 octobre 2026, Sarah Gran annonce que les certificats de 64 jours sont disponibles dans l’environnement de test (« staging ») depuis le 14 octobre 2026, selon l’annonce. À partir du 10 février 2027, la durée par défaut sera de 64 jours, sauf pour les abonnés qui choisissent une durée plus courte (45 ou 6 jours, comme déjà annoncé). Le dernier certificat de 90 jours devrait expirer le 11 mai 2027. La période de réutilisation des autorisations, c’est-à-dire des validations de domaine, passe de 30 à 10 jours, avec pour motif la conformité à la réduction de 2029. Le billet présente le 64 jours comme une préparation à des durées par défaut de 45 jours en 2028, et indique qu’en 2028 la réutilisation sera ramenée à sept heures. Il explique ce choix ainsi : les durées plus courtes réduisent « the risk of key compromise and mis-issuance » (le risque de compromission de clé et d’émission erronée). Help Net Security a repris ces dates le 12 octobre 2026.

Ce sont deux calendriers distincts. Le billet de Let’s Encrypt ne nomme d’ailleurs pas le CA/Browser Forum : le 64 jours de février 2027 est un choix de l’autorité, plus rapide que les 200 jours puis 100 jours qu’exige le règlement commun à ces dates. Let’s Encrypt précise par ailleurs qu’il ne révoquera pas les certificats valides dans le cadre de cette transition.

5. Que faire concrètement ?

Le premier réflexe est de vérifier si le renouvellement est automatisé. Let’s Encrypt est clair sur ce point : si les renouvellements sont automatiques et que le client prend en charge ACME Renewal Info (ARI), « you should be all set » (« tout devrait bien se passer »). L’ARI permet à l’autorité d’indiquer au client le bon moment pour renouveler. Pour les installations qui renouvellent à date fixe, le billet recommande de viser environ deux tiers de la durée de vie du certificat, et de rechercher dans les tâches planifiées, scripts et procédures les valeurs codées en dur telles que 83, 80 ou 60 jours. Il conseille aussi d’automatiser le rechargement et le déploiement des certificats et de mettre des alertes en cas d’échec de renouvellement.

Pour la validation, le billet indique que, sauf client ACME conçu pour s’appuyer sur la réutilisation de validation, aucune modification n’est nécessaire (« you will not need to make any changes », cité par Help Net Security). Pour la configuration précise de votre logiciel, la documentation de votre client ACME et celle de votre autorité de certification font foi : nous ne détaillons pas ici de réglages que nous n’avons pas pu sourcer.

Le cas des équipements qui ne savent pas automatiser est le plus délicat, et aucune des sources lues ne le règle. Un administrateur de Reddit, cité par The Register, juge le changement acceptable sur le plan de la sécurité mais lourd en travail manuel, notamment à cause du matériel hérité. Daniel V. Bailey, cité par InfoQ en mai 2025, reconnaît que « in practice, companies will have legacy systems and appliances where they can’t easily automate ».

Les désaccords et les limites

Les critiques portent surtout sur la charge d’exploitation. DigiCert, autorité de certification qui a voté pour, estime dans un billet du 16 mai 2025 que l’automatisation devient essentielle, et qu’une revalidation manuelle serait « a recipe for failure and outages » (une recette pour les pannes). Le même billet relève que l’intervalle irrégulier entre les étapes, notamment entre 2027 et 2029, peut prêter à confusion. Pour cette autorité, le coût ne change pas, car la facturation repose sur un abonnement annuel : c’est son argument commercial, à lire comme tel.

Autre réserve, celle de Daniel V. Bailey, qui s’interroge sur l’existence de données empiriques démontrant l’intérêt de la mesure, tout en reconnaissant que la révocation est peu fiable. Un utilisateur de Reddit cité par InfoQ pointe pour sa part le coût de l’automatisation pour les entités publiques. Ces voix sont minoritaires dans les sources que nous avons lues, majoritairement favorables, et DigiCert, vendeur de solutions de gestion de certificats, a un intérêt commercial évident à insister sur l’automatisation.

Ce que l’on ne sait pas

Le billet de Let’s Encrypt annonce 45 jours « en 2028 », sans date précise : nous n’en donnons pas. Le calendrier de la réduction à 47 jours, lui, court jusqu’en 2029, et les sources lues ne disent pas si les étapes pourraient être révisées. Elles ne fournissent pas non plus de mesure chiffrée du nombre d’équipements publics encore renouvelés à la main, ni de bilan des incidents évités. Enfin, la version du règlement que nous avons lue est celle jointe au ballot, un brouillon destiné à la période de revue : pour une obligation contractuelle, c’est la dernière version publiée des Baseline Requirements sur le site du CA/Browser Forum qui fait référence.

À retenir et à surveiller

L’étape à 200 jours est déjà en vigueur selon le calendrier du ballot ; la suivante, à 100 jours, vise les certificats émis à partir du 15 mars 2027. Du côté de Let’s Encrypt, la durée par défaut passera à 64 jours le 10 février 2027, et un environnement de test est disponible depuis le 14 octobre 2026, selon l’annonce. Le geste utile reste le même : vérifier que le renouvellement est automatisé, chercher les durées codées en dur dans les scripts et prévoir des alertes en cas d’échec.

Sources

In

, , , ,
Enable Notifications OK No thanks