Vers un renouvellement mensuel des certificats

Fin 2024, Apple a surpris tout le monde en décidant de réduire la durée de vie maximale des certificats à seulement 45 jours. Il a fallu quelques mois et deux ou trois petites révisions, mais en avril 2025, la mesure a été adoptée via le vote SC-081v3 du CA/Browser Forum. Si vous ne le saviez pas déjà, il s’agit d’un changement plutôt radical, passant de la durée maximale autorisée actuelle de 398 jours à seulement 47 jours en mars 2029. Il ne faut pas traîner, car il existe deux étapes intermédiaires : la première réduction est fixée à 200 jours en mars 2026 (très bientôt !) et la deuxième à 100 jours en mars 2027.

En pratique, nous passons d’un renouvellement annuel aujourd’hui, à deux renouvellements par an en 2026, puis à un renouvellement trimestriel en 2027, et enfin à un renouvellement mensuel en 2029. 

En conséquence, tout le monde s’active pour localiser ses certificats publics avant de mettre en place l’automatisation. Sur le long terme, ces changements seront bénéfiques, mais la charge de travail supplémentaire à court terme représente un vrai fardeau pour beaucoup.

Let's Encrypt, l’AC gratuite qui délivre la majorité des certificats dans le monde et pionnière des certificats à 90 jours, adoptera un calendrier encore plus ambitieux : leurs certificats passeront à 45 jours dès février 2028. Cela ne devrait pas trop vous préoccuper. Leurs certificats sont toujours émis automatiquement, ce qui signifie qu’il n’y aura rien à faire, si ce n’est observer le changement.

Il existe de nombreux arguments solides en faveur de certificats à durée de vie plus courte. Considérez les points suivants :

• Le renouvellement manuel est une perte de temps. D’innombrables heures de travail ont été consacrées à planifier, coordonner et exécuter cette tâche fastidieuse. De plus, chaque modification manuelle risque de causer une panne, qu’il faudra ensuite corriger, nécessitant d’autres ressources. Le renouvellement manuel devient irréaliste lorsque la durée de vie des certificats est courte, ce qui va imposer à tous la mise en place d’une automatisation. À long terme, tout le monde s’en portera mieux.
• Le renouvellement automatisé est agile. Les PKI publiques accordent énormément d’attention à la conformité des certificats. Être strict évite de longues discussions pour déterminer si une erreur mérite d’être classée comme une mauvaise délivrance. L’écosystème a choisi la rigueur afin d’éviter ces débats. De ce fait, lorsqu’une erreur survient, elle doit être corrigée — même sans impact pratique. Un renouvellement forcé dû à une faute d’une AC n’est jamais bien perçu par les clients, mais l’automatisation est une solution idéale. Dans le RFC 9773, ACME a été étendu pour permettre aux AC de déclencher le renouvellement automatisé des certificats défaillants.
• Des durées de vie plus courtes favorisent l’agilité cryptographique. À l’époque, on utilisait la fonction de hachage SHA1 pour les signatures de certificats, avant de s’apercevoir que cette fonction était cassée. La migration vers SHA2 a été très lente, notamment à cause des certificats longue durée encore en circulation avec SHA1. Les navigateurs ne pouvaient donc pas simplement cesser de les accepter sans provoquer d’importantes ruptures. Avec des durées de vie plus courtes, il sera bien plus facile de gérer des situations similaires.
• La vérification de la révocation n’est pas pratiquée. Il y a quelques années, les principaux navigateurs ont décidé de renoncer à la vérification de la révocation, invoquant des problèmes de performance, de disponibilité et de confidentialité. (Firefox fait figure d’exception et a mis en place un système appelé CRLite, actuellement en place sur leurs plateformes de bureau.) Cela crée une situation problématique : lorsqu’un certificat est compromis, la fenêtre d’exploitation peut durer jusqu’à 398 jours. Réduire la durée de vie du certificat est la seule solution fiable à ce problème.
• Les certificats résiduels existent partout. Il est désormais rare d’obtenir ses propres certificats. Nous nous inscrivons plutôt sur des plateformes qui les obtiennent pour nous. C’est tout le flou du système : ces certificats portent nos noms de domaine mais sont sous le contrôle de tiers. À qui appartiennent-ils ? Lorsqu’on change de fournisseur, les anciens certificats restent actifs… quelque part. Idem lors d’un transfert de propriété de domaine : l’ancien propriétaire conserve un pouvoir sur un domaine qui ne lui appartient plus. Plus d’informations dans cet article de recherche. Des durées de vie plus courtes réduiront également l’impact de ce problème.

Il est évident que ces changements sont bénéfiques, mais moins clair d’expliquer pourquoi s’arrêter à 47 jours. On pourrait soutenir qu’un palier à 90 jours remplirait la même fonction, tout en réduisant la pression sur les systèmes d’émission et de surveillance. Inversement, on peut imaginer une nouvelle réduction des durées maximales à l’avenir… mais il sera difficile de la justifier pour tout le monde.

