FAQ

Nein. Certificate Lifecycle Management (CLM) steuert den Lebenszyklus von Machine Identities insgesamt, nicht nur Server-TLS. Typische Abdeckung: TLS-Server und -Clients (mTLS), Zertifikate für APIs/Gateways, Kubernetes/Ingress und Service-Mesh-Workloads, Geräte- und IoT-Identitäten, Code-Signing sowie S/MIME. Wert entsteht, wenn Inventory, Ownership, Ausstellung, Erneuerung, Rotation, Widerruf und Deployment zentral automatisiert und revisionssicher laufen.

Ja. Häufig bleibt AD CS als Issuing-CA bestehen, während CLM als Orchestrator darüberliegt. Ein bewährtes Zielbild: Discovery und Inventarisierung (Windows, Linux, Appliances, Cloud, Kubernetes), standardisierte Templates/Policies, automatisierte Enrollment- und Renewal-Flows (inkl. Installation und Service-Reload) sowie klare Rollen und Zuständigkeiten (CA-Administration getrennt von Anwendungs-Ownern). So bleiben Investitionen erhalten und Prozesse werden einheitlich auditierbar.

Outages entstehen meist durch fehlende Sichtbarkeit und zu späte Erneuerung. Wirksam sind: vollständige Inventarisierung (inkl. Shadow-IT), eindeutige Ownership/Metadaten, Alert-Stufen (z. B. 90/60/30/14/7/1 Tage), automatisierte Erneuerung mit Installation/Deployment sowie technische Checks (Chain-Validation, Hostname/SAN, TLS-Handshake, mTLS-Auth). Zusätzlich sollte die gesamte Kette (Root/Intermediate/Leaf) überwacht werden, damit ein Zwischenzertifikat nicht unbemerkt zum Single Point of Failure wird.

HSMs schützen besonders kritische Schlüssel (Root-CA, Issuing-CAs, Code-Signing) durch hardwarebasierte Isolation und kontrollierte Kryptofunktionen, oft mit Zertifizierungen wie FIPS 140-2/140-3. Best Practice: Offline-Root (nur zum Signieren der Issuing-CAs), Issuing-CAs mit HSM-Backing, dokumentierte Key-Ceremonies (z. B. M-of-N-Kontrolle), klare Rollen (Security Officer vs. Operator) und getestete Backup/Recovery-Prozesse. Technisch erfolgt die Einbindung typischerweise über PKCS#11 oder herstellerspezifische Provider.

PKI beschreibt die Infrastruktur und Vertrauenskette (Root/Intermediate-CA, Policies, CRL/OCSP) zur Ausstellung von X.509-Zertifikaten (RFC 5280). CLM ist die operative Disziplin und Tooling-Schicht darüber: Inventarisierung, Genehmigung, Ausstellung, Verteilung/Installation, Erneuerung, Rotation und Widerruf. Ohne CLM bleibt PKI oft handbetrieben, was bei hundert bis tausenden Zertifikaten schnell zu Ausfällen führt.

Im Browser-Ökosystem gilt für öffentlich vertrauenswürdige TLS-Serverzertifikate seit einigen Jahren als gängige Obergrenze 398 Tage (ca. 13 Monate). Das zwingt Organisationen, Renewal-Automatisierung und saubere Zuständigkeiten aufzubauen. Intern (Private CA) kann man andere Laufzeiten wählen, sollte aber aus Sicherheits- und Betriebsgründen eher kürzer als länger denken.

Für TLS ist RFC 8446 (TLS 1.3) zentral; für Zertifikatsprofile RFC 5280. OCSP ist in RFC 6960 beschrieben, Certificate Transparency in RFC 6962. Für Automatisierung ist ACME (RFC 8555) de facto Standard für öffentliches TLS; in Enterprise/Devices spielen auch EST (RFC 7030) sowie CMP (RFC 4210) eine Rolle.

Praktisch braucht man Discovery über alle Orte, an denen Zertifikate liegen: Webserver, Load Balancer, API-Gateways, Java Keystores, Windows Zertifikatsspeicher, Kubernetes Secrets/Ingress, Cloud KMS, CI/CD und Code-Signing-Stores. Wichtig sind Metadaten: Owner, System, Umgebung, Kritikalität, Ablaufdatum, Issuer, Schlüsseltyp/Größe und Deployment-Ziele. Ein brauchbarer KPI ist: Anteil der Zertifikate mit zugewiesenem Owner (Ziel: 100%).

