Private PKI betreiben: OpenSSL & CFSSL aufsetzen, CRL/OCSP und HSM‑Integration

In diesem Beitrag erkläre ich, wie Sie eine Private PKI betreiben — also eine interne Public Key Infrastructure (PKI), die X.509‑Zertifikate ausstellt und verwaltet. Eine PKI ist zentral für TLS, Code‑Signing, Client‑Authentifizierung und VPN‑Zugänge. Ich behandle Praxisaspekte: Entscheidung OpenSSL vs. CFSSL, CA‑Architektur, CRL (Certificate Revocation List) und OCSP (Online Certificate Status Protocol) zur Sperrprüfung, sowie HSM‑Integration über PKCS#11. Zielgruppe sind Administratoren, System Engineers und Operatoren: daher Fokus auf Betrieb, Risiken, Prüfschritte, Troubleshooting und Rückfallstrategien.

Warum eine private PKI betreiben?

Eine private PKI gibt Kontrolle über Ausstellungsregeln, Lebenszeiten und Schlüsselmaterial. Anders als öffentliche CAs ist sie für interne Zertifikate gedacht, die nicht im Browser‑Rootstore stehen. Das ermöglicht kurze Lifetimes, automatisierte Rollouts und strikte Policy‑Durchsetzung. Risiken sind jedoch größer: Root‑Key‑Kompromittierung, fehlerhafte Revocation‑Konfiguration oder mangelnde Automatisierung können Verfügbarkeit und Sicherheit gefährden.

Grundlegende Architekturentscheidungen

Vor dem Aufbau sollten Sie Architekturfragen klären. Entscheidend sind CA‑Hierarchie, Automatisierungsgrad, Aufbewahrung der Schlüssel und Revocation‑Strategie.

CA‑Topologie: Root, Sub‑CA, Issuing

Best Practice ist eine mehrstufige Hierarchie: ein offline gehaltenes Root‑CA (Root‑Key, höchstes Vertrauensanker) und eine oder mehrere Online‑Sub‑CAs (Issuing CAs), die aktive Zertifikate signieren. Diese Trennung reduziert Risiko: Ein kompromittiertes Issuing CA ist beherrschbarer; Root‑Key bleibt sicher offline für längere Perioden.

Softwarewahl: OpenSSL vs. CFSSL (vs. Vault)

OpenSSL ist ein flexibel anpassbares Toolkit; gut für einfache, low‑volume PKIs oder Admin‑kontrollierte Workflows. CFSSL (CloudFlare SSL) ist ein spezialisierter PKI‑Server mit REST API, JSON‑Konfiguration und integrierter Automation. HashiCorp Vault bietet zusätzlich ein KMS‑ähnliches Modell mit dynamischen Zertifikaten und Policies. Wählen Sie nach Anforderungen:

• OpenSSL: volle Kontrolle, Scripts, aber mehr Eigenentwicklung für APIs und Automation.
• CFSSL: API‑bereit, einfacher Automatisierungspfade, gut für interne DevOps/CI.
• Vault: starke Policy‑ und Secret‑Management‑Funktionalität; sinnvoll, wenn bereits Vault im Einsatz ist.

Voraussetzungen und Sicherheitsgrundlagen

Vor dem Aufbau benötigen Sie klare Policies: Schlüsselgrößen (2048/3072/4096 RSA oder ECDSA P‑256/P‑384), Lebensdauern, Renewal‑Prozesse, Audit‑Logging und Rollen (z. B. CA‑Offizier, Auditor). HSM (Hardware Security Module) ermöglicht Schutz privater Schlüssel gegen Extraktion; PKCS#11 ist ein Standard‑API dafür. Definieren Sie Backup‑ und Recovery‑Pläne für Schlüsselmaterial und CA‑Datenbanken.

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

CP/CPS sind dokumentierte Regeln, die Ausstellung, Nutzung und Sperrung regeln. Auch wenn intern, sind diese Dokumente essenziell für Klarheit im Betrieb und als Referenz bei Audits.

Schritt‑für‑Schritt: OpenSSL Root und Sub‑CA (Kurzbeispiel)

Dieses Beispiel zeigt das Minimale: Root CA offline erzeugen, Sub‑CA für den Signierbetrieb. Erläuterung: OpenSSL konfiguriert per config‑Datei (Zweck: Extensions, Pfade). Scheitern passiert häufig durch falsche Permissions oder vergessene Seriennr/Index‑Dateien.

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"

Sub‑CA erzeugen und vom Root signieren (Sub‑CA online):

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

Typische Stolperfalle: Beim Kopieren von Root‑Schlüsseln aufs Online‑System wird der Root kompromittiert. Besser ist Signatur‑Workflow: CSR offline signieren und nur das Sub‑CA‑Zertifikat nach online übertragen.

