Kernaussage: Ein Zertifikatswechsel ist kein Notfall, sondern ein kontrollierter Prozess — wenn er mit klaren Verantwortlichkeiten, automatisierten Prüfungen und abgestuften Rollout-Schritten vorbereitet wird.
Warum ein strukturierter Wechsel wichtig ist
Zertifikate berühren Schnittstellen, Clients, Load Balancer, CI/CD-Pipelines und Überwachungs-Tools. Fehler führen zu Ausfall von APIs, fehlgeschlagenen Backups, Monitoring-Lücken oder blockierten Batch-Jobs. Planen Sie so, dass jeder Schritt überprüfbar ist, Rückfallwege existieren und der Betrieb weiterhin funktioniert, während Änderungen ausgerollt werden.
Bestandsaufnahme: Wo werden Zertifikate verwendet?
- Inventar: Erstellen Sie ein vollständiges, maschinenlesbares Inventar (z. B. CSV oder JSON) sämtlicher Zertifikatseinträge: Hostname/FQDN, IP, Port, Dienst/Applikation, ausstellende CA, Ablaufdatum, SANs, verwendetes Protokoll (TLS1.2/1.3), SNI-Anforderungen, Schlüsselmaterial (HW-Sicherheitsmodul vs. Datei), Verantwortliche.
- Abhängigkeiten: Identifizieren Sie Client-Abhängigkeiten (mTLS-Clients, Pinning, Hardcoded Thumbprints), Load Balancer/Proxy-Konfigurationen (SNI, Backend-TLS) und Integrationen (CI/CD, Monitoring, Logstash, SMTP).
- Zertifikatskette prüfen: Stellen Sie sicher, dass Sie vollständige Chains haben; Testen Sie Vertrauenskette gegen Zielplattformen (Betriebssysteme, Java-Keystores, mobile Geräte).
Technische Entscheidungen vor dem Wechsel
- Schlüsselmanagement: Entscheiden Sie, ob Private Keys rotiert, rekeyed oder übernommen werden. Nutzen Sie HSMs oder Vault-Backends für private Keys; dokumentieren Sie Exportmöglichkeiten für Notfälle.
- Validierungsmethode: Wählen Sie Validierungsverfahren (ACME, manuelle CSR + CA). Bei ACME prüfen Sie die Automatisierungspfade und Wiederherstellungsoptionen bei Let's Encrypt Rate Limits.
- Chain- und Root-Strategie: Entscheiden Sie, ob Sie neue Intermediate-CA verwenden oder bestehende Kette erweitern. Bevorzugen Sie kompatible Chaining ohne neuere Root-Anforderungen, um ältere Clients nicht zu verlieren.
- Protokoll- und Cipher-Politik: Legen Sie fest, ob beim Rollout TLS-Versionen/Cipher verändert werden. Wenn ja, testen Sie Kompatibilität separat, da dies zusätzliche Risiken bringt.
Testbarkeit und Validierung ohne Produktionsrisiko
- Staging-Umgebung: Spiegeln Sie Konfigurationen (SNI, TLS-Profile, Keystores) in einer Staging-Umgebung, die echte Clients simuliert (inkl. Mobile/Embedded, Java-Clients).
- Automatisierte Tests: Implementieren Sie Scripte für:
- Certificate chain validation (openssl verify / Java keytool checks)
- TLS handshake tests (openssl s_client, testssl.sh, sslscan)
- Application-level smoke tests (API-Calls, SMTP-Handshake, LDAP-Bind)
- mTLS-Authentikationstests mit echten Client-Zertifikaten
- Canary-/Blue-Green-Tests: Nutzen Sie Canary-Deployments oder parallele Virtual Hosts, um neues Zertifikat für 1–5% Verkehr zu testen und Telemetrie (errors, latency, TLS handshakes) gegen Baseline zu vergleichen.
- Monitoring vor dem Wechsel: Stellen Sie synthetische Checks bereit (HTTP GET mit TLS-Handshake), sowie Alarmierung bei Certificate Expiry, Chain Changes oder Handshake-Fehlern.
Operative Stolpersteine und wie man sie vermeidet
- Hardcoded Thumbprints und Pinning: Prüfen Sie Repositories/Config-Management auf Thumbprints oder CA-Pinning. Wenn vorhanden, planen Sie Koordination mit allen Teams und gegebenenfalls Dual-Trust-Phase (alt + neu).
- Keystore-Formate: Unterschiedliche Systeme nutzen PEM, PKCS#12, JKS. Automatisieren Sie Konvertierungen und testen Sie Passwörter/Permissions. Vermeiden Sie manuelle Konvertierung in produktiven Schritten.
- Time-synchronisation: TLS scheitert bei falscher Uhrzeit. Überprüfen Sie NTP/Chrony auf allen betroffenen Systemen vor dem Rollout.
- CRL/OCSP availability: Testen Sie Zertifikatsrevocation-Abfragen. Falls OCSP Stapling genutzt wird, prüfen Sie Server-Support und Response-Zeiten.
- Rollback-Plan: Halten Sie vorher exportierte, gültige Zertifikate und Konfigurationen bereit. Stellen Sie sicher, dass Secrets sicher, aber erreichbar sind (z.B. in Vault mit Notfallzugang).
- CI/CD-Integration: Pipeline-Schritte, die Artefakte signieren oder Services betreiben, können TLS-Änderungen benötigen. Führen Sie Testruns der Pipelines gegen Staging mit neuen Zertifikaten durch.
- Betriebspersonal: Definieren Sie Eskalationspfade, Verantwortlichkeiten und Uhrzeiten für produktive Änderungen; vermeiden Sie Changes am Freitagabend.
Go-live-Entscheidungen: inkrementell, messbar, reversibel
- Phasenmodell:
- Phase 0 — Vorbereitung: Inventar, HSM/Vault, Testskripte, Staging-Tests bestehen.
- Phase 1 — Canary: Neues Zertifikat auf Neben-Host oder 1% Traffic; Monitoring intensiv.
- Phase 2 — Staged Rollout: 10–50% Traffic; erweitertes Monitoring.
- Phase 3 — Full Rollout: Alle Instanzen; Validierung und Cleanup (alte Zertifikate entfernen).
- Konfigurationsmanagement: Alle Änderungen via Infrastructure-as-Code (Ansible, Terraform, Helm) ausrollen; keine manuellen SSH-Edits im Live-Betrieb.
- Kommunikation: Planen Sie Wartungsfenster, Stakeholder-Benachrichtigungen und interne Runbooks. Geben Sie präzise Zeitfenster, erwartete Auswirkungen und Kontaktpersonen an.
- Abschlusschecks: Nach Rollout Chain, OCSP/Stapling, Alarmierungen, Client-Fehlerraten, und SLO/KPI-Überwachung prüfen; anschliessend Dokumentation aktualisieren.
Nach dem Wechsel: hardening und Lessons learned
- Zertifikatshalter-Lifecycle: Richten Sie automatisierte Erneuerungen ein (ACME/Cert-Manager) mit Test- und Notfallpfaden.
- Auditing: Erfassen Sie Logs von Handshakes und Fehlern für Postmortem.
- Cleanup: Entfernen Sie alte Zertifikate und Thumbprints, passen Sie Pinning oder Allowlists an.
- Review: Aktualisieren Sie Runbooks, Inventar und definieren Sie Intervallprüfungen (z. B. 30/60/90 Tage vor Ablauf).
14–30-Tage-Plan (nummerierte Schritte)
Tag 0–2: Vollständiges Inventar erstellen (Hostname, Dienst, Keystore-Format, Verantwortliche). Alle Alarm- und Monitoring-Checks identifizieren.
Tag 3–5: Entscheidungsdokument: Schlüsselstrategie (Rekey vs. Same Key), CA-Chain-Strategie, HSM/Vault-Nutzung, Validierungsmethode. Stakeholder absegnen.
Tag 6–8: Staging-Umgebung aufsetzen/aktualisieren; Kopien von Keystores (sicher) und Test-SANs implementieren.
Tag 9–12: Automatisierte Tests entwickeln: Chain-Validation, TLS-Handshakes, mTLS-Tests, Anwendungs-Smoketests. Tests in CI einbauen.
Tag 13–15: Canary-Deployment vorbereiten: Routing/Load Balancer Regeln, Telemetrie-Dashboards, Alarm-Schwellenwerte. Rollback-Mechanismen prüfen.
Tag 16–18: Canary durchführen (1–5% Traffic) während 48–72 Stunden; Fehleranalyse und Anpassungen.
Tag 19–21: Staged Rollout (10–50% Traffic) an 48–72 Stunden; zusätzliche Systeme (SMTP, LDAP, CI/CD) einbinden und testen.
Tag 22–24: Vollausrollen (alle Instanzen) während definiertem Change-Window; Monitoring eng beobachten.
Tag 25–26: Post-Rollout-Validierung: Chain, OCSP/Stapling, Client-Errors, SLOs prüfen; alte Zertifikate entfernen.
Tag 27–28: Dokumentation aktualisieren (Inventar, Runbooks, Konfig-Änderungen), Lessons Learned-Meeting.
Tag 29–30: Automatisierte Erneuerung (ACME/Cert-Manager) testen und in Produktion überführen; Monitoring für Zertifikat-Ablauf finalisieren.
Fazit: Mit Inventar, automatisierten Tests, inkrementellen Rollouts und klaren Rollback-Prozeduren bleibt ein Zertifikatswechsel planbar und sicher. Operative Disziplin (IaC, HSM/Vault, NTP) verhindert die typischen Fehlerquellen und macht den Go-live reproduzierbar.
