Secu
Certificats TLS plus courts : industrialiser pour survivre
Par Thierry Derouet, publié le 15 décembre 2025
D’ici 2029, les certificats TLS (Transport Layer Security) ne vivront plus que 47 jours. Une décision portée par Google, Microsoft, Apple et validée par le CA/Browser Forum. Pour les RSSI, il faudra tourner la page des fichiers Excel et accepter une évidence : la gestion des certificats doit devenir industrielle, automatisée et gouvernée.
Le cadenas de votre navigateur lors d’une connexion HTTPS ? Un symbole, celui de la présence du certificat numérique qui joue le rôle d’une carte d’identité pour le serveur auquel vous vous connectez et atteste de l’utilisation d’une clé de cryptage protégeant vos échanges.
Ces certificats, émis au format X.509 par une autorité de certification (AC), comportent notamment deux champs, NotBefore et NotAfter, qui fixent leur période de validité. Tant qu’ils sont dans cette fenêtre, ils sont acceptés par le navigateur et permettent d’établir une connexion HTTPS chiffrée.
En cas de compromission ou de dépassement des délais, les règles du CA/Browser Forum imposent une révocation sous 24 heures.
Mais les mécanismes de révocation – qu’il s’agisse des CRL (listes de certificats révoqués) ou de l’OCSP (protocole de vérification en ligne) – sont souvent mal implémentés ou ignorés, si bien qu’un certificat compromis peut continuer à être utilisé, lors de communications mal sécurisées donc.
Sans certificat valide, pas de confiance
La durée de vie des certificats (délai entre le NotBefore et le NotAfter) n’a cessé de raccourcir. De cinq puis trois ans, on est passé en 2018, à 825 jours (deux ans et trois mois). Au 1er septembre 2020, Apple a officiellement limité à 398 jours la durée de validité sur iOS et macOS, rapidement suivi par Chrome, Firefox et Edge.
En avril 2025, le CA/Browser Forum a voté un plan encore plus drastique : 200 jours dès mars 2026, 100 jours en 2027, et seulement 47 jours à partir de mars 2029.
« Certains évoquent même dix jours à terme », souligne Romain Quinat, chief marketing officer du groupe Nomios, intégrateur œuvrant dans le domaine de la cybersécurité.
Google, de son côté, avait déjà ouvert le débat en mars 2023 dans son document Moving Forward Together, plaidant pour une durée maximale de 90 jours.
Une logique sécuritaire, l’autre opérationnelle
Deux logiques expliquent cette accélération. La première est sécuritaire. Plus un certificat reste en circulation longtemps, plus sa clé privée est exposée. Et demain, l’ordinateur quantique pourrait accélérer la capacité de casser des clés cryptographiques aujourd’hui jugées robustes. « Le raccourcissement des durées vise surtout à anticiper la fragilisation des algorithmes asymétriques (RSA, ECC) à l’ère post-quantique. »
La seconde raison est opérationnelle. Il s’agit, en rendant quasiment impossible une gestion « manuelle » de certificats à renouveler plus souvent, de forcer les organisations à automatiser ces renouvellements, ainsi que la vérification de la validité des certificats en usage.
Romain Quinat
Chief marketing officer du groupe Nomios
« Nous aidons nos clients à industrialiser leur gestion. L’idée n’est pas de multiplier les certificats, mais d’éviter que leur complexité devienne un point de fragilité. »
Une usine à mettre en place
Pour une PME dotée d’un simple site vitrine, la contrainte reste supportable : il suffit de s’appuyer sur un acteur comme Let’s Encrypt, qui renouvelle automatiquement les certificats tous les 90 jours.
Mais à l’échelle d’un grand groupe, le décor change radicalement. Sa DSI doit veiller sur des milliers de certificats disséminés dans le SI : sites internes, applications métiers, API, messagerie, VPN… La moindre négligence peut se transformer en incident majeur.
Des exemples ? En 2021, un certificat oublié a suffi à plonger Facebook dans le noir pendant plusieurs heures, entraînant une panne mondiale. En février 2021, c’est Google Voice qui est resté hors service plus de quatre heures à cause d’un certificat TLS expiré, conséquence d’un renouvellement manqué. Même scénario en février 2020 pour Microsoft Teams, tombé en panne durant trois heures, privant ses millions d’utilisateurs d’accès à la messagerie et aux appels, là encore pour un certificat d’authentification périmé. Ces incidents rappellent qu’un simple oubli peut suffire à créer une interruption massive de service – et jusqu’à 15 M$ de pertes pour une grande entreprise, selon certaines estimations.
Impossible de continuer avec un simple tableur
Longtemps, la gestion des certificats s’est faite à la main. Un fichier Excel, quelques colonnes, un rappel Outlook…
« Tant qu’il y avait un renouvellement annuel, ça passait. Mais à 100 jours, et a fortiori à 47, c’est terminé », tranche Romain Quinat.
Deux chantiers s’ouvrent donc pour les RSSI. Le premier, assez simple, consiste à automatiser la demande et la réception d’un certificat auprès des autorités de certification avec le protocole ACME (Automatic Certificate Management Environment), standard largement adopté dans l’écosystème. « C’est la partie la plus simple, parce que c’est standardisé. Mais attention, encore faut-il que toutes les applications soient compatibles ACME. Dans les environnements legacy, c’est loin d’être toujours le cas. »
Le second chantier est autrement plus délicat : installer automatiquement le certificat renouvelé dans les applications, serveurs, répartiteurs de charge (load balancers), voire dans Outlook pour les certificats personnels utilisés en messagerie chiffrée. « C’est là que la vraie complexité apparaît », insiste Romain Quinat. L’obstacle n’est pas seulement technique. C’est aussi une question de responsabilité. Dans de nombreuses organisations, c’est le RSSI qui gère la relation avec l’autorité de certification, mais ce sont les responsables applicatifs qui installent les certificats. Et lorsque l’un oublie sa mission, l’autre accuse. « Avec des cycles à 47 jours, on ne pourra plus se renvoyer la balle. »
Une coopération entre RSSI et responsables applicatifs
Surtout, le RSSI n’a plus vocation à vérifier chaque date de péremption. « Le renouvellement en soi n’a aucun intérêt pour lui, affirme Romain Quinat. Son rôle, c’est la vigilance : révoquer un certificat compromis, gérer les cas de clés volées, garantir la gouvernance et la conformité. »
Les organisations les plus matures, déjà engagées dans des pratiques DevOps, pourront intégrer la gestion des certificats dans leurs pipelines CI/CD (Continuous Integration / Continuous Delivery). Les autres, encore organisées en silos, devront avancer domaine par domaine.
Ce basculement s’inscrit dans un contexte réglementaire plus large. Les textes européens comme NIS 2 (Network and Information Security Directive) ou DORA (Digital Operational Resilience Act) n’évoquent pas directement les certificats, mais imposent continuité, traçabilité et résilience. « La réduction des durées va dans ce sens, observe Romain Quinat. Les normes ne disent pas “vous devez gérer vos certificats”, mais elles fixent un cap. Les RSSI n’ont plus le choix. »
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