HSM‑Integration: Warum und wie (PKCS#11)

HSMs schützen private Schlüssel physisch und verhindern einfache Export. PKCS#11 ist ein plattformunabhängiges API, mit dem Software HSMs anspricht. SoftHSM ist eine softwarebasierte PKCS#11‑Implementierung zum Testen; Cloud‑HSMs (AWS, Azure, Google) bieten managed HSM mit eigenen Integrationsschritten.

SoftHSM als Testlauf

SoftHSM ist nützlich für Tests; ersetzt nicht ein produktives FIPS‑zertifiziertes HSM. Um einen Schlüssel in SoftHSM anzulegen:

# 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

In Produktionsumgebungen konfigurieren Sie Ihre CA‑Software (OpenSSL, CFSSL, Vault) so, dass private Keys über PKCS#11 verbleiben und Signieroperationen im HSM ausgeführt werden. OpenSSL benötigt z. B. ein PKCS#11‑Engine oder die p11tool/engine_pkcs11 Konfiguration.

# 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

Häufige Fehler: falsche Slot/Token IDs, PIN‑Timeouts, ACLs am HSM. Testen Sie Schleifen wie Signier‑ und Unterschreibungs‑Workflows automatisiert, bevor Sie live gehen.

Revocation: CRL und OCSP im Betrieb

Revocation ist kritisch: CRL (Certificate Revocation List) ist eine Liste gesperrter Seriennummern; Clients laden sie periodisch. OCSP ermöglicht Online‑Abfrage des Status einzelner Zertifikate. Beide haben Vor‑ und Nachteile:

• CRL: einfach, skalierbar per CDN/HTTP, aber Liste kann groß sein und Clients müssen regelmäßige Updates herunterladen.
• OCSP: Echtzeit‑Status, geringer Datentransfer pro Anfrage, erfordert aber einen zuverlässigen OCSP‑Responder (hohe Verfügbarkeit) und signierte Responses (OCSP‑Responder Zertifikat oder stapled OCSP für TLS).

Für interne PKIs ist oft eine Kombination sinnvoll: Issuing CA publiziert CRLs periodisch (z. B. alle 12 Stunden) und betreibt einen OCSP‑Responder für niedrige Latenz und echte Online‑Prüfungen.

CRL mit OpenSSL erstellen

# 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

Wichtig: Webserver, CDN oder Fileserver müssen CRL mit konsistenten Cache‑Headern ausliefern. Prüfen Sie, ob Clients die CRL‑Distribution‑Point (CDP) URL vom Zertifikat korrekt folgen.

OCSP‑Responder (Beispiel mit 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

Produktiv nutzen Sie spezialisierte OCSP‑Responder (z. B. aus CFSSL, EJBCA oder kommerziellen Appliances) und stellen Hochverfügbarkeit (Load Balancer, Anycast) sicher. OCSP‑Stapling (TLS‑Registration des OCSP‑Status) reduziert Abfragen auf Client‑Seite.

CFSSL: REST‑API und Automatisierung

CFSSL bietet APIs für Signatur‑Requests und CRL/OCSP‑Management. Typisch sind JSON‑Policies und ein einfaches Deployment in Docker/Kubernetes. CFSSL eignet sich, wenn Sie automatisierte Zertifikatsausgabe in CI/CD oder Provisioning‑Pipelines integrieren möchten.

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

CFSSL ist simpler zu betreiben für REST‑Clients als OpenSSL‑Scriptjobs; achten Sie auf Authentifizierung der API (mTLS, Token) und Rate‑Limits, sonst kann ein verbrauchtes Konto massenhaft Zertifikate erzeugen.

Betrieb, Monitoring und Audit

Essentiell sind Audit‑Logs (wer hat ein Zertifikat beantragt/genehmigt), Monitoring (CA‑Service‑Health, OCSP‑Antwortzeiten, CRL‑Publikationsstatus), Backup der CA‑Datenbanken (index.txt, serial), sowie regelmäßige Restore‑Tests. Sorgen Sie für Alarmierung bei Fehlern: fehlgeschlagene CRL‑Publikationen, OCSP‑Responder‑Down oder HSM‑Kommunikationsfehler.

Audit und Log‑Integrität

Log‑Integrität heißt: Logs müssen prüfbar sein. Signieren Sie Audit‑Logs oder speichern Sie sie append‑only an einem externen Log‑Service. Ohne verifizierbare Logs ist bei Incident Response die Rekonstruktion problematisch.

Troubleshooting typische Stolperfallen

Hier die häufigsten Ursachen und Prüfsequenzen:

1. Client fehlerhaftes Datum/Uhrzeit: Prüfen Sie NTP; abgelaufene Zertifikate oder ungültige NotBefore/NotAfter führen zu TLS‑Fehlern.
2. CRL/OCSP nicht erreichbar: Testen Sie die CDP URL im Zertifikat und OCSP URL; prüfen Sie HTTP(S) Erreichbarkeit und Firewall.
3. HSM PIN/Lifecycle: PIN‑Sperre oder Block durch fehlgeschlagene Authentifizierung; prüfen Sie Token‑Status und HSM‑Logs.
4. Missing chain: Server liefert nur das End‑Entity‑Zertifikat, aber nicht die Sub‑CA; prüfen Sie die TLS Chain Konfiguration auf Webservern oder Provisionern.
5. Format‑Inkonsistenzen: PEM vs DER; viele Tools erwarten explizite Formate.

Beispielprüfschritte

# 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

Automatisierung und Lebenszyklusmanagement

Automatisierung reduziert menschliche Fehler beim Erneuern/Revoke. Für interne Umgebungen gibt es zwei typische Wege: ACME‑kompatible interne CA (z. B. cfssl+acme‑bridge oder Boulder‑like Lösungen) oder API‑basierte Automatisierung via CFSSL/Vault. ACME ist ein Protokoll, das Clients erlaubt, Zertifikate automatisiert zu bestellen und zu erneuern; wichtig ist hier die Authentifizierung der Clients (HTTP‑01 intern, DNS‑01 oder mTLS).

Wichtige Aspekte beim Lifecycle:

• Automatische Benachrichtigung vor Ablauf (z. B. 30/7/1 Tage).
• Zero‑touch Renewal für Server und Load Balancer durch Hooks/Agenten.
• Automatisches Testen nach Renewal: Verifizieren der Chain und 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

Wichtig ist, dass alle relevanten Clients und Systeme das interne Root/Intermediates vertrauen. Typische Verteilungswege:

• Windows: GPO verteilt Root‑Cert in Trusted Root Certification Authorities.
• Linux/Servers: zentraler CA‑Bundle in /etc/pki/ca‑trust/source/anchors und update‑ca‑trust ausführen.
• Mobile/Endpunkte: MDM (Mobile Device Management) oder manuelle Installation für managed Geräte.

Testen Sie Rollout in Stufen und prüfen Sie, ob Clients nach Distribution korrekt TLS‑Verbindungen aufbauen und OCSP/CRL prüfen.

Skalierung, Performance und Hochverfügbarkeit

Skalierung betrifft vor allem OCSP und CRL‑Distribution. OCSP‑Responder müssen niedrige Latenz bieten; übliche Maßnahmen:

• OCSP Caching (Responder und Load Balancer) und Anycast für geografische Verteilung.
• CDN für CRL‑Bereitstellung mit passenden Cache‑Control Headern und TTLs.
• Monitoring von Antwortzeiten und Fehlerquoten; automatisches Failover des Responders.

# 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

Bereiten Sie ein klares Runbook für Vorfälle vor. Wichtige Schritte bei Root/CA‑Komprimittierung oder HSM‑Ausfall:

1. Isolieren Sie betroffene Systeme und heben Sie Beweismittel (Logs). Dokumentieren Sie Zeitpunkte.
2. Revoke kompromittierter Zertifikate und publizieren Sie sofort eine CRL‑Update und OCSP‑Status „revoked“.
3. Wenn Root kompromittiert: Plan für Cross‑Sign oder Neuaufbau der PKI mit parallelem Rollout neuer Root/Sub‑CAs; informieren Sie betroffene Teams.
4. Testen Sie Wiederherstellung aus Backup, inklusive HSM‑Import oder Ersatz‑HSM‑Prozeduren.

Regelmäßige DR‑Drills (mindestens jährlich) sind Pflicht: testen Sie Wiederherstellungsschritte schriftlich und führen Sie eine End‑to‑End Validierung durch.

Praktische Prüf‑Commands & Beispiele

Einige nützliche Prüfungen, die Sie regelmäßig in Ihre Runbooks integrieren sollten:

# Zertifikatspfadprüfung
openssl verify -CAfile chain.pem service.cert.pem

# CRL herunterladen und prüfen
curl -sS -o crl.der http://crl.example.local/crl.der
openssl crl -in crl.der -inform DER -text -noout

# OCSP Testabfrage einer Produktions-URL
openssl ocsp -issuer subca.cert.pem -cert service.cert.pem -url http://ocsp.example.local:2560 -header "HOST" "ocsp.example.local" -resp_text

# HSM Slot/Token-Status (pkcs11-tool)
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -L
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -T

Fazit

Private PKI betreiben erfordert mehr als nur Zertifikate ausstellen: klare Policies, sichere Schlüsselaufbewahrung (idealerweise HSM), Automation für Issue/Renew/Revoke, Monitoring und getestete Recovery‑Prozeduren. OpenSSL bietet maximale Kontrolle, CFSSL erleichtert API‑basierte Automatisierung. CRL und OCSP ergänzen sich in Robustheit und Reaktionsgeschwindigkeit. Testen Sie HSM‑Workflows, prüfen Sie CRL/OCSP‑Erreichbarkeit automatisch und halten Sie ein schriftliches Runbook für Rotation und Incident Response bereit. Eine gut dokumentierte PKI minimiert Betriebsrisiken und hält Ihre internen TLS‑Abhängigkeiten zuverlässig am Laufen.

Weiterführende Ressourcen und interne Links

Für tiefere Integrationen prüfen Sie Tool‑Dokumentationen: CFSSL, OpenSSL Engine PKCS#11, SoftHSM und die HSM‑Vendorspezifikationen. Planen Sie außerdem ein Audit der PKI‑Policies und regelmäßige Restore‑Proben, ähnlich wie bei Backup‑Recovery‑Tests in anderen kritischen Systemen.

Für dieses Thema sind auch Openssl Pki und Hsm Integration wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.