STELAU / CERTIFICATE LIFECYCLE MANAGEMENT
Un certificat ne vit pas seul. Il a une autorité, des usages, des emplacements et une échéance. reBop relie ces informations pour rendre le cycle de vie observable, compréhensible et pilotable.
01 / Un produit Stelau
reBop est un Certificate Lifecycle Management : son objet est le certificat, du repérage à son renouvellement observé. Une vision transversale des certificats, publics comme privés, au-delà d’une seule autorité de certification. Stelau y applique sa maîtrise de X.509, des infrastructures PKI et des contraintes d’exploitation.
02 / Découverte & collecte
Internet, réseau interne, fichiers locaux : un inventaire utile réunit le certificat et les endroits où il est observé. Un nom de fichier ou une date d’expiration ne suffit pas.
URL et port TCP, listes d’hôtes, export DNS ou recherche de sous-domaines : plusieurs points d’entrée permettent de retrouver les certificats présentés sur les services accessibles.
Les sources de découverte incluent les recherches DNS et les Certificate Transparency Logs. Un résultat de CT est un indice d’émission ; l’observation d’un service renseigne le certificat effectivement présenté.
La sonde reBop parcourt les systèmes de fichiers locaux et les réseaux configurés pour découvrir les certificats qui ne sont pas exposés sur Internet.
La sonde open source fonctionne sous Windows, macOS, Linux et Unix. Elle produit un fichier JSON avec les certificats et leur contexte : chemin local, hôte et adresses IP. Les fichiers de clés privées sont ignorés.
Un même certificat peut être utilisé sur plusieurs hôtes ou services. reBop conserve le contexte d’utilisation pour suivre les renouvellements emplacement par emplacement.
Import par fichier ou envoi de la sonde avec une clé d’API : la collecte alimente l’inventaire sans confondre le certificat avec le serveur qui l’utilise. La sonde mémorise les certificats déjà observés pour identifier les nouveautés.
Découverte et surveillance reBop ↗Fonctionnement de la sonde ↗
03 / Cryptographie appliquée
Les dates ne sont qu’une partie du sujet. Un certificat X.509 transporte une identité, une clé publique, des usages et des contraintes. Ce sont ces données qu’un CLM doit rendre lisibles.
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
-- SubjectPublicKeyInfo, Validity,
-- Extensions: SAN, KU, EKU, AIA, CRL…Sujet, émetteur, numéro de série, période de validité, clé publique et extensions : l’encodage ASN.1 donne accès aux informations qui décrivent le certificat.
SAN, KeyUsage, ExtendedKeyUsage, BasicConstraints, politiques, AIA et points de distribution CRL : ces champs permettent de comprendre à quel usage et à quel environnement un certificat est destiné.
L’analyse détaillée de reBop réunit les informations du certificat, son état et les éléments de son contexte de confiance, avec une analyse de conformité.
La documentation produit décrit notamment l’inclusion dans les listes de confiance européennes eIDAS, Mozilla et Microsoft. La présence d’un certificat dans un inventaire ne suffit pas à établir sa confiance pour un usage donné.
Identifier les algorithmes de signature, les clés et les usages permet de préparer les évolutions d’une politique cryptographique, y compris la transition post-quantique.
La première question est opérationnelle : où se trouvent les certificats concernés et quels services en dépendent ? L’inventaire et la lecture des paramètres rendent les dépendances visibles avant de planifier une migration.
04 / Détection des renouvellements
Le renouvellement est une relation entre un ancien certificat, un nouveau certificat et leurs emplacements. reBop met cette relation au centre du suivi.
Une nouvelle observation révèle un certificat susceptible de remplacer un certificat déjà suivi.
Le moteur de corrélation, appelé AI Engine dans reBop, identifie les renouvellements probables et traite les correspondances qu’il juge suffisamment certaines.
Les cas incertains deviennent des propositions à accepter ou rejeter. Lors d’une acceptation, les labels et paramètres de suivi sont transmis au nouveau certificat ; l’ancien est archivé.
L’observation continue des emplacements permet de repérer les certificats expirés, révoqués ou suspendus encore en ligne, et de suivre le délai entre le début de validité et le déploiement effectif.
Disposer d’un certificat renouvelé et l’avoir réellement mis en service sont deux étapes différentes. Ce délai aide à mettre en évidence les écarts entre la disponibilité du certificat et son déploiement. La détection d’un renouvellement ne constitue pas une émission ou un déploiement automatique par reBop.
05 / Exploitation & pilotage
Réduire les angles morts, organiser les échéances et partager les décisions : la lecture technique doit déboucher sur une exploitation maîtrisée.
La timeline répartit les certificats par échéance et par état de renouvellement. Les périodes deviennent des filtres vers les certificats à examiner.
Certificats renouvelés, renouvellements en attente et actions restantes : la vue de pilotage aide à préparer le travail plutôt qu’à réagir au dernier moment.
Alertes de validité, de révocation et de présence en ligne, notifications dans l’application, emails et rapports : les échéances se traduisent en informations pour les personnes concernées.
Les périodes et notifications sont configurables. Les alertes sont suivies par utilisateur et par organisation, avec les fonctions disponibles selon l’offre choisie.
Labels, recherche et filtres organisent l’inventaire. Les profils opérateur et lecteur distinguent la gestion opérationnelle de la consultation.
Les journaux tracent les imports, les événements du cycle de vie, les modifications de labels et les décisions sur les propositions de renouvellement ; l’initiateur est enregistré lorsque pertinent.
06 / Architecture de déploiement
Une plateforme hébergée pour fédérer la surveillance. Les sondes remontent les certificats des environnements internes selon le périmètre configuré.
Une même lecture des certificats exposés, internes et importés.
L’offre Enterprise prévoit une installation on-premise, en machine virtuelle ou en conteneur, ainsi qu’un déploiement dans votre IaaS.
Le mode de déploiement et les fonctions attendues se cadrent avec les équipes Stelau.
07 / À vous de lire
Cet atelier Stelau reprend notre application React fondée sur le décodeur ASN.1 de Lapo Luchini. Importez un certificat ou essayez l’exemple fictif : les champs X.509, l’arbre ASN.1 et les octets restent synchronisés à chaque sélection.
Du champ à l’octet : explorez les identités, la validité, les usages, les extensions et les QCStatements.
Ce décodeur lit les données. Il ne valide ni la signature, ni la chaîne de confiance, ni la révocation ou la qualification eIDAS. Aucun appel OCSP ou CRL n’est effectué.
L’exemple est un certificat auto-signé de démonstration pour des noms fictifs. Les QCStatements servent à explorer l’encodage ; ils ne lui confèrent aucune qualification. L’atelier fonctionne indépendamment du service reBop.