SSL-Zertifikat abgelaufen: Was jetzt zu tun ist

Was Besucher gerade sehen

Chrome und Edge zeigen NET::ERR_CERT_DATE_INVALID, Firefox meldet SEC_ERROR_EXPIRED_CERTIFICATE, Safari sagt schlicht, die Verbindung sei nicht privat. Alle drei blenden eine Warnseite ein, die die meisten Besucher nicht überspringen. Für eine Landingpage ist das ärgerlich, für einen Shop bedeutet es null Umsatz, bis das Zertifikat erneuert ist.

Schlimmer ist, was du nicht siehst: Mobile Apps, Zahlungsanbieter, Webhooks und Cronjobs anderer Systeme prüfen Zertifikate strikt und brechen ohne Warnseite ab. Ein abgelaufenes Zertifikat auf einer API kann Bestellungen, Synchronisationen und Logins stoppen, ohne dass irgendjemand eine Fehlermeldung im Browser sieht.

Sofortmaßnahmen

Bevor du etwas erneuerst, klär, welcher Host das TLS tatsächlich terminiert. Bei einem CDN wie Cloudflare, einem Load Balancer oder einem Reverse Proxy vor dem Webserver ist das Zertifikat auf dem Ursprungsserver oft gar nicht das, was der Browser sieht. Erneuerst du am falschen Ort, ändert sich nichts.

1. Mit dem SSL Checker oder openssl prüfen, welches Zertifikat der Browser bekommt und wo es herkommt (Aussteller, Ablaufdatum, Hostnamen im SAN).
2. Den terminierenden Host identifizieren: Proxy, Load Balancer, CDN oder direkt der Webserver.
3. Dort erneuern: bei Let's Encrypt mit certbot renew, bei Plesk, cPanel oder dem Hosting-Panel über die Zertifikatsverwaltung, bei gekauften Zertifikaten über den Anbieter.
4. Den Dienst neu laden, damit er das neue Zertifikat auch liest, zum Beispiel nginx -s reload oder systemctl reload apache2.
5. Von außen erneut prüfen, nicht nur lokal. Erst wenn der Check das neue Ablaufdatum zeigt, ist das Problem gelöst.

openssl s_client -connect www.beispiel.de:443 -servername www.beispiel.de </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject

Warum die automatische Verlängerung versagt hat

Fast jedes abgelaufene Let's-Encrypt-Zertifikat hatte eine funktionierende Automatik, die irgendwann still stehen geblieben ist. Die Ursachen wiederholen sich, deshalb lohnt sich die Suche, sonst stehst du in 90 Tagen wieder hier.

• HTTP-01-Challenge kaputt: Die Domain zeigt inzwischen auf einen anderen Server oder ein Redirect fängt /.well-known/acme-challenge/ ab.
• DNS-01-Challenge kaputt: Nach einem DNS-Umzug hat der ACME-Client keine Rechte mehr, TXT-Records in der neuen Zone anzulegen.
• Port 80 blockiert: Eine neue Firewall-Regel oder ein Provider-Wechsel lässt nur noch 443 durch, HTTP-01 braucht aber 80.
• Cron oder Systemd-Timer läuft nicht: Nach einem Server-Umzug wurde der Timer nie eingerichtet, oder der Job läuft als Nutzer ohne Schreibrechte.
• Rate Limits: Zu viele fehlgeschlagene Versuche oder zu viele Zertifikate für dieselbe Domain in kurzer Zeit.
• CAA-Record: Ein CAA-Eintrag erlaubt nur eine bestimmte CA, und Let's Encrypt steht nicht drin.
• ACME-Account oder Client veraltet: Alte certbot-Versionen und abgekündigte API-Endpunkte funktionieren irgendwann nicht mehr.

Der Log des ACME-Clients nennt die Ursache fast immer im Klartext. Bei certbot findest du ihn unter /var/log/letsencrypt/, ein Trockenlauf mit certbot renew --dry-run zeigt sofort, ob die Challenge wieder funktioniert.

