SSL-Zertifikat-Ablauf überwachen: nicht erst vom Kunden erfahren

Den SSL-Zertifikat-Ablauf überwachen heißt, den SSL-Ablauf automatisch und regelmäßig zu prüfen, also wie viele Tage das TLS-Zertifikat einer Website noch gültig ist, und rechtzeitig eine Warnung zu bekommen, um es zu erneuern. Läuft ein Zertifikat ab, ersetzen Browser die Seite durch eine bildschirmfüllende Warnung, Formulare, Logins und Checkout funktionieren nicht mehr, und der Traffic bricht fast sofort ein.

Abgelaufene Zertifikate treffen selten die Vorzeige-Website, auf die alle schauen. Sie treffen die Website, die von einer früheren Agentur übernommen wurde, eine Subdomain, die auf keiner Liste stand, und das gern am Wochenende. Viel zu oft merkt es der Kunde vor der Agentur.

Was Besucher und Crawler bei einem abgelaufenen Zertifikat sehen

Chrome zeigt „Dies ist keine sichere Verbindung“ mit dem Fehlercode NET::ERR_CERT_DATE_INVALID. Firefox zeigt „Warnung: Mögliches Sicherheitsrisiko erkannt“ mit SEC_ERROR_EXPIRED_CERTIFICATE. Die meisten Besucher gehen. Sendet die Website einen Strict-Transport-Security-Header (HSTS), bieten Browser nicht einmal die Möglichkeit an, trotzdem fortzufahren, und für wiederkehrende Besucher ist die Website schlicht nicht erreichbar.

Die Analytics-Kurve wird flach, weil die Seite nie lädt und das Tracking-Skript nie läuft. Zahlungs- und Lead-Formulare scheitern. Server-zu-Server-Aufrufe, etwa Webhooks eines Zahlungsanbieters, lehnen das Zertifikat ab und protokollieren den Fehler meist irgendwo, wo niemand hinschaut. Googlebot bekommt Abruffehler, und dauert das Problem Tage statt Stunden, verlangsamt sich das Crawling und Seiten können aus dem Index fallen.

Warum Zertifikate trotz Auto-Renewal ablaufen

Let's-Encrypt-Zertifikate sind 90 Tage gültig, und die Erneuerung ist normalerweise ein geplanter Job, den Certbot oder das Hosting-Panel ausführt. Dieser Job scheitert auf eine Handvoll vorhersehbarer Arten.

Der Job selbst geht kaputt. Ein Paket-Upgrade, eine geänderte Python-Umgebung oder eine volle Festplatte lassen certbot renew mit einem Fehler abbrechen, der in /var/log/letsencrypt/ landet und sonst nirgends. Außerdem hat Let's Encrypt 2025 den Versand seiner Erinnerungsmails zum Ablauf eingestellt, die Warnung, auf die sich viele verlassen haben, kommt also nicht mehr.

Die Validierung klappt nicht mehr. Die HTTP-01-Challenge braucht ein erreichbares /.well-known/acme-challenge/ auf Port 80, und eine neue Weiterleitungsregel, eine WAF oder eine Firewall-Änderung kann das blockieren. Bei DNS-01 macht ein Umzug des DNS zu einem anderen Anbieter die API-Zugangsdaten unbrauchbar, mit denen die Erneuerung gearbeitet hat.

Das Zertifikat wird erneuert, aber nie geladen. Nginx und Apache liefern so lange das Zertifikat aus, das sie beim Start geladen haben, bis sie neu geladen werden. Certbot löst das mit einem Deploy-Hook wie --deploy-hook "systemctl reload nginx". Wurde dieser Hook nie gesetzt, liegt auf der Platte eine frische Datei, während Besucher das abgelaufene Zertifikat bekommen.

Edge und Origin sind sich nicht einig. Wenn Cloudflare oder ein Load Balancer TLS terminiert, gibt es zwei Zertifikate mit zwei Ablaufdaten. Besucher sehen das Zertifikat am Edge, aber ein abgelaufenes Origin-Zertifikat unterbricht die Verbindung dahinter, wenn der Modus „Full (strict)“ aktiv ist.

Subdomains werden vergessen. Ein Zertifikat für example.com und www.example.com deckt shop.example.com oder staging.example.com nicht ab, und jede dieser Subdomains hat womöglich ihr eigenes Zertifikat und ihren eigenen Erneuerungsjob.

Mit certbot renew --dry-run kannst du den Erneuerungsweg testen, ohne etwas zu ersetzen.

Den SSL-Zertifikat-Ablauf selbst prüfen

Im Browser klickst du auf das Symbol links neben der Adressleiste, öffnest die Zertifikatsdetails und liest das Datum unter „Gültig bis“ ab.

Auf der Kommandozeile:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

Das gibt notBefore, notAfter und den Aussteller aus. Gib immer -servername mit an. Ohne diesen Parameter liefert ein Server, der mehrere Websites auf einer IP hostet, womöglich sein Standardzertifikat statt des Zertifikats für deinen Hostnamen.

Wenn du schon dabei bist, prüf zwei weitere Dinge. Der Aussteller sollte der erwartete sein, denn ein Wechsel bedeutet oft, dass Hosting oder CDN umkonfiguriert wurden. Und die Kette sollte vollständig sein: Ein fehlendes Zwischenzertifikat oder ein Hostname, der nicht in den Subject Alternative Names des Zertifikats steht, erzeugt dieselbe Browserwarnung wie ein Ablauf, auch wenn noch Monate übrig sind.

Pro Website dauert das eine Minute. Bei dreißig Kunden, ihren Subdomains und ein paar Staging-Umgebungen wird daraus eine Aufgabe, die in stressigen Wochen ausfällt. Die Website-Monitoring-Checkliste für Agenturen behandelt die anderen wiederkehrenden Checks, denen es genauso geht.

SSL-Ablauf automatisch prüfen und warnen lassen mit Deltio

Deltio prüft das Zertifikat jeder Website, die du hinzufügst, zeigt die verbleibenden Tage und den Aussteller im Dashboard und warnt dich per Slack und E-Mail vor dem Ablauf und wenn ein Zertifikat ungültig ist. Der Domain-Ablauf wird an derselben Stelle geprüft. Das ist wichtig, weil eine abgelaufene Domain Zertifikat, Website und E-Mail gleichzeitig mitnimmt. Uptime, robots.txt und Sitemap-Änderungen laufen im selben Konto, SSL ist also eine Zeile im Gesamtbild jeder Kundenseite statt eines separaten Tools, so wie in Kundenwebsites auf Änderungen überwachen beschrieben. Ein abgelaufenes Zertifikat ist praktisch Downtime, und deshalb taucht es auch in unserem Vergleich zur UptimeRobot-Alternative auf.