Avec le raccourcissement de leur durée de vie, la multiplication des identités machines et la préparation au post-quantique, les certificats numériques changent d’échelle. Un mouvement qui oblige les entreprises à mieux connaître leur patrimoine cryptographique, mais aussi à repenser sa gestion. Yona Brawerman, fondatrice de Klarion Technologies, et Jean-Julien Alvado, CTO et cofondateur d’Evertrust, reviennent sur un sujet longtemps resté dans les coulisses du SI.
Pendant longtemps, un certificat numérique pouvait presque se faire oublier. On le déployait, on inscrivait éventuellement une date de renouvellement dans un calendrier ou un fichier Excel, puis on y revenait plusieurs mois plus tard. Cette façon de travailler arrive doucement en bout de course. Le raccourcissement programmé de la durée de vie des certificats TLS publics accélère le mouvement. Après le passage à 200 jours en 2026, leur durée maximale doit tomber à 100 jours en 2027 puis à 47 jours en 2029. Pour Yona Brawerman, fondatrice de Klarion Technologies, la conséquence est assez directe : « Ce qui était possible et réalisable manuellement ne l’est plus du tout. »
Même constat chez Evertrust. Jean-Julien Alvado, CTO et cofondateur de l’entreprise, parle d’un passage d’une gestion « de l’ordre de l’événementiel » à quelque chose qui relève désormais du « flux continu ». Avec 1 000 certificats publics, illustre-t-il, il ne s’agit plus d’effectuer environ 1 000 renouvellements par an, mais de multiplier fortement ces opérations à mesure que leur durée de vie diminue. Et renouveler le certificat ne représente qu’une partie du travail car il faut aussi le redéployer, le réinstaller et vérifier son bon fonctionnement.
Avant d’automatiser, encore faut-il savoir ce que l’on possède
Le premier obstacle n’est pourtant pas nécessairement le renouvellement. Il se situe souvent bien avant, dans la connaissance même des certificats présents dans le système d’information. « Il y a pas mal de zones grises », constate Yona Brawerman, pour qui très peu d’entreprises disposent aujourd’hui d’un inventaire réellement exhaustif et centralisé. Entre réseau, serveurs, différents clouds et applications, la visibilité existe parfois, mais reste partielle.
Même les organisations les plus matures n’échappent pas totalement au problème. Jean-Julien Alvado évoque des certificats émis en dehors des circuits officiels, des PKI historiques oubliées dans un coin du SI, celles embarquées dans des environnements Kubernetes ou OpenShift, des certificats autosignés ou encore des certificats publics obtenus directement par des développeurs.
Et puis il y a le classique certificat wildcard, déployé à de nombreux endroits avec une même clé privée, parfois sans que personne ne sache précisément où elle se trouve. Un fonctionnement qui facilite les opérations au départ, mais qui peut aussi étendre considérablement la surface de risque si cette clé est compromise.
Ce manque de visibilité pourrait devenir d’autant plus problématique que les renouvellements vont s’accélérer. Yona Brawerman redoute ainsi que certaines entreprises finissent par être « éduquées par la panne » c’est-à-dire découvrir le changement lorsqu’un certificat non renouvelé provoque une interruption de service. Selon elle, les grands groupes ont déjà commencé à se mettre en ordre de marche, quand la prise de conscience reste plus disparate dans les PME et ETI. « Le premier sujet que je vois, c’est l’éducation », insiste-t-elle.
Automatiser, mais sans simplement déplacer le problème
Face à ces volumes et à ces fréquences de renouvellement, l’automatisation apparaît difficilement évitable. Elle ne règle cependant pas tout. « L’automatisation ne va pas supprimer le risque, mais elle va le déplacer vers des problématiques de gouvernance », résume Jean-Julien Alvado.
Premier point de vigilance : les droits. Lorsqu’un outil central est capable d’émettre ou de renouveler automatiquement des certificats, encore faut-il maîtriser précisément qui peut demander quoi, pour quel système et dans quelles conditions. Le deuxième sujet, ce sont les clés privées. D’après les architectures, celles-ci peuvent être générées directement sur l’équipement qui utilisera le certificat, ou au contraire être créées de manière centralisée avant d’être distribuées. Dans le second cas, le CLM devient lui-même un coffre particulièrement sensible.
Enfin, automatiser un déploiement suppose souvent de donner au système central des accès élevés à des équipements tiers, via des API notamment. Firewalls, serveurs ou autres briques critiques peuvent ainsi se retrouver accessibles depuis l’outil de gestion des certificats. Cela ne signifie pas que l’automatisation augmente nécessairement le risque. Elle le rend plutôt différent. Pour le CTO d’Evertrust, ces problèmes ont au moins l’avantage de pouvoir être contrôlés et audités, là où une gestion manuelle reste très dépendante de l’erreur humaine.
La question de la dépendance se pose également vis-à-vis des fournisseurs. Yona Brawerman insiste sur la nécessité de conserver la possibilité de changer d’autorité de certification. Dans un environnement où une même entreprise peut utiliser plusieurs fournisseurs, elle défend une gestion agnostique afin d’éviter un nouveau verrouillage technologique. « On ne peut pas être dépendant », estime-t-elle, rapprochant le sujet d’autres situations de lock-in déjà rencontrées dans l’IT.
Les identités machines font exploser les volumes
À ce premier changement s’en ajoute un autre : les certificats ne servent plus seulement à sécuriser quelques sites Web. API, conteneurs, workloads cloud, objets connectés et désormais agents IA multiplient les identités non humaines devant pouvoir s’authentifier entre elles. Pour Jean-Julien Alvado, cela pose trois problèmes à la fois : le volume, la vitesse et la responsabilité. Certains de ses clients gèrent déjà « des certificats en dizaines de millions par an ». Et contrairement aux certificats Web classiques, certaines identités machines peuvent n’avoir qu’une durée de vie de quelques minutes.
À 500 000 identités, avec des certificats régulièrement renouvelés en quelques minutes, le changement d’échelle devient évident. Reste une question moins technique mais tout aussi importante : à qui appartient chaque certificat et qui est responsable de son cycle de vie ?
Yona Brawerman observe là encore des maturités très différentes selon les organisations. Les grandes entreprises ont commencé à intégrer le sujet, estime-t-elle, tandis qu’une petite structure qui utilise progressivement davantage de services numériques ou d’agents IA n’a pas nécessairement encore conscience des mécanismes d’identité qui se cachent derrière. À terme, la frontière entre gestion des certificats et gestion des identités machines pourrait d’ailleurs devenir de moins en moins nette. Pour la fondatrice de Klarion, les mécanismes utilisés aujourd’hui sur le Web vont progressivement « arriver plus largement sur les agents IA ».
Inventorier, rationaliser, puis automatiser
Alors, par où commencer lorsque le SI compte déjà des centaines ou des milliers de certificats dispersés ? Pour Evertrust, la première étape reste la découverte : savoir quelles autorités de certification sont utilisées, quels types de certificats existent et où ils sont déployés. Mais l’inventaire seul ne suffit pas. Il faut ensuite rattacher chaque certificat à un propriétaire ou à une équipe responsable de son usage, puis rationaliser : définir quelles autorités sont autorisées pour quels usages, fermer certaines pratiques historiques et mettre en place une véritable politique cryptographique.
L’automatisation arrive ensuite, progressivement et en fonction des cas d’usage. Surtout, il ne faut pas attendre d’avoir terminé l’inventaire pour avancer sur le reste. « L’inventaire […] ne se finira jamais », prévient Jean-Julien Alvado. De nouveaux certificats apparaissent, d’autres disparaissent : la cartographie devient elle-même un processus continu.
Cette logique rejoint le constat de Klarion : avec des certificats qui vivent, sont révoqués, renouvelés et déplacés, l’inventaire doit lui aussi être constamment remis à jour. À cela s’ajoutent les journaux permettant de savoir qui a manipulé quel certificat et à quel moment. La gestion finit alors par devenir un outil à part entière plutôt qu’un simple tableau de suivi.
Le post-quantique commence par savoir où se trouve sa cryptographie
Cette connaissance du patrimoine prend une autre dimension avec la transition post-quantique. Pour Yona Brawerman, il ne suffira pas de remplacer un algorithme par un autre. Une fois le nouvel algorithme choisi, encore faut-il que le certificat puisse être accepté et déployé sur les endpoints existants. Latence, compatibilité ou version des équipements risquent alors de devenir des problèmes très concrets.
« C’est une chose d’avoir un algorithme. C’est autre chose d’avoir un nouveau certificat. Et c’est encore autre chose d’avoir un nouveau certificat qui est déployable sur l’endpoint existant », explique-t-elle. Certaines infrastructures pourraient même se révéler trop anciennes pour suivre la migration.
Evertrust élargit encore le périmètre. Préparer le post-quantique ne consiste pas seulement à inventorier les certificats, mais aussi les protocoles, bibliothèques cryptographiques, clés de chiffrement, applications ou matériels qui les utilisent.
Les systèmes les plus sensibles et les données qui devront rester confidentielles pendant de longues années sont naturellement prioritaires. Le scénario harvest now, decrypt later repose justement sur la conservation aujourd’hui de données chiffrées dans l’espoir de pouvoir les déchiffrer demain.
Jean-Julien Alvado cite également les problématiques de signature de logiciels installés sur des équipements dont la durée de vie peut atteindre quinze ou vingt ans, comme certaines voitures ou certains avions. Sa recommandation tient finalement en une formule assez simple : « essayer de ne pas créer de dette ». Tester dès maintenant les mécanismes hybrides disponibles, vérifier les feuilles de route des fournisseurs lors de l’achat d’un firewall ou d’un équipement et s’assurer qu’il pourra évoluer lorsque la migration sera nécessaire.
Le certificat numérique n’est donc plus seulement ce petit élément technique dont on se souvient le jour où un navigateur affiche une alerte ou lorsqu’un service tombe. Sa durée de vie raccourcit au moment même où son usage s’étend à des volumes beaucoup plus importants d’identités machines. Et derrière la question apparemment simple du renouvellement se dessine déjà un chantier plus large : connaître réellement les usages cryptographiques d’un SI avant d’avoir à les faire évoluer.
