TLS ist gelöst. Oder?
Let's Encrypt, AWS Certificate Manager, Cloudflare – automatische Zertifikatsverwaltung ist heute Standard. Kostenlose oder integrierte Zertifikate, automatische Erneuerung, kurze Laufzeiten. Problem gelöst.
Bis es nicht mehr funktioniert.
Und dann ist deine Seite offline. Nicht weil dein Server abgestürzt ist. Nicht weil deine Datenbank voll ist. Sondern weil ein Zertifikat abgelaufen ist und der Browser deinen Nutzern eine Warnseite zeigt, die sie nie wegklicken werden.
Warum automatische Erneuerung fehlschlägt
Die Liste ist länger als man denkt:
• DNS-Challenge schlägt fehl, weil sich ein Record geändert hat
• HTTP-Challenge schlägt fehl, weil ein Reverse Proxy umkonfiguriert wurde
• Certbot-Cronjob wurde bei einem Server-Update überschrieben
• Rate Limits bei Let's Encrypt erreicht (zu viele Requests)
• Wildcard-Zertifikat braucht DNS-Challenge, aber der API-Key zum DNS-Provider ist abgelaufen
• AWS Certificate Manager kann die Domain nicht mehr validieren, weil die Validierungs-Records gelöscht wurden
• Container wurde neu deployed, aber ohne das Volume mit den Zertifikaten
• Kubernetes Cert-Manager hat ein Problem mit dem Issuer-Config
• Cloudflare-Integration verliert die Verbindung zum Origin nach einer Konfigurationsänderung
Jeder dieser Fälle ist real. Jeder führt zum gleichen Ergebnis: Zertifikat läuft aus, Seite zeigt Fehlermeldung, Nutzer sind weg.
Das Zeitfenster ist klein
Let's Encrypt Zertifikate laufen nach 90 Tagen ab. Die Erneuerung passiert typischerweise 30 Tage vorher. Das heißt: Wenn die Erneuerung fehlschlägt, hast du 30 Tage um es zu merken.
Klingt viel. Aber wenn niemand aktiv hinschaut, merkst du es erst am Tag des Ablaufs. Oder schlimmer: Deine Nutzer merken es vor dir.
Bei Zertifikaten mit längerer Laufzeit (1 Jahr) ist das Fenster noch tückischer. Die Erneuerung steht einmal im Jahr an – genau der Zeitpunkt, an dem sich niemand mehr erinnert, wie es eingerichtet wurde.
Das andere Problem: Unerwartete Neuausstellungen
Nicht nur fehlende Erneuerung ist ein Problem. Auch das Gegenteil kann gefährlich sein: Ein Zertifikat wird ausgestellt, das du nicht bestellt hast.
Was das bedeuten kann:
• Jemand hat DNS-Kontrolle erlangt und die ACME-Challenge bestanden
• Ein Angreifer hat ein Zertifikat bei einer anderen CA beantragt
• Ein alter Prozess oder ein vergessener Server erneuert noch Zertifikate für eine Domain, die du migriert hast
In jedem Fall: Es existiert ein gültiges Zertifikat für deine Domain, das du nicht kontrollierst. Der Browser deiner Nutzer wird es akzeptieren. Kein Alarm, kein Fehler – einfach ein grünes Schloss auf einer Seite, die nicht dir gehört.
Was sich ändert und was gleich bleibt
Bei einem gesunden Zertifikat ändern sich regelmäßig:
• Das Ablaufdatum (bei jeder Erneuerung)
• Die Seriennummer (jedes Zertifikat hat eine neue)
• Der Fingerprint
Was gleich bleiben sollte:
• Der Issuer (deine CA)
• Die SANs (Subject Alternative Names – für welche Domains es gilt)
• Der Key-Typ und die Key-Größe
Wenn sich der Issuer ändert, hat jemand ein Zertifikat von einer anderen CA geholt. Wenn sich die SANs ändern, deckt das Zertifikat plötzlich andere Domains ab. Beides sind Signale, die du sofort sehen willst.
Was Driftguard erkennt
Driftguard überwacht deine TLS-Zertifikate auf mehreren Ebenen:
Ablauf-Tracking: Wie viele Tage bis zum Ablauf? Wurde rechtzeitig erneuert? Wenn das Zertifikat sich dem Ablaufdatum nähert ohne erneuert zu werden, wirst du alarmiert – nicht erst am Tag des Ausfalls.
Issuer-Wechsel: Hat sich die ausstellende CA geändert? Von Let's Encrypt zu einer unbekannten CA? Das ist ein starkes Signal.
SAN-Änderungen: Deckt das Zertifikat plötzlich andere Domains ab? Oder fehlen Domains, die vorher drin waren?
Unerwartete Neuausstellung: Ein neues Zertifikat taucht auf, obwohl das alte noch gültig war und keine Erneuerung fällig war. Warum?
Alles wird dokumentiert, alles ist nachvollziehbar. Damit du den Unterschied siehst zwischen "planmäßig erneuert" und "hier stimmt etwas nicht".