Exploiter une PKI privée : mettre en place OpenSSL et CFSSL, CRL/OCSP et intégration HSM

Dans cet article, j’explique comment opérer une PKI privée — c’est‑à‑dire une Public Key Infrastructure (PKI) interne qui émet et gère des certificats X.509. Une PKI est centrale pour TLS, la signature de code, l’authentification des clients et les accès VPN. J’aborde des aspects pratiques : choix OpenSSL vs. CFSSL, architecture CA, CRL (Certificate Revocation List) et OCSP (Online Certificate Status Protocol) pour la vérification de révocation, ainsi que l’intégration HSM via PKCS#11. Le public visé est composé d’administrateurs, de system engineers et d’opérateurs : l’accent est donc mis sur l’exploitation, les risques, les étapes de contrôle, le dépannage et les stratégies de repli.

Pourquoi exploiter une PKI privée ?

Une PKI privée donne le contrôle sur les règles d’émission, les durées de vie et le matériel clé. Contrairement aux autorités de certification publiques, elle est destinée aux certificats internes qui ne figurent pas dans les stores racines des navigateurs. Cela permet des durées de vie courtes, des déploiements automatisés et une application stricte des politiques. Les risques sont toutefois accrus : compromission de la clé racine, configuration de révocation défaillante ou automatisation insuffisante peuvent compromettre la disponibilité et la sécurité.

Décisions d’architecture fondamentales

Avant le déploiement, vous devez clarifier les questions d’architecture. Les points décisifs sont la hiérarchie CA, le degré d’automatisation, la conservation des clés et la stratégie de révocation.

CA‑Topologie: Root, Sub‑CA, Issuing

La bonne pratique consiste en une hiérarchie à plusieurs niveaux : une Root‑CA maintenue hors ligne (clé racine, ancre de confiance la plus élevée) et une ou plusieurs Sub‑CA en ligne (Issuing CAs) qui signent les certificats actifs. Cette séparation réduit le risque : une Issuing CA compromise est plus contenue ; la clé racine reste sécurisée hors ligne pendant de longues périodes.

Softwarewahl: OpenSSL vs. CFSSL (vs. Vault)

OpenSSL est un toolkit flexible et adaptable ; adapté aux PKI simples ou à faible volume ou aux workflows contrôlés par les administrateurs. CFSSL (CloudFlare SSL) est un serveur PKI spécialisé avec REST API, configuration JSON et automatisation intégrée. HashiCorp Vault apporte en plus un modèle de type KMS avec des certificats dynamiques et des politiques. Choisissez en fonction des exigences :

• OpenSSL : contrôle total, scripts, mais plus de développement interne pour les API et l’automatisation.
• CFSSL : fournit une API, facilite les parcours d’automatisation, adapté aux équipes DevOps/CI internes.
• Vault : fonctionnalités robustes de gestion des politiques et des secrets ; pertinent si Vault est déjà en place.

Prérequis et principes de sécurité

Avant le déploiement, vous aurez besoin de politiques claires : tailles de clés (2048/3072/4096 RSA ou ECDSA P‑256/P‑384), durées de vie, processus de renewal, journalisation d’audit et rôles (p. ex. officier CA, auditeur). Le HSM (Hardware Security Module) permet de protéger les clés privées contre l’extraction ; PKCS#11 est l’API standard pour cela. Définissez des plans de sauvegarde et de récupération pour le matériel clé et les bases de données CA.

Richtlinien: Certificate Policy (CP) und Certification Practice Statement (CPS)

Les CP/CPS sont des règles documentées qui régissent l’émission, l’utilisation et la révocation. Même en interne, ces documents sont essentiels pour la clarté opérationnelle et comme référence lors d’audits.

Étape par étape: OpenSSL Root und Sub‑CA (Kurzbeispiel)

Cet exemple montre le minimum : générer la Root CA hors ligne, une Sub‑CA pour l’opération de signature. Remarque : OpenSSL se configure via un fichier de configuration (objectif : extensions, chemins). Les échecs surviennent souvent à cause de permissions incorrectes ou de fichiers de numéro de série/index oubliés.

Root CA generieren (offline):