Kette und Zwischenzertifikate prüfen

Nicht immer ist das Endzertifikat abgelaufen. Manchmal ist es das Zwischenzertifikat (Intermediate) in der Kette, die der Server ausliefert. Browser mit aktuellem Zertifikatsspeicher bauen sich oft eine gültige Kette selbst, ältere Android-Versionen, Java-Clients und curl auf alten Systemen tun das nicht. Das Ergebnis: Auf deinem Laptop funktioniert alles, beim Kunden nicht.

Prüfe deshalb immer die vollständige Kette, nicht nur das erste Zertifikat. Bei Let's Encrypt gehört fullchain.pem in die Serverkonfiguration, nicht cert.pem. Der SSL Checker zeigt jede Stufe der Kette mit ihrem eigenen Ablaufdatum.

openssl s_client -connect www.beispiel.de:443 -servername www.beispiel.de -showcerts </dev/null 2>/dev/null | grep -E "s:|i:|Verify return code"

Laufzeiten werden kürzer, Automatisierung wird Pflicht

Let's Encrypt stellt seit jeher Zertifikate mit 90 Tagen Laufzeit aus und bietet inzwischen auch deutlich kürzere an. Das CA/Browser Forum hat beschlossen, die maximale Laufzeit öffentlicher Zertifikate schrittweise zu senken: bis 2029 auf 47 Tage. Das gilt für alle öffentlichen CAs, auch für gekaufte Zertifikate.

Damit ist das manuelle Erneuern endgültig vorbei. Ein Zertifikat, das jemand jedes Jahr per Hand in ein Panel lädt, wird in wenigen Jahren alle sechs Wochen fällig. Wer heute noch manuell erneuert, sollte den Wechsel auf ACME jetzt einplanen, solange kein Ablauf drängt.

Vorbeugen: Monitoring mit Schwellwerten

Automatisierung allein reicht nicht, denn die Automatik kann still versagen. Was hilft, ist eine unabhängige Prüfung von außen, die das tatsächlich ausgelieferte Zertifikat liest und rechtzeitig meldet. Bewährt haben sich gestaffelte Schwellwerte: 30 Tage als frühe Information, 14 Tage als Hinweis, dass die Automatik offenbar nicht greift, 7 Tage als Alarm.

Bei Let's Encrypt läuft die Erneuerung normalerweise 30 Tage vor Ablauf. Ein Zertifikat, das bei 14 Tagen Restlaufzeit noch nicht erneuert ist, hat also mit hoher Wahrscheinlichkeit ein Problem, und du hast zwei Wochen Zeit, es in Ruhe zu beheben, statt am Wochenende vom Kunden angerufen zu werden.

Häufige Fragen

Das Zertifikat ist erneuert, der Browser zeigt trotzdem noch die Warnung. Warum?

Meist wurde der Dienst nicht neu geladen und liefert noch das alte Zertifikat aus dem Speicher. Prüfe mit openssl von außen, was tatsächlich ausgeliefert wird. Falls das neue Zertifikat sichtbar ist, liegt es am Browser-Cache oder an einem CDN, das das alte Zertifikat noch vorhält.

Kann ich das Zertifikat vorab erneuern, ohne dass etwas ausfällt?

Ja. Das neue Zertifikat wird parallel ausgestellt und beim Reload aktiviert, Besucher merken nichts. Es gibt keinen Grund, bis zum letzten Tag zu warten.

Hilft ein Zertifikat mit längerer Laufzeit?

Nur kurzfristig. Die maximale Laufzeit sinkt für alle öffentlichen CAs, und ein Jahreszertifikat verschiebt das Problem nur auf ein Datum, an das sich niemand mehr erinnert. Kurze Laufzeiten mit funktionierender Automatik sind zuverlässiger.