Skip to content

La gestion du cycle de vie des certificats a besoin d'une plateforme de surveillance dédiée

Les outils de CLM gèrent l'émission et le renouvellement, mais les plateformes de surveillance dédiées offrent la découverte en temps réel et la visibilité sur la Certificate Transparency dont les entreprises ont réellement besoin.

Ivan Ristic·Chief Scientist
Published: January 13, 2026·5 min read

La surveillance des certificats, en tant que catégorie de produits, a toujours été un marché difficile. En partie parce qu'une grande partie de ce type de fonctionnalité se retrouve intégrée dans des outils de surveillance réseau, et en partie parce que les entreprises ont souvent quelqu'un en interne qui écrira rapidement un ou deux scripts et considérera la tâche accomplie. Ou du moins, c'est l'intention.

En pratique, ces approches ne fonctionnent jamais vraiment bien, même si elles répondent à certains besoins. La cause profonde tient au fait que la surveillance des certificats est l'un de ces problèmes qui semblent simples vus de l'extérieur ; mais rien n'est simple lorsqu'il s'agit d'infrastructures à clé publique (PKI), et la plupart des organisations l'apprennent et le réapprennent en manipulant leurs scripts.

Red Sift propose une plateforme dédiée à la surveillance des certificats et on nous demande souvent d'expliquer ce que notre produit peut faire de mieux que les solutions existantes. L'objectif de cet article est de discuter de l'état de l'art de la surveillance des certificats afin de mieux comprendre l'effort nécessaire pour concevoir un bon produit.

La gestion du cycle de vie des certificats peut-elle aider à la surveillance des certificats ?

La surveillance des certificats est souvent considérée comme faisant partie de la catégorie Certificate Lifecycle Management (CLM), qui a connu une popularité croissante ces dernières années. Les outils de CLM sont conçus pour l'orchestration des certificats. Les fournisseurs proposant de tels produits revendiquent également des capacités de surveillance, mais, d'après mon expérience, celles-ci laissent aussi beaucoup à désirer. C'est contre-intuitif, mais on pourrait s'attendre à ce que les outils de CLM disposent de bonnes capacités de surveillance des certificats, non ?

Dans le cas du CLM, la cause profonde tient au fait que l'objectif principal de ces outils est de gérer les certificats. Ce n'est pas une tâche facile car il existe une grande diversité de produits qui consomment des certificats. Les développeurs de CLM passent la plupart de leur temps à mettre en œuvre des intégrations d'automatisation, ce qui leur laisse moins de temps pour se concentrer sur la surveillance, qui finit souvent par être ajoutée en complément du produit principal.

En pratique, les CLM peuvent offrir une visibilité sur les certificats sous leur contrôle, mais ceux-ci ne représentent qu'une fraction de l'ensemble des certificats utilisés par une organisation.

À quoi ressemble l'automatisation des certificats en pratique ?

Le rêve du CLM est de déployer un seul produit qui vous donne un contrôle total sur tous vos certificats. En pratique, c'est très difficile à réaliser. Une des raisons est que l'automatisation nécessite une intégration avec de nombreuses plateformes différentes, et aucun CLM ne peut prétendre tout prendre en charge. Une petite entreprise peut se retrouver avec un seul CLM parfaitement adapté, mais une plus grande entreprise aura inévitablement plusieurs CLM, soit parce qu'ils sont nécessaires pour leurs meilleures fonctionnalités (par exemple, l'intégration avec une PKI privée particulièrement importante), soit en raison de fusions et acquisitions. À cela s'ajoutent les CDN et les serveurs externalisés. Et il faut ajouter ACME, désormais fourni par défaut dans de nombreux cas, et trop coûteux à grande échelle pour être connecté à un CLM, même lorsque cela est pris en charge.

Par conséquent, vous finissez par avoir plusieurs CLM et plusieurs déploiements ACME, mais vous n'êtes toujours pas plus proche d'une visibilité complète et d'une surveillance unifiée. Si tant est que cela change quelque chose, plusieurs CLM rendent la tâche encore plus difficile.

La solution consiste à s'appuyer sur une surveillance des certificats dédiée

Notre approche consiste à proposer une plateforme dédiée à la surveillance des certificats, où nous consacrons notre temps de développement à être très performants sur notre cœur de métier. À quoi cela ressemble-t-il ? Eh bien, considérez les aspects généraux suivants :

  • Découverte automatisée de l'infrastructure et surveillance approfondie de l'infrastructure ; ces aspects sont nécessaires pour éviter de dépendre d'un travail manuel, qui prend du temps et est limité dans ce qu'il peut produire. Nous avons un article de blog dédié avec plus d'informations sur ce sujet.
  • Surveillance de la Certificate Transparency pour une visibilité complète de tous les certificats émis, couvrant à la fois les certificats existants et les nouvelles émissions en temps réel. Plus de détails dans cet article de blog précédent.
  • La cryptographie et la PKI comme compétences fondamentales, ce qui garantit la prise en charge des protocoles clés et de leur configuration, dans le but de constituer un inventaire cryptographique. Avec tant de changements dans ce domaine, simplement suivre le rythme nécessite un temps de développement considérable, pour des fonctionnalités qui relèvent exactement de notre cœur de métier.
  • Des outils DevOps pour l'inspection ponctuelle et les conseils portant sur diverses options de configuration, notamment TLS, PKI, HSTS, CAA, DNSSEC, DANE, et d'autres.

Notre objectif ici n'est pas de dresser une liste de fonctionnalités, mais de souligner à quel point un bon outil pour ce cas d'usage complexe doit être conçu et construit depuis la base. Par exemple, nos capacités de découverte se concentrent d'abord sur l'infrastructure, et nous y ajoutons ensuite une découverte des certificats qui fonctionne de manière transparente sur toutes les CA, sans aucun effort manuel. Nous superposons ensuite une surveillance active du réseau pour pouvoir identifier ce qui est utilisé et où, ainsi que découvrir les relations avec des tiers.

Ce que nos clients nous disent, c'est qu'ils apprécient notre visibilité, non seulement pour les informations qu'elle fournit, mais aussi comme un moyen de comprendre leur parc afin de pouvoir planifier leurs autres tâches, telles que l'acquisition de CLM, le déploiement de PKI privées, et l'évaluation de leur préparation à l'automatisation et au post-quantique. Cela ne fait pas de mal que notre plateforme soit très facile à déployer et fournisse des résultats rapidement.

Ivan Ristic
Ivan Ristic
Chief Scientist

Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.