Das Zertifikat erneuert sich automatisch – aber wer merkt, wenn es nicht passiert?

Ein grünes Schloss im Browser wirkt endgültig. Ist es aber nicht.

TLS-Zertifikate laufen ab, Erneuerungen scheitern, DNS-Einträge ändern sich, Challenge-Pfade werden blockiert und neue Infrastruktur übernimmt alte Domains nur halb. Das Ergebnis ist selten eine elegante Fehlermeldung. Meist sehen Besucher plötzlich eine Sicherheitswarnung – genau dort, wo Vertrauen, Kontaktanfragen oder Umsatz entstehen sollen.

Die gefährliche Annahme lautet: „Das Zertifikat erneuert sich automatisch.“ Automatisierung reduziert Handarbeit. Sie ersetzt keine Überwachung.

Warum automatische Erneuerung trotzdem scheitert

ACME automatisiert Ausstellung und Verwaltung von Zertifikaten. Trotzdem hängt die Erneuerung von mehreren beweglichen Teilen ab:

• Der ACME-Client muss laufen und korrekt konfiguriert sein.
• Die Domain muss weiterhin auf die erwartete Infrastruktur zeigen.
• HTTP- oder DNS-Challenges müssen erreichbar und autorisiert sein.
• Reverse Proxy, CDN oder Firewall dürfen die Validierung nicht blockieren.
• Das neu ausgestellte Zertifikat muss vom aktiven Dienst geladen werden.
• Wildcard-, Subdomain- und Alt-Domain-Konfigurationen müssen vollständig bleiben.

Ein erfolgreicher Cronjob bedeutet daher noch nicht, dass die Website das neue Zertifikat ausliefert.

Fünf Warnzeichen, die Teams oft übersehen

1. Es gibt nur E-Mail-Erinnerungen

Erinnerungen landen schnell im falschen Postfach, bei einer ehemaligen Agentur oder in einer überfüllten Shared Inbox. Kritische Infrastruktur darf nicht davon abhängen, dass jemand eine einzelne Nachricht rechtzeitig sieht.

2. Das Monitoring prüft nur die Startseite

Eine Organisation kann Zertifikate für Hauptdomain, www, App, API, Adminbereich, CDN, Mail-Tracking-Domain oder Kunden-Subdomains betreiben. Ein grüner Check für die Homepage sagt nichts über den Rest.

3. Das Zertifikat wurde erneuert, aber nicht aktiviert

Ein typischer Fehler: Das Zertifikat liegt korrekt auf dem Server, doch Nginx, Caddy, Traefik oder der Anwendungsprozess verwendet weiterhin die alte Datei oder wurde nicht neu geladen.

4. Niemand überwacht unerwartete Ausstellung

Zertifikatsmonitoring sollte nicht nur Ablaufdaten beobachten. Certificate-Transparency-Daten und CAA-Regeln können ungewollte oder falsch konfigurierte Ausstellung sichtbar machen. CAA erlaubt Domaininhabern, festzulegen, welche Zertifizierungsstellen ausstellen dürfen.

5. Die Verantwortlichkeit ist nicht dokumentiert

Wer reagiert nachts oder am Wochenende? Wer besitzt den ACME-Account? Wo liegen Account-Schlüssel, DNS-Zugänge und Runbook? Ohne klare Zuständigkeit wird aus einem kleinen Zertifikatsproblem ein Hosting-, DNS- und Agentur-Rätsel.

Ein brauchbarer TLS-Selbstcheck

• Welche Domains und Subdomains benötigen Zertifikate?
• Welcher Dienst stellt sie aus und erneuert sie?
• Wann läuft jedes aktive Zertifikat ab?
• Wird extern geprüft, was ein echter Browser tatsächlich erhält?
• Gibt es Warnungen bei 30, 14, 7 und 3 Tagen Restlaufzeit?
• Wird nach der Erneuerung das ausgelieferte Zertifikat erneut kontrolliert?
• Sind ACME-Fehler und Proxy-Logs zentral sichtbar?
• Sind CAA-Einträge vorhanden und noch passend?
• Gibt es einen dokumentierten manuellen Notfallweg?
• Kann eine zweite Person den Prozess ohne Spezialwissen übernehmen?

Wenn mehrere Antworten fehlen, ist das Problem nicht das Zertifikat selbst. Es ist die fehlende Betriebsfähigkeit rundherum.

So sollte die Überwachung aussehen

1. Externe TLS-Prüfung: Sie kontrolliert den öffentlich ausgelieferten Endpunkt, nicht nur lokale Dateien.
2. Ablaufwarnungen mit Eskalation: Mehrere Zeitfenster und mehr als eine verantwortliche Person.
3. ACME- und Deployment-Logs: Fehler werden sichtbar, bevor das Zertifikat kritisch kurz vor Ablauf steht.
4. Inventar aller Hostnamen: Auch APIs, Redirect-Domains und selten genutzte Subdomains.
5. Post-Renewal-Verifikation: Seriennummer, Gültigkeit und Zertifikatskette am öffentlichen Endpunkt prüfen.
6. CAA- und DNS-Review: Schutzregeln dürfen den legitimen Erneuerungsweg nicht blockieren.
7. Runbook: Provider, Accounts, Schlüsselzuständigkeit, DNS-Verfahren, Notfallkontakte und Wiederherstellung dokumentieren.

Was Website-Pflichtencheck prüfen würde

Ein technischer Website-Check kann zeigen, ob Zertifikatsmanagement nur „irgendwie automatisch“ läuft oder wirklich belastbar ist. Geprüft werden können öffentlich ausgelieferte Zertifikate und Ketten, Ablaufzeiten, Domainabdeckung, HSTS- und HTTPS-Konfiguration, CAA-Einträge, Monitoring, Alarmierungswege sowie dokumentierte Zuständigkeiten.

Das Ziel ist nicht, noch ein Dashboard einzuführen. Das Ziel ist, eine peinlich einfache Frage jederzeit beantworten zu können: Wer merkt es zuerst, wenn die automatische Erneuerung nicht funktioniert – Ihr Team oder Ihre Kunden?

Wenn die ehrliche Antwort „wahrscheinlich die Kunden“ lautet, ist jetzt der richtige Zeitpunkt für einen strukturierten TLS- und Betriebscheck.