Shadow Certificates entstehen, wenn Teams selbstständig Zertifikate beschaffen und deployen, ohne zentrale Sichtbarkeit. Gegenmaßnahmen: Discovery/Scanning, verpflichtende Ausgabewege (z. B. über CLM), Richtlinien für Allowed Issuers, sowie Blocken nicht genehmigter CAs an zentralen Punkten (Ingress/LB). CT-Monitoring (RFC 6962) hilft zusätzlich bei öffentlich ausgestellten Zertifikaten für eigene Domains.

ACME (RFC 8555) ist optimal für automatisierte TLS-Zertifikate (DNS/HTTP-Challenges). SCEP ist historisch weit verbreitet, aber funktional begrenzt; EST (RFC 7030) ist moderner und besser für Geräte/Enterprise. CMP (RFC 4210) ist sehr mächtig (komplexe PKI-Workflows), aber aufwendiger in Integration und Betrieb.

Erneuerung umfasst nicht nur die neue Ausstellung, sondern kontrolliertes Deployment: Zertifikat schreiben, Dienst reloaden, Health-Check (TLS Handshake, SNI/SAN, Chain), dann erst umschalten. Bei Load Balancern/Ingress sollte der Rollout gestaffelt erfolgen (Canary). Bewährt sind Renewal-Fenster von 30 bis 60 Tagen vor Ablauf und automatische Retries inklusive Audit-Trail.

Renewal ersetzt typischerweise das Zertifikat, kann aber denselben Key weiterverwenden. Key Rotation bedeutet: neuer privater Schlüssel plus neues Zertifikat. Für hohe Sicherheit empfiehlt sich Rotation, z. B. periodisch oder bei jedem Renewal, besonders bei Workloads mit erhöhtem Risiko oder bei Verdacht auf Key-Exposure.

In der Praxis ist RSA-2048 weit verbreitet; für höhere Sicherheitsmargen wird RSA-3072 genutzt. Bei ECC sind Kurven wie P-256 gängig und effizient (weniger CPU, kleinere Schlüssel). Wichtig ist, den Algorithmus mit Client-Kompatibilität (Legacy-Devices) und internen Policies abzustimmen.

Korrekt heißt: vollständige Chain bis zum Trust Anchor, richtige Reihenfolge, und passende SAN-Einträge (DNS/IP). Zusätzlich müssen Key Usage und Extended Key Usage passen (z. B. Server Auth, Client Auth). Ein häufiger Fehler ist ein fehlendes Intermediate im Deployment; restriktive Clients brechen dann hart ab.

CRL ist einfach, kann aber groß werden und wird oft selten aktualisiert. OCSP (RFC 6960) ermöglicht Online-Statusabfragen pro Zertifikat, belastet aber den Responder und ist operativ kritisch. In der Praxis reduziert OCSP Stapling den Laufzeit-Impact und macht Widerrufsprüfung robuster.

Beim Stapling liefert der Server den OCSP-Status direkt im TLS-Handshake mit, statt dass der Client separat den Responder abfragt. Das senkt Latenz und entkoppelt Clients von der Erreichbarkeit des OCSP-Responders. Für hochverfügbare Services ist Stapling oft ein Muss.

CT (RFC 6962) protokolliert öffentlich ausgestellte TLS-Zertifikate in CT-Logs. Monitoring kann Miss-issuance schneller sichtbar machen (Zertifikate für Ihre Domain, die nicht von Ihnen beantragt wurden). Operational sinnvoll: CT-Alerts mit Playbook (Validierung, ggf. Widerruf, Incident-Prozess).

Das ist Policy-Arbeit: verbiete SHA-1 und RSA-1024, erzwinge Mindestgrößen (z. B. RSA-2048+) und moderne Signaturalgorithmen. Setze diese Regeln in CA-Templates, CLM-Gates und CI/CD-Checks um. Zusätzlich sollten TLS-Policy und Cipher Suites zentral gemanagt werden.

Ansätze: Zertifikate als Secrets per Controller/Operator erneuern, Ingress-Controller mit automatisierter Zertifikatsbindung, Service-Mesh mTLS mit Workload-Identitäten. Wichtig ist die Trennung von Ausstellen (CA/CLM) und Verteilen (K8s). Achte auf kurze Laufzeiten und automatische Rolling Restarts, damit Pods den neuen Key nutzen.

