Aller au contenu

CertRiver & CertManager — Cycle de vie des certificats

Deux modules complémentaires, jamais redondants :

Module Rôle Écrit sur l'AC ?
CertRiver Inventaire — observe les certificats déjà présents sur le parc Non, lecture seule
CertManager Émission — demande, approuve, émet et révoque de nouveaux certificats Oui, via un agent dédié

CertRiver répond à « quels certificats existent, où, et lequel expire bientôt ? ». CertManager répond à « comment en obtenir un nouveau, proprement, avec approbation et traçabilité ? ». Un certificat émis par CertManager apparaît automatiquement dans l'inventaire CertRiver dès sa signature — les deux bases de données restent liées par (autorité, numéro de série), jamais dupliquées.

1. CertRiver — inventaire des certificats

1.1 Trois canaux de collecte

CertRiver ne collecte jamais lui-même sur le réseau — trois sources alimentent son inventaire, chacune indépendante des autres :

Un agent InfraRiver Collector (module certs) inspecte le filesystem d'un serveur et remonte chaque certificat X.509 trouvé — chaîne de confiance, algorithme, taille de clé, dates de validité, empreinte. C'est la source la plus large : elle couvre tout serveur équipé du Collector, quel que soit l'usage du certificat (TLS web, messagerie, signature applicative…).

Un script PowerShell (collect_adcs.ps1) lit en lecture seule le registre d'une autorité de certification Microsoft ADCS et remonte chaque certificat émis par cette AC — y compris ceux jamais déployés sur un serveur observable par le canal 1. Ne lit jamais une clé privée. Déployé via un bundle généré depuis la page de configuration (voir §1.3).

Le connecteur vCenter remonte directement le certificat de gestion de chaque hôte ESXi (chiffrement du canal de management), sans agent supplémentaire — piloté par la configuration du connecteur vCenter lui-même.

Aucune clé privée n'est jamais collectée

Les trois canaux ne remontent que des métadonnées de certificat (sujet, émetteur, validité, empreinte, taille de clé…). Aucun canal ne lit, ne transmet ni ne stocke le contenu d'une clé privée.

1.2 Ce que l'inventaire signale

Chaque certificat est évalué automatiquement à la collecte :

  • Expiration proche — sous le seuil configuré (§1.3).
  • Clé faible — RSA sous le seuil configuré, ou EC < 256 bits, ou DSA (toujours faible, non configurable).
  • Auto-signé ou chaîne non fiable.
  • Wildcard, CA, algorithme de signature.

1.3 Configuration (/admin/plugins/certriver)

Champ Défaut Description
Token Bearer (ingest_token) — Jeton présenté par le collecteur (canal 1) dans l'en-tête Authorization: Bearer. Sans token configuré, l'endpoint d'ingestion répond 503.
Alerte expiration (expiry_warn_days) 30 jours Un certificat dont days_until_expiry < expiry_warn_days est marqué en alerte.
Taille minimale RSA (weak_rsa_bits) 2048 bits Sous ce seuil, une clé RSA est marquée faible.

La même page permet de générer un bundle PKI/ADCS (canal 2) : un .zip qui contient :

  • le script de collecte ;
  • sa configuration pré-remplie ;
  • un certificat client mTLS ;
  • un install.ps1 qui dépose le tout sur la machine ADCS et crée la tâche planifiée (exécution horaire, compte SYSTEM).

Le bundle n'est généré et téléchargeable qu'une seule fois : la clé privée du certificat mTLS n'est jamais conservée côté serveur une fois le téléchargement effectué.

Machine cible

Ce bundle se déploie sur la machine CA/ADCS elle-même (lecture locale du registre) — à l'inverse de l'agent CertManager (§2.7), qui ne doit jamais tourner sur l'AC.

1.4 Page d'inventaire (/certriver/)

Table filtrable (recherche, tri, filtre par colonne, filtre avancé ET/OU, sélecteur de colonnes) sur l'ensemble des certificats connus, tous canaux confondus.

Un clic sur une ligne ouvre la fiche détail :

  • sujet, émetteur, SAN ;
  • dates de validité, empreinte ;
  • tous les déploiements connus de ce même certificat (plusieurs serveurs peuvent partager le même certificat) ;
  • si le certificat a été émis via CertManager, un lien vers la demande d'origine.

2. CertManager — demande, approbation, émission

2.1 Principe

CertManager couvre le cycle complet d'un nouveau certificat :

  1. un utilisateur soumet une demande fermée (nom, domaines/IP autorisés) ;
  2. une policy définit les règles (autorité, template, contraintes) ;
  3. une approbation (manuelle ou automatique selon l'équipe) valide la demande ;
  4. un agent Windows dédié la soumet réellement à l'autorité de certification ;
  5. la clé privée générée est conservée chiffrée jusqu'à téléchargement ou expiration.

2.2 Invariants de sécurité

  • L'agent soumet, il ne signe jamais — la signature reste entièrement du ressort de l'autorité de certification (ADCS).
  • Clé privée toujours chiffrée au repos (chiffrement en enveloppe — une clé maîtresse distincte protège chaque clé privée individuelle, jamais stockée au même endroit que les clés qu'elle protège).
  • Remise de clé uniquement par fichier chiffré, avec un code à usage unique envoyé par messagerie à l'adresse du compte demandeur — jamais affiché à l'écran, jamais stocké en clair.
  • Formulaire de demande fermé : nom de domaine (CN), SAN DNS, SAN IP — rien d'autre (aucun SAN e-mail/UPN/URI, exclu par choix de sécurité).
  • Liste blanche d'autorités/templates côté agent — l'agent ne fait jamais confiance aveuglément à ce que le serveur lui annonce, il vérifie sa propre configuration locale avant toute soumission.
  • Révocation ciblée uniquement sur un certificat déjà connu de CertRiver — jamais un numéro de série saisi librement.

2.3 Issuing Policies

Une policy nommée regroupe tout ce qui définit comment un certificat sera émis.

La page Administration → CertManager commence par le tableau Templates du PKI : les templates connus, avec l'autorité (CA) qui les publie, si la CA les publie toujours, le nombre de certificats émis, la date de la dernière émission et le nombre de policies qui les utilisent.

  • Récupération automatique : l'agent Windows (§2.7) lit sur chaque autorité la liste des templates qu'elle publie et la transmet à InfraRiver, à son installation puis toutes les heures. Le bouton ↻ Actualiser depuis le PKI demande une relecture immédiate (à son prochain passage, moins d'une minute après). La colonne Source indique Agent pour un template lu sur la CA.
  • Complément CertRiver : les templates vus sur les certificats déjà collectés y figurent aussi, y compris avant que l'agent ait lu la CA (colonne Publié à « — »).
  • Template retiré d'une CA : l'agent le signale (« non » en rouge). Il n'est plus proposé pour une nouvelle policy ; une policy existante reste modifiable mais le tableau l'indique.

Le bouton + Créer une policy d'une ligne ouvre le formulaire avec ce template déjà choisi.

Champ Description
Nom Libellé affiché aux équipes lors de la demande.
Template du PKI Liste déroulante des templates du tableau ci-dessus. L'autorité (CA) n'est pas saisie : elle découle du template choisi et s'affiche sous la liste. L'agent refuse de toute façon tout template hors de sa propre liste blanche locale.
Algorithme / taille de clé RSA (2048, 3072 ou 4096 bits) ou EC (P-256 ou P-384) : la liste des tailles suit l'algorithme choisi.
Champs Subject (O, OU, C, ST, L) Fixés par la policy — le demandeur ne saisit jamais que le CN.
Domaines DNS autorisés Suffixes acceptés pour le CN/SAN.
Wildcard autorisé Si oui, une demande wildcard force malgré tout l'approbation manuelle (jamais d'auto-approbation sur un wildcard).
SAN IP autorisé + plages CIDR Optionnel.
Nombre max de SAN Combiné DNS + IP.
Conservation de la clé Jusqu'à expiration (purge automatique dès que le certificat expire) ou après 1er téléchargement.
Conservation clé — .csr seul Un .csr jamais soumis n'a pas de date d'expiration à attendre — délai configurable, 90 jours par défaut.
Qui peut télécharger la clé Le demandeur seul, ou n'importe quel membre de l'équipe.

2.4 Droits équipe × policy

Chaque policy est assignée à une ou plusieurs équipes, avec un mode d'approbation par paire (équipe, policy) :

  • Manuel (par défaut) — la demande attend une approbation explicite.
  • Automatique — la demande passe directement au statut approuvée, sauf demande wildcard (toujours manuelle, quel que soit ce réglage).

Aucune équipe absente de cette matrice ne voit la policy dans le formulaire de demande.

2.5 Formulaire de demande (/certmanager/new)

Deux actions possibles :

Bouton Effet Soumis à l'autorité ?
Générer le certificat Génère clé + CSR, entre dans le cycle d'approbation Oui
Générer un .csr seulement Génère clé + CSR, statut terminal immédiat Non — pour une autorité externe, soumission manuelle

2.6 Cycle de vie d'une demande

pending_approval → approved → (submitted) → pending_ca → signed
                 ↘ declined                            ↘ failed
  • pending_approval — en attente (mode manuel).
  • approved — validée, en attente du prochain passage de l'agent (cycle à la minute).
  • pending_ca — soumise, l'autorité elle-même demande une seconde validation avant de signer (« soumission en deux temps ») — l'agent revérifie automatiquement au cycle suivant.
  • signed — certificat émis. Poussé automatiquement dans l'inventaire CertRiver.
  • declined / failed — la clé chiffrée est purgée immédiatement.
  • csr_only — statut terminal dès la soumission, jamais transmis à l'agent.

2.7 Agent Windows

Un script PowerShell dédié (jamais installé sur l'autorité de certification elle-même), en mode pull : il interroge InfraRiver à intervalle régulier (tâche planifiée, chaque minute), ne reçoit jamais que des demandes déjà approuvées, et rapporte le résultat de chaque soumission.

Garde-fous appliqués côté agent, indépendamment de ce que le serveur annonce :

  • Liste blanche locale des autorités et templates autorisés (fichier de configuration du bundle, jamais modifiable à distance).
  • Détection d'une autorité mal configurée (indicateur EDITF_ATTRIBUTESUBJECTALTNAME2) — refuse toute soumission vers cette autorité précise, sans bloquer les autres.
  • Le certificat client mTLS est importé dans le magasin Windows (non exportable) plutôt que laissé en fichier sur le disque — la clé privée du canal de communication ne survit pas à l'installation.

Le bundle d'installation se génère depuis /admin/plugins/certmanager (« Bundle agent Windows ») — whitelist d'autorités/templates auto-dérivée des policies actives, jamais saisie à la main.

Lecture des templates (lecture seule). L'agent peut tourner avant toute policy : sans policy, il ne soumet rien (toute demande serait refusée) mais lit déjà les templates publiés par les autorités que CertRiver et vos policies lui désignent. Il ne transmet que des noms de templates, jamais un certificat ni une clé.

Réglages optionnels du fichier de configuration de l'agent :

Réglage Valeur
template_discovery_minutes 60 par défaut
extra_cas autorités à lire en plus, au format hôte\nom_ac
discover_templates false pour désactiver

Une autorité qu'aucun certificat collecté ni aucune policy ne désigne doit être ajoutée dans extra_cas.

Le token d'authentification reste toujours requis

Le certificat client mTLS est une couche de sécurité additionnelle, jamais un remplacement du jeton Bearer — les deux sont vérifiés indépendamment à chaque appel.

2.8 Téléchargement de la clé privée

Le CSR se télécharge directement (aucun secret dedans). La clé privée se télécharge sous forme de fichier chiffré : un code aléatoire (20 caractères minimum, sans caractères ambigus) est envoyé par messagerie à l'adresse du compte demandeur — jamais affiché dans InfraRiver, jamais stocké. Si l'envoi du mail échoue, aucun fichier n'est délivré.

Limite assumée

Ce mécanisme ne protège vraiment que si la messagerie est consultée sur un canal distinct du poste d'accès à InfraRiver — à documenter auprès des équipes concernées.

2.9 Révocation

Deux points d'entrée, tous deux soumis à la permission certmanager.revoke :

  • Depuis une demande signée — révoque le certificat qu'elle a produit.
  • Formulaire générique (/certmanager/revocations/new) — recherche n'importe quel certificat déjà connu de CertRiver (émis via CertManager ou non) et le cible pour révocation. Un certificat totalement inconnu de CertRiver est refusé.

Motif obligatoire à chaque révocation (RFC 5280) : Compromission de clé (prioritaire à l'affichage), Non spécifié, Remplacé, Cessation d'activité. La révocation est synchrone côté autorité — un seul passage de l'agent suffit à la confirmer. Une fois confirmée, la clé chiffrée associée est purgée automatiquement.

2.10 Purge automatique

Une tâche planifiée quotidienne purge les clés chiffrées qui n'ont plus lieu d'être conservées : certificat expiré (selon la date d'expiration réelle observée par CertRiver) ou .csr seul au-delà de son délai de conservation. S'ajoute aux purges immédiates déjà déclenchées par un refus, une révocation confirmée, ou un premier téléchargement (selon la policy).

3. Permissions

Permission Portée
certmanager.request Soumettre une demande, consulter ses propres demandes.
certmanager.approve Approuver/décliner une demande, voir la file d'approbation complète.
certmanager.revoke Déclencher une révocation, voir la liste des révocations.
certmanager.manage Configurer les Issuing Policies et les droits équipe × policy.

Les quatre permissions sont indépendantes — un rôle peut par exemple approuver sans jamais pouvoir révoquer.

4. Limites connues

  • CertManager — deux garde-fous PKI avancés restent hors périmètre v1 : l'inspection automatique des droits d'un template ADCS avant activation d'une policy, et la détection de droits excessifs accordés à l'agent sur l'autorité (au-delà du strict nécessaire). Ces deux points nécessitent un gabarit ADCS volontairement mal configuré pour être vérifiés en conditions réelles.
  • CertRiver — le bundle PKI/ADCS (canal 2) transmet aujourd'hui son certificat client mTLS sous forme de fichiers PEM classiques ; l'agent CertManager (§2.7), lui, importe son certificat dans le magasin Windows pour contourner une limitation de Windows sur l'authentification par certificat client — le même traitement n'a pas encore été généralisé au bundle CertRiver.
  • Multi-autorité — chaque Issuing Policy cible une seule autorité/template ; un besoin de bascule automatique entre plusieurs autorités n'est pas couvert.