Einordnungen und Kurzmeldungen zu Trends, Standards und Vorfällen rund um Public Key Infrastructure (PKI), Certificate Lifecycle Management (CLM), Zertifikate und Verschlüsselung.
Die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Serverzertifikate liegt seit 2020 bei 398 Tagen (vorher 825). Wenn Organisationen zusätzlich auf 90‑Tage‑Zyklen umstellen, wird Automatisierung zwingend: Inventar, Policy, Issuance und Renewal müssen ohne Tickets laufen. Best Practice ist ein Erneuerungsfenster von 30 Tagen sowie Monitoring auf „notAfter“, Key-Usage und SAN-Änderungen.
In Zero-Trust-Architekturen wird Certificate Lifecycle Management (CLM) zum Policy-Enforcer: Ausstellen nur bei erfüllten Controls (z.B. attested Workload, korrekter SPIFFE-ID, genehmigte SANs) und automatische Sperrung bei Policy-Verstößen. Technisch etabliert sind Mindeststandards wie RSA‑2048 oder ECDSA P‑256 sowie kurze Rotationszyklen (30–90 Tage) für Maschinenidentitäten. Damit wird mTLS nicht nur Verschlüsselung, sondern auch kontinuierliche Authentisierung.
Mit Service Mesh und mTLS steigt die Zahl der Maschinenzertifikate sprunghaft. Beispiel: 500 Services mit 20 Replikas erzeugen 10.000 Workload-Identitäten, jeweils mit mindestens einem Zertifikat plus Zwischen- und Root-Chain. Skalierbar wird das nur mit automatischer Issuance, Rotation und sauberer Telemetrie (Zertifikatsalter, Fehlerraten bei Handshakes, Aussteller/Issuer).
Krypto-Agilität bedeutet, Algorithmen und Key-Parameter wechseln zu können, ohne Anwendungen neu zu bauen. Praktisch heißt das: abstrahierte Crypto-Policies (z.B. RSA‑2048 → ECDSA P‑256) und vorbereitete Pfade für Hybrid-/Post-Quantum-Verfahren. Entscheidend sind saubere Schnittstellen, Konfigurierbarkeit und Tests, damit ein Algorithmuswechsel in Tagen statt Quartalen gelingt.
Post-Quantum-Migration startet mit Inventar und Risikoklassifizierung: Wo werden heute RSA/ECC genutzt (TLS, S/MIME, Code Signing, Geräteidentitäten), welche Laufzeiten haben die Zertifikate und welche Systeme verarbeiten die Keys. NIST hat 2022 die ersten Kandidaten zur Standardisierung benannt (u.a. CRYSTALS‑Kyber, CRYSTALS‑Dilithium, SPHINCS+). In Pilotprojekten werden häufig Hybrid-Ansätze getestet, weil PQC-Keys und Signaturen typischerweise deutlich größer sind (oft mehrere Kilobyte) und damit Handshake-Größe, MTU und Latenz beeinflussen können.
ACME ist seit RFC 8555 (2019) der De‑facto‑Standard für automatisierte Zertifikatsausstellung. In der Praxis wird ACME längst nicht mehr nur fürs Web genutzt, sondern auch für interne PKI, APIs, Geräte und mTLS. Typische Patterns: DNS‑01 für Wildcards/Headless-Workloads, feste Renewal-Policies (z.B. T‑30 Tage) und zentrale Error-Budgets für fehlgeschlagene Renewals.
„Key-Protection by Default“ setzt sich durch: Private Keys sollten HSM- oder KMS-gestützt erzeugt und genutzt werden, sodass sie die Schutzboundary nicht verlassen. Das reduziert das Risiko von Key-Exfiltration und erleichtert Audits, etwa entlang FIPS 140‑2/140‑3 Controls. Übliche Baselines sind AES‑256 für Datenverschlüsselung sowie RSA‑2048 oder ECDSA P‑256 für Signaturen, kombiniert mit rollenbasierter Trennung (Generate, Approve, Use).
Certificate Transparency (CT) macht Fehl- oder Miss‑Issuance sichtbar, weil Zertifikate in append-only Logs mit SCTs nachweisbar protokolliert werden. Operativ wird Monitoring zur Pflichtdisziplin: Watchlists auf eigene Domains, Alerts bei unbekannten Issuern, und Abgleich gegen erlaubte SAN-Patterns. Damit lassen sich unerwartete Zertifikate oft innerhalb von Stunden identifizieren, statt erst bei Incident-Response.
Zertifikate sind Identitäten, ihre Private Keys sind Secrets. Moderne Plattformen trennen daher klar: Secret-Store für Key-Material, CLM für Policy und Lifecycle (Issuance, Renewal, Revocation). Für Maschinenidentitäten sind kurze Gültigkeiten (30–90 Tage) plus automatische Rotation der Schlüsselpaare der Standard, damit Key-Compromise nicht Jahre nachwirkt.
In Kubernetes ist cert-manager quasi Standard für interne Issuance und automatisches Renewal. Über CRDs wie Certificate, Issuer und ClusterIssuer werden Policies als Code abgebildet, inklusive Rotation vor Ablauf und automatischer Chain-Verteilung. In Multi-Cluster-Setups ist entscheidend, dass Issuer-Typen (ACME, Vault, interne CA) konsistent konfiguriert sind und dass Zertifikate nicht „silent“ auslaufen.
S/MIME erlebt ein Comeback, getrieben durch Compliance-Programme und den Bedarf an nachweisbarer E-Mail-Integrität. Technisch basiert S/MIME auf X.509: Signaturen (typisch RSA‑2048 oder ECDSA P‑256) plus optionaler Verschlüsselung des Inhalts. CLM wird wichtig, weil Zertifikate für User, Gruppen und Gateways ausgestellt, erneuert und bei Rollenwechseln zügig gesperrt werden müssen.
Revocation bleibt schwierig: OCSP/CRL sind nicht überall zuverlässig, und viele Clients verhalten sich aus Verfügbarkeitsgründen „soft-fail“. Daher kombinieren robuste Designs mehrere Maßnahmen: OCSP Stapling, kurze Zertifikatslaufzeiten, schnelle Key-Rotation und strikte Incident-Prozesse für Key-Compromise. Ein guter CLM-Ansatz misst Revocation- und Renewal-Erfolg als SLO, nicht als Einmalprojekt.
Die 398‑Tage‑Regel für öffentliche TLS-Zertifikate zwingt zu kürzeren Renewal-Zyklen und sauberem Lifecycle-Management. Vorher waren bis zu 825 Tage üblich; viele Legacy-Prozesse (jährliche Maintenance Windows) passen dazu nicht mehr. Praxistipp: ein zentrales Zertifikatsinventar mit Expiry-Forecasting und automatischen Renewals senkt Ausfälle durch abgelaufene Zertifikate messbar.
mTLS etabliert sich als Default für Ost‑West‑Traffic: Jede Verbindung ist verschlüsselt und beide Seiten authentisieren sich per Zertifikat. Identity-Frameworks wie SPIFFE standardisieren die Darstellung von Workload-Identitäten; Rotation wird oft auf Stunden oder wenige Tage ausgelegt, damit kompromittierte Keys schnell obsolet werden. CLM wird damit Teil der Service-Reliability.
Remote Work hat die PKI-Last erhöht: Geräte-, VPN- und Access-Zertifikate müssen in großer Zahl verteilt, erneuert und bei Device-Loss sofort invalidiert werden. Häufige Muster sind EAP‑TLS/802.1X für Netzwerkzugang und clientseitige Zertifikate für MDM/Zero‑Trust-Access. Ohne Automatisierung sind schon einige Tausend Endpoints operativ kaum stabil zu betreiben.
TLS 1.3 (RFC 8446, 2018) reduziert den Standard-Handshake von 2 RTT auf 1 RTT und entfernt veraltete Kryptografie (z.B. statische RSA-Key-Exchange). Es erlaubt optional 0‑RTT Early Data und setzt auf AEAD-Cipher-Suites wie AES‑GCM und ChaCha20‑Poly1305. Für PKI/CLM heißt das: Zertifikate bleiben zentral, aber Fehlkonfigurationen (Chain, SAN, Key-Usage) fallen schneller und häufiger im Betrieb auf.
„Short‑Lived Certificates“ reduzieren den Schmerz von Revocation: Wenn ein Zertifikat nur 24 Stunden oder wenige Tage gilt, wird ein kompromittierter Key schnell wertlos. Der Trade-off ist operativ: Time-Sync (NTP), hochverfügbare Issuer und robuste Auto-Renewal-Pipelines. CLM verschiebt sich damit von „Sperrlisten pflegen“ zu „Rotation garantieren“.
Wildcard-Zertifikate lassen sich mit ACME über DNS‑01 automatisiert beziehen, was die Web- und API-Bereitstellung stark vereinfacht. Gerade bei 90‑Tage‑Zertifikaten (wie bei vielen öffentlichen CAs üblich) wird Automation zur Voraussetzung, weil man sonst jährlich vier Renewals pro Zertifikat manuell betreuen müsste. Wichtig ist dabei ein sauber abgesicherter DNS-Workflow, weil DNS‑01 direkt die Domain-Kontrolle beweist.
Trust-Store-Änderungen in Browsern zeigen die Governance-Seite von PKI: Wenn eine CA Vertrauen verliert, müssen Unternehmen Zertifikate in Wochen bis Monaten migrieren, inklusive Chain-Updates auf Load Balancern, Appliances und Legacy-Servern. Das unterstreicht die Notwendigkeit eines vollständigen Zertifikatsinventars und eines „CA-Wechsel“-Runbooks. Technische Controls wie CT-Monitoring und klare Allowed-Issuer-Listen reduzieren Überraschungen.
Kostenlose und automatisierte DV-Zertifikate (z.B. mit ACME) haben HTTPS massiv beschleunigt. Typisch sind kurze Laufzeiten von 90 Tagen, wodurch Security schneller nachziehen kann, aber Lifecycle-Prozesse zwingend automatisiert werden müssen. DV bestätigt Domain-Kontrolle, nicht Organisation; daher sind zusätzliche Controls (HSTS, CT-Monitoring, starke Key-Policies) wichtig, wenn Identität kritisch ist.