mTLS braucht Automatisierung. Bewährt: kurze Laufzeiten, automatisches Renewal, klar definierte Trust-Domains und Policies für ClientAuth. SPIFFE/SPIRE kann Workload-Identitäten standardisieren; CLM muss Ausstellung, Rotation und Audits abdecken. Ein guter KPI ist der Anteil automatisierter mTLS-Renewals (Ziel: nahe 100%).

Viele Ausfälle entstehen an nicht automatisierten Endpunkten. Für Appliances braucht man API-basierte Installation, einheitliche Naming-Konventionen und Rollback. Ohne CLM-Connectoren bleibt es Handarbeit und damit ein Ausfallrisiko.

Code Signing braucht streng getrennte Keys (idealerweise im HSM) und Freigabeprozesse. Für langfristige Verifizierbarkeit ist Time-Stamping nach RFC 3161 wichtig, damit Signaturen auch nach Zertifikatsablauf prüfbar sind. Signier-Keys gehören nicht auf Build-Agenten, sondern in HSM/KMS-gestützte Signierdienste.

Public CAs sind für Internet-Trust geeignet, folgen aber strengen Regeln und kürzeren Laufzeiten. Private CAs geben Flexibilität (mTLS, Devices), erfordern aber Governance: Root offline, Intermediates, Revocation, Logging, Audits und Rollenkonzepte. Besser als viele CAs ohne Ownership ist eine klare CA-Hierarchie pro Trust-Domain.

OCSP/CRL sind betriebliche Abhängigkeiten: Responder/Distribution Points müssen hochverfügbar und global erreichbar sein. Plane Redundanz (mindestens aktiv/aktiv), SLAs und Monitoring (Latenz, Fehlerquoten, Datenaktualität). Für Issuing-CAs gilt: keine Single Points, saubere Backups und getestete Restore-Prozesse.

Neben Ablaufdatum sollten auch Signale überwacht werden: fehlender Owner, fehlgeschlagene Deployments, unerwartete Issuer, Policy-Verstöße, ungewöhnliche Ausstellungsraten. Robust ist mehrstufige Alarmierung (z. B. 30/14/7/1 Tage) und Integration in Oncall/ITSM. KPI: Renewal Success Rate und Anzahl eskalierter Incidents pro Quartal.

Klassiker: Zertifikat abgelaufen, falscher SAN/Hostname, fehlendes Intermediate, Key-Mismatch, Mixed-Chain nach CA-Wechsel, oder Dienste laden das neue Zertifikat nicht (kein Reload). Auch Intermediate-Rotation wird oft unterschätzt: Chain-Updates müssen überall sauber ausgerollt werden. Automatisierte Handshake-Checks gegen reale Clients reduzieren das Risiko deutlich.

Bei Intermediate-Wechsel ist Chain-Management zentral: neue Chain vorbereiten, Overlap-Phasen berücksichtigen, Rollouts stufenweise durchführen. Teste kritischste Clients (Legacy-Java, Embedded) vor dem Cutover. Halte ein Migrations-Playbook mit Cutover-Plan, Telemetrie und Rollback-Kriterien vor.

Krypto-Agilität heißt: Algorithmen, Schlüsselgrößen und Policies können ohne Großprojekt gewechselt werden. Dazu braucht es zentral definierte Policies, automatisierte Rotation und Konfiguration als Code. Metrik: Wie schnell lässt sich ein Algorithmuswechsel auf X Prozent der Endpunkte ausrollen?

PQC ist ein mehrjähriger Übergang: Inventar der Algorithmen, Bewertung von Langzeitvertraulichkeit (z. B. 10+ Jahre), und Planung für Hybrid-Ansätze. TLS, VPN, S/MIME und Code Signing müssen PQC-fähige Clients/Bibliotheken unterstützen. Kurzfristig ist Krypto-Agilität der wichtigste Schritt, um spätere Umstellungen operational beherrschbar zu machen.

KPIs sind: Coverage (Prozent der Zertifikate im Inventory), Owner-Zuordnung (Ziel 100%), Automatisierungsgrad, Renewal Success Rate, ungeplante Zertifikatsincidents, Median-Time-to-Renew, und Anteil Policy-konformer Algorithmen. Ergänzend: Zeit bis Reaktion auf CT-Alerts sowie Rollout-Zeit bei CA/Intermediate-Änderungen.