# Root private key (offline, auf HSM empfohlen) und self-signed cert (10 Jahre)
openssl genpkey -algorithm RSA -out root.key.pem -pkeyopt rsa_keygen_bits:4096
openssl req -x509 -new -nodes -key root.key.pem -sha256 -days 3650 -out root.cert.pem -subj "/C=DE/O=ACME/OU=PKI Root/CN=ACME Root CA"

Générer la Sub‑CA et la faire signer par la racine (Sub‑CA en ligne) :

openssl genpkey -algorithm RSA -out subca.key.pem -pkeyopt rsa_keygen_bits:4096
openssl req -new -key subca.key.pem -out subca.csr.pem -subj "/C=DE/O=ACME/OU=PKI SubCA/CN=ACME SubCA"
openssl x509 -req -in subca.csr.pem -CA root.cert.pem -CAkey root.key.pem -CAcreateserial -out subca.cert.pem -days 1825 -sha256 -extensions v3_ca -extfile /etc/ssl/openssl.cnf

Piège typique : lors de la copie des clés racine vers le système en ligne, la racine est compromise. Mieux vaut un workflow de signature : générer la CSR hors ligne, la signer hors ligne, et ne transférer en ligne que le certificat de la Sub‑CA.

Intégration HSM : pourquoi et comment (PKCS#11)

Les HSM protègent physiquement les clés privées et empêchent leur exportation simple. PKCS#11 est une API indépendante de la plateforme qui permet aux logiciels de communiquer avec les HSM. SoftHSM est une implémentation logicielle de PKCS#11 pour les tests ; les Cloud‑HSM (AWS, Azure, Google) fournissent des HSM managés avec des étapes d’intégration propres.

SoftHSM pour un essai

SoftHSM est utile pour les tests ; il ne remplace pas un HSM certifié FIPS en production. Pour créer une clé dans SoftHSM :

# Initialisierung (Beispiel mit SoftHSM2)
softhsm2-util --init-token --slot 0 --label "test-token" --pin 1234 --so-pin 5678
# Import eines RSA-Schlüssels (PKCS#12) in SoftHSM
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -l --pin 1234 --import mykey.p12 --type private

Dans des environnements de production, configurez votre logiciel de CA (OpenSSL, CFSSL, Vault) de sorte que les clés privées restent gérées via PKCS#11 et que les opérations de signature s’exécutent dans le HSM. OpenSSL nécessite par exemple un moteur PKCS#11 ou la configuration p11tool/engine_pkcs11.

# Beispiel: OpenSSL mit engine_pkcs11 (vereinfacht)
openssl engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD

Erreurs fréquentes : identifiants de slot/token incorrects, expirations de PIN, ACLs côté HSM. Testez de manière automatisée des boucles telles que les workflows de signature et de contre‑signature avant la mise en production.

Révocation : CRL et OCSP en exploitation

La révocation est critique : la CRL (Certificate Revocation List) est une liste de numéros de série révoqués ; les clients la téléchargent périodiquement. OCSP permet d’interroger en ligne le statut d’un certificat individuel. Les deux approches ont des avantages et des inconvénients :

• CRL : simple, évolutif via CDN/HTTP, mais la liste peut devenir volumineuse et les clients doivent télécharger des mises à jour régulières.
• OCSP : statut en temps réel, faible volume de données par requête, mais exige un OCSP‑Responder fiable (haute disponibilité) et des réponses signées (certificat d’OCSP‑Responder ou OCSP stapling pour TLS).

Pour les PKI internes, une combinaison est souvent pertinente : la CA d’émission publie des CRL périodiquement (p. ex. toutes les 12 heures) et exploite un OCSP‑Responder pour une faible latence et des vérifications en ligne réelles.

Créer une CRL avec OpenSSL

# CRL erstellen (angenommen index.txt und serial vorhanden)
openssl ca -config openssl.cnf -gencrl -out crl.pem
# CRL in DER für HTTP-Distribution konvertieren
openssl crl -in crl.pem -outform DER -out crl.der

Important : les serveurs web, CDN ou serveurs de fichiers doivent fournir les CRL avec des en-têtes de cache cohérents. Vérifiez que les clients suivent correctement l’URL CRL‑Distribution‑Point (CDP) contenue dans le certificat.

OCSP‑Responder (exemple avec OpenSSL)

# OCSP responder starten (vereinfacht, für Tests)
openssl ocsp -index index.txt -port 2560 -rsigner ocsp.cert.pem -rkey ocsp.key.pem -CA root.cert.pem -text

En production, utilisez des OCSP‑Responder spécialisés (par ex. fournis par CFSSL, EJBCA ou des appliances commerciales) et assurez la haute disponibilité (Load Balancer, Anycast). OCSP‑Stapling (enregistrement TLS de l’état OCSP) réduit les requêtes côté client.

CFSSL: REST‑API und Automatisierung

CFSSL propose des API pour les demandes de signature et la gestion CRL/OCSP. Typiquement, on utilise des JSON‑policies et un déploiement simple dans Docker/Kubernetes. CFSSL convient si vous souhaitez intégrer l’émission automatisée de certificats dans des pipelines CI/CD ou de provisioning.

{
  "signing":{
    "default":{
      "expiry":"8760h"
    },
    "profiles":{
      "server":{
        "expiry":"720h",
        "usages":["signing","key encipherment","server auth"]
      }
    }
  }
}

CFSSL est plus simple à exploiter pour les clients REST que des scripts OpenSSL ; veillez à l’authentification de l’API (mTLS, token) et aux limites de taux, sinon un compte compromis peut émettre un grand nombre de certificats.

Exploitation, supervision et audit

Les éléments essentiels sont : les logs d’audit (qui a demandé/apprové un certificat), la supervision (CA‑Service‑Health, temps de réponse OCSP, statut de publication des CRL), la sauvegarde des bases de données de la CA (index.txt, serial), ainsi que des tests de restauration réguliers. Prévoyez des alertes en cas d’erreurs : publications CRL échouées, OCSP‑Responder hors service ou erreurs de communication avec le HSM.

Audit et intégrité des logs

L’intégrité des logs signifie : les logs doivent être vérifiables. Signez les logs d’audit ou stockez-les en mode append‑only sur un service de logs externe. Sans logs vérifiables, la reconstruction lors d’une réponse à incident est problématique.

Dépannage — pièges typiques

Voici les causes les plus fréquentes et les séquences de vérification :

1. Client : date/heure incorrectes : vérifiez le NTP ; des certificats expirés ou des NotBefore/NotAfter invalides entraînent des erreurs TLS.
2. CRL/OCSP inaccessibles : testez l’URL CDP dans le certificat et l’URL OCSP ; vérifiez l’accessibilité HTTP(S) et les pare-feu.
3. HSM PIN/Lifecycle : verrouillage du PIN ou blocage suite à des authentifications ratées ; vérifiez l’état du token et les logs du HSM.
4. Chaîne manquante : le serveur fournit uniquement le certificat End‑Entity, mais pas la Sub‑CA ; vérifiez la configuration de la chaîne TLS sur les serveurs web ou les provisioners.
5. Incohérences de format : PEM vs DER ; de nombreux outils attendent des formats explicites.

Exemples d’étapes de vérification

# Prüfen des Zertifikatspfads und CRL/OCSP URLs
openssl x509 -in service.cert.pem -text -noout | sed -n '/X509v3 CRL/D, /Authority Information Access/ p'

# OCSP-Abfrage eines spezifischen Zertifikats (Testumgebung)
openssl ocsp -issuer subca.cert.pem -cert service.cert.pem -url http://ocsp.example.local:2560 -text -resp_text

Automatisation et gestion du cycle de vie

L’automatisation réduit les erreurs humaines lors du renouvellement/révocation. Pour des environnements internes, il existe deux approches typiques : une CA interne compatible ACME (p. ex. cfssl+acme‑bridge ou des solutions de type Boulder) ou une automatisation basée sur API via CFSSL/Vault. ACME est un protocole qui permet aux clients de demander et renouveler des certificats de manière automatisée ; l’authentification des clients est ici cruciale (HTTP‑01 en interne, DNS‑01 ou mTLS).

Aspects importants du cycle de vie :

• Notification automatique avant expiration (p. ex. 30/7/1 jours).
• Renouvellement sans intervention (zero‑touch) pour serveurs et load balancers via hooks/agents.
• Tests automatiques après renouvellement : vérification de la chaîne et de l’OCSP‑Stapling.

# Beispiel: Ansible Task (vereinfachte Darstellung) um CRL zu verteilen
- name: Upload CRL to webserver
  copy:
    src: /var/pki/crl/crl.der
    dest: /srv/www/ssl/crl/crl.der
    owner: root
    mode: '0644'
  notify: RESTart nginx

- name: RESTart nginx
  service:
    name: nginx
    state: RESTarted

Client‑Trust‑Verteilung und Bereitstellung

Il est essentiel que tous les clients et systèmes concernés fassent confiance aux Root/Intermediates internes. Voies de distribution typiques :

• Windows: GPO distribue le Root‑Cert dans Trusted Root Certification Authorities.
• Linux/Servers: CA‑Bundle central dans /etc/pki/ca‑trust/source/anchors et exécuter update‑ca‑trust.
• Mobile/Endpunkte: MDM (Mobile Device Management) ou installation manuelle pour appareils gérés.

Testez le déploiement par paliers et vérifiez que les clients, après distribution, établissent correctement des connexions TLS et vérifient OCSP/CRL.

Skalierung, Performance und Hochverfügbarkeit

La mise à l’échelle concerne principalement OCSP et la distribution des CRL. Les OCSP‑Responder doivent fournir une faible latence ; mesures courantes :

• Caching OCSP (Responder et Load Balancer) et Anycast pour la distribution géographique.
• CDN pour la diffusion des CRL avec en‑têtes Cache‑Control appropriés et TTL.
• Surveillance des temps de réponse et des taux d’erreur ; basculement automatique du Responder.

# Beispiel: Prometheus Alert (vereinfachtes Beispiel)
- alert: OCSPResponderDown
  expr: probe_success{job="ocsp_probe"} == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "OCSP Responder nicht erreichbar"
    description: "OCSP Responder {{ $labels.instance }} antwortet nicht."

Disaster Recovery und Incident‑Runbook

Préparez un runbook d’incident clair. Étapes importantes en cas de compromission du Root/CA ou de panne HSM :

1. Isoler les systèmes affectés et préserver les preuves (Logs). Documenter les horodatages.
2. Révoquer les certificats compromis et publier immédiatement une mise à jour de la CRL et le statut OCSP „revoked“.
3. Si le Root est compromis : prévoir un plan de cross‑signing ou de reconstruction de la PKI avec un déploiement parallèle des nouveaux Root/Sub‑CAs ; informer les équipes concernées.
4. Tester la RESTauration depuis les sauvegardes, y compris l’import HSM ou les procédures de remplacement HSM.

Les exercices DR réguliers (au moins annuels) sont obligatoires : testez par écrit les étapes de RESTauration et effectuez une validation de bout en bout.

Praktische Prüf‑Commands & Beispiele

Quelques vérifications utiles à intégrer régulièrement dans vos runbooks :

# Vérification du chemin du certificat
openssl verify -CAfile chain.pem service.cert.pem

# Télécharger et vérifier la CRL
curl -sS -o crl.der http://crl.example.local/crl.der
openssl crl -in crl.der -inform DER -text -noout

# Requête OCSP de test vers une URL de production
openssl ocsp -issuer subca.cert.pem -cert service.cert.pem -url http://ocsp.example.local:2560 -header "HOST" "ocsp.example.local" -resp_text

# État du slot/token HSM (pkcs11-tool)
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -L
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -T

Conclusion

Exploiter une PKI privée exige bien plus que l’émission de certificats : des politiques claires, un stockage sécurisé des clés (idéalement HSM), une automatisation pour l’émission/le renouvellement/la révocation, du monitoring et des procédures de récupération testées. OpenSSL offre un contrôle maximal, CFSSL facilite l’automatisation basée sur API. CRL et OCSP se complètent en robustesse et en rapidité de réaction. Testez les workflows HSM, vérifiez automatiquement l’accessibilité des CRL/OCSP et maintenez un runbook écrit pour la rotation et la gestion des incidents. Une PKI bien documentée minimise les risques opérationnels et garantit la disponibilité fiable de vos dépendances TLS internes.

Ressources et liens internes

Pour des intégrations plus poussées, consultez la documentation des outils : CFSSL, OpenSSL Engine PKCS#11, SoftHSM et les spécifications fournisseurs des HSM. Prévoyez également un audit des politiques PKI et des tests de RESTauration réguliers, comme pour les exercices de récupération de sauvegarde dans d’autres systèmes critiques.

Sur ce sujet, l’intégration OpenSSL PKI et HSM est également importante. L’article situe ces aspects de manière compréhensible et indique ce qui importe au quotidien.