Dans leur rapport annuel 2024, l’Internet Security Research Group (ISRG, créateur de Let's Encrypt) a poussé la logique à l’extrême en annonçant des certificats de six jours pour 2025. Cela n’aura guère de sens pour la plupart des organisations, mais c’est idéal pour celles qui veulent réduire au maximum la période de vulnérabilité liée à un certificat compromis. Dans le pire des cas, la fenêtre d’exposition n’est que de six jours. C’est en fait mieux que ce que garantissait la vérification de révocation en ligne (dans la pratique), soit sept jours.

Je suis amateur d’archéologie PKI, et j’ai donc pris le temps de remonter l’évolution historique des durées maximales de certificats. D’une certaine manière, l’évolution de ces règles est le reflet du passage des PKI publiques d’un fonctionnement « far west » à un environnement strictement réglementé et surveillé, comme aujourd’hui. On y retrouve presque une dimension de soap opera.

Les premières restrictions ont été introduites avec la première version du document « Baseline Requirements » (BR) du CA/Browser Forum, qui définit les modalités de délivrance des certificats. Avant BR, il n’y avait aucun plafond, et il était possible d’obtenir un certificat valable dix ans. La première version du BR a plafonné la durée à 60 mois en 2012, avec une réduction prévue à 39 mois, repoussée à 2015.

Deux ans plus tard, en 2017, la première tentative (vote Ballot 185) pour limiter la durée à 398 jours a échoué. Pratiquement toutes les AC ont voté « non ». Fait intéressant, deux éditeurs de navigateurs ont également voté « non » et un s’est abstenu. Cependant, un mois plus tard, le Ballot 193 a été adopté, réduisant la durée de vie maximale à 825 jours.

Deux ans après, en octobre 2019, la deuxième tentative (vote Ballot SC-022v2) de réduire à 398 jours a également échoué. Là encore, les AC n’étaient pas favorables. D’après les motifs avancés, la principale raison était l’augmentation de la charge client. Faire quelque chose deux fois plus souvent coûte deux fois plus cher. Les navigateurs n’en souffrent pas, mais les AC oui, ce qui a fait ressortir une fracture profonde entre navigateurs et AC.

Au final, même si Google était à l’origine de SC022, c’est Apple qui a décidé unilatéralement et, lors de la réunion CA/Browser Forum de février 2020, a annoncé qu’à partir de septembre 2020, elle n’accepterait plus les nouveaux certificats valides plus de 398 jours. Officiellement, la modification du BR a eu lieu via le Ballot SC-031, intitulé avec enthousiasme « Browser Alignment ».

Comme vous le savez désormais, Apple était également à l’origine de la récente accélération vers 47 jours. Cette fois-ci, la plupart des AC ont voté pour la proposition. Difficile de dire combien l’ont réellement voulu et combien n’avaient pas le choix.

Honnêtement, la situation en 2025 paraît bien meilleure côté automatisation, après 10 ans d’émission automatisée via Automatic Certificate Management Environment (ACME). On se dit qu’une automatisation complète est à portée de main ? Le vote indique aussi clairement une adoption progressive, permettant de faire marche arrière en cas d’obstacle majeur.

Un examen attentif du Ballot SC-081v3 (qui a instauré la réduction finale des durées de certificats) montre qu’une diminution similaire s’applique aux délais de réutilisation de validation. Si vous ne connaissez pas bien la PKI, vous ne savez peut-être pas que les validations de certificats sont réutilisables, mais c’est le cas.

Autrefois, quand l’essentiel de la validation était manuel, la possibilité de réutiliser les résultats était un sacré gain de temps pour les clients et les AC. Les AC validaient périodiquement leurs clients et domaines, ce qui permettait ensuite d’émettre des certificats [pour leurs propriétés] quasiment instantanément. Ceux qui ont déjà vécu une validation manuelle savent que cela pouvait prendre des jours. Cette méthode était logique et faisait gagner énormément de temps à tous.

Pour la validation de l’identité du sujet (exemple : identité de l’organisation), la limite actuelle est de 825 jours, mais elle va passer à 398 jours en mars 2026, sans nouvelle réduction prévue. Cette tâche étant manuelle et complexe, il est logique d’autoriser une réutilisation plus longue.

En revanche, la réutilisation des validations de noms de domaine et d’adresses IP — qui peut être entièrement automatisée — suivra la même trajectoire que les durées des certificats, le dernier seuil étant fixé à seulement 10 jours.

Ces évolutions sont un nouveau pas vers une automatisation généralisée de tout ce qui peut l’être. Elles s’inscrivent dans un ménage global, qui inclut aussi l’abandon des anciennes méthodes de validation comme WHOIS, l’email et le téléphone (par exemple SC-090, SC-091 et SC-080v3). Résultat : les propriétaires de domaines auront plus de contrôle sur les entités autorisées à émettre pour leurs domaines. Cela n’implique pas nécessairement plus de travail pour quiconque, car de nouvelles fonctionnalités sont en préparation pour permettre une signalisation continue des autorisations, comme un enregistrement DNS persistant pour la validation de domaine (également prévu dans SC-091).