PKI Client

Créer et exploiter une hiérarchie de certification privée par organisation : autorités racine, intermédiaires et de délivrance, profils, demandes CSR, certificats émis, révocation, CRL, OCSP et audit.

1. Ce que permet le module

Le tableau de bord PKI Client regroupe les autorités de certification, les certificats émis, les certificats révoqués et les autorités post-quantiques de votre organisation. Les actions principales disponibles dans l’interface sont Nouvelle racine gérée, Importer une racine hors ligne, Nouvelle autorité fille, Nouveau profil et Soumettre un CSR.

Les objets PKI sont isolés par organisation. Une demande ne peut pas utiliser un profil ou une autorité appartenant à une autre organisation.

2. Choisir la hiérarchie PKI

Ecurem CLM distingue trois types d’autorités :

• Root / Racine : autorité auto-signée au sommet de la hiérarchie.
• Intermediate / Intermédiaire : autorité signée par une racine et utilisée pour séparer les niveaux de confiance.
• Issuing / Délivrance : autorité destinée à signer les certificats finaux.

Une architecture courante est donc :

Racine → Autorité intermédiaire → Autorité de délivrance → Certificats finaux

Pour une structure plus simple, vous pouvez également utiliser :

Racine → Autorité de délivrance → Certificats finaux

3. Créer une racine gérée

Dans PKI Client, cliquez sur Nouvelle racine gérée. Le formulaire demande :

• Organisation : organisation propriétaire de la PKI.
• Nom : nom d’affichage interne, par exemple Acme Root CA 2026.
• Nom commun X.509 : valeur CN inscrite dans le certificat de la racine, par exemple Acme Corporate Root CA.
• Algorithme de signature : RSA 3072, RSA 4096, ECDSA P-256, ECDSA P-384, ML-DSA-44, ML-DSA-65 ou ML-DSA-87.
• Validité en jours : entre 365 et 7300 jours. La valeur initiale proposée par le formulaire est 3650 jours.
• URL de distribution CRL : facultative si la plateforme publie déjà une URL par défaut.
• URL OCSP : facultative si la plateforme publie déjà une URL par défaut.

Après création, Ecurem CLM génère la racine auto-signée, protège la clé privée dans le backend configuré, génère une première CRL et prépare un répondeur OCSP. La clé privée n’est pas affichée à l’utilisateur dans le formulaire.

4. Importer une racine hors ligne

L’action Importer une racine hors ligne sert lorsque la racine est créée et conservée en dehors d’Ecurem CLM. Dans ce modèle, Ecurem CLM référence le certificat de la racine et permet de construire la hiérarchie opérationnelle sans faire de la plateforme le détenteur de la clé privée de cette racine.

Ce modèle est recommandé lorsque votre politique exige que la racine reste hors ligne. L’émission quotidienne peut alors être déléguée à une autorité intermédiaire ou de délivrance gérée par la plateforme.

La plateforme prend également en charge la publication/import de CRL d’une racine externe afin que l’état de révocation reste exploitable dans la chaîne de confiance.

5. Créer une autorité fille

Cliquez sur Nouvelle autorité fille. Les champs sont :

• Organisation.
• Autorité parente : une racine ou une intermédiaire active, non révoquée, appartenant à la même organisation.
• Type d’autorité : Autorité intermédiaire ou Autorité de délivrance.
• Nom.
• Nom commun X.509.
• Algorithme de signature.
• Validité en jours : entre 30 et 3650 jours, avec 1825 jours proposés initialement.
• URL de distribution CRL des certificats émis.
• URL OCSP des certificats émis.

La validité réelle d’une autorité fille ne peut pas dépasser la durée restante de sa parente. Ecurem CLM limite automatiquement la durée si nécessaire.

La hiérarchie est aussi contrôlée par les contraintes X.509 : une autorité parente expirée, révoquée, désactivée ou dont la contrainte de chemin interdit le niveau demandé ne peut pas signer la nouvelle autorité.

6. Créer un profil de certificat

Un profil définit les règles applicables aux certificats finaux. Cliquez sur Nouveau profil puis renseignez :

• Organisation.
• Nom : par exemple TLS serveurs internes.
• Validité en jours : durée des certificats émis avec ce profil.
• Suffixes DNS autorisés : un suffixe par ligne, par exemple services.example.ca. Les valeurs sont normalisées en minuscules.
• Autoriser les wildcards : activez uniquement si le besoin de certificats *.example.ca est réel.
• Approbation requise : si activée, une demande doit être explicitement approuvée avant émission.
• Activé : un profil désactivé n’est plus proposé pour les nouvelles demandes.

Dans l’interface client actuelle, les usages techniques du profil sont initialisés pour les certificats TLS serveur avec digitalSignature et serverAuth. Les suffixes DNS et la politique wildcard servent ensuite à contrôler les noms demandés.

7. Soumettre un CSR

Cliquez sur Soumettre un CSR. Le formulaire demande exactement :

• Organisation.
• Profil : uniquement les profils actifs accessibles dans votre organisation.
• Autorité : uniquement les autorités actives, non révoquées et autorisées. Lorsque le contrôle Issuing CA obligatoire est actif, seules les autorités de délivrance sont proposées.
• CSR PEM : requête PKCS#10 au format PEM.

Ecurem CLM analyse le CSR avant de l’accepter. Le CSR doit :

• être un CSR PKCS#10 PEM valide ;
• avoir une signature cryptographique valide ;
• contenir un Common Name ;
• respecter le profil sélectionné, notamment le périmètre DNS et la politique wildcard.

Le Common Name et les Subject Alternative Names sont extraits du CSR et conservés dans la demande. Vous n’avez donc pas à les ressaisir séparément dans ce formulaire.

8. Approbation et émission

Les demandes suivent des statuts explicites : Pending, Approved, Rejected, Issued ou Failed.

• Si le profil exige une approbation, la demande doit être Approved avant émission.
• L’autorité de délivrance doit être active et non révoquée.
• L’autorité et la demande doivent appartenir à la même organisation.
• La validité du certificat final ne peut pas dépasser la validité restante de l’autorité émettrice.

Après émission, Ecurem CLM conserve le numéro de série, le certificat PEM, la chaîne, l’empreinte SHA-256, les dates de validité et le lien vers la demande d’origine.

La chaîne X.509 inclut les informations de révocation disponibles : URL OCSP et point de distribution CRL lorsque ceux-ci sont configurés.

9. Révocation, CRL et OCSP

Un certificat émis peut être révoqué lorsqu’il ne doit plus être considéré comme valide : compromission de clé, remplacement, cessation d’usage ou autre raison de gouvernance.

La révocation est enregistrée avec sa raison, la date et l’utilisateur ayant exécuté l’action. Le module maintient également :

• une CRL signée par autorité, avec numéro, empreinte, dates thisUpdate et nextUpdate ;
• un répondeur OCSP associé à l’autorité ;
• des événements d’audit PKI qui enregistrent l’organisation, l’acteur, l’action, l’objet, le résultat et les détails techniques utiles.

Le tableau des autorités fournit les actions de publication/révocation nécessaires. Avant une mise en production, assurez-vous que les URLs CRL/OCSP publiques sont correctement définies et accessibles aux consommateurs des certificats.

10. Algorithmes disponibles

Le modèle d’autorité supporte actuellement :

• RSA 3072
• RSA 4096
• ECDSA P-256
• ECDSA P-384
• ML-DSA-44
• ML-DSA-65
• ML-DSA-87

Le choix dépend de votre politique cryptographique, de la compatibilité des systèmes consommateurs et du niveau de préparation post-quantique recherché. Ne choisissez pas ML-DSA uniquement parce qu’il est disponible : vérifiez que les composants qui consommeront la chaîne savent traiter cet algorithme.

11. Erreurs fréquentes

• « Le profil appartient à une autre organisation » : sélectionnez un profil de la même organisation que la demande.
• « L’autorité appartient à une autre organisation » : sélectionnez une autorité du même tenant.
• « Le CSR PKCS#10 PEM est invalide » : vérifiez les balises PEM et régénérez le CSR.
• « La signature du CSR est invalide » : le CSR a été altéré ou mal généré.
• « Le CSR ne contient aucun nom commun » : fournissez un CN dans le CSR.
• Autorité non proposée : vérifiez qu’elle est active, non révoquée et, si requis, de type Issuing.
• Autorité fille impossible à créer : vérifiez le type de la parente, son statut, sa date d’expiration et les contraintes de chemin X.509.
• Émission bloquée en attente : vérifiez si le profil impose une approbation explicite.