SSL-Zertifikat abgelaufen: Was jetzt zu tun ist

Ein abgelaufenes Zertifikat nimmt eine Website ebenso wirksam vom Netz wie ein abgestürzter Server. Browser zeigen eine ganzseitige Warnung (NET::ERR_CERT_DATE_INVALID in Chrome, SEC_ERROR_EXPIRED_CERTIFICATE in Firefox), und wenn die Website HSTS nutzt, gibt es nicht einmal einen Link „trotzdem fortfahren“. API-Clients, mobile Apps, Webhooks und Zahlungs-Callbacks schlagen schlicht fehl. Dieser Leitfaden beschreibt, was in der ersten halben Stunde zu tun ist und wie Sie dafür sorgen, dass es nicht wieder passiert.

Schritt 1: Feststellen, was wirklich nicht stimmt

Nicht jeder Datumsfehler ist ein abgelaufenes Zertifikat auf Ihrem Server. Prüfen Sie von einem Rechner aus, dessen Uhr Sie vertrauen:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates
subject=CN = example.com
issuer=C = XX, O = Example CA, CN = Example CA R3
notBefore=Jun 20 08:00:00 2026 GMT
notAfter=Sep 18 08:00:00 2026 GMT

Liegt notAfter in der Vergangenheit, ist der Fall klar. Ähnlich aussehende Ursachen, die etwas anderes sind:

Falsche Uhrzeit auf dem Client. Ein Laptop mit leerer Pufferbatterie, der glaubt, es sei 2019, lehnt jedes Zertifikat ab. Meldet nur ein einzelner Besucher den Fehler, fragen Sie zuerst nach der Uhr.
Ein abgelaufenes Zwischenzertifikat in der Kette, die der Server sendet, während das Endzertifikat in Ordnung ist.
Nur einer von mehreren Servern hat das alte Zertifikat. Prüfen Sie hinter einem Load Balancer oder einem CDN jeden Knoten, und prüfen Sie den Ursprungsserver getrennt vom Edge.
Ein anderer Dienst unter demselben Namen. Port 443 wurde erneuert, aber der Mailserver (:465, :993, :587 mit STARTTLS) hat noch die alte Datei:

$ openssl s_client -connect mail.example.com:587 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

Die Option -servername ist wichtig: Ohne SNI liefern viele Server ein Standardzertifikat, das nicht dem entspricht, was Browser sehen.

Schritt 2: Erneuern, je nach Herkunft des Zertifikats

ACME (Let's Encrypt und ähnliche)

Das Zertifikat hätte sich selbst erneuern sollen. Finden Sie heraus, warum es das nicht getan hat.

$ sudo certbot certificates          # was certbot kennt und wann was abläuft
$ sudo certbot renew --dry-run       # den Erneuerungsweg testen
$ sudo certbot renew                 # alles erneuern, was fällig ist
$ systemctl list-timers | grep -i certbot

Die üblichen Ursachen: Nach einem Serverumzug fehlt der Timer oder der Cronjob. Port 80 ist geschlossen oder wird so umgeleitet, dass die HTTP-01-Challenge scheitert. Das DNS-API-Token für DNS-01 wurde ausgetauscht. Ein AAAA-Record zeigt auf eine Maschine, die die Challenge nicht beantwortet. Ein restriktiver CAA-Record führt die CA nicht auf. Oder die Domain zeigt inzwischen auf einen ganz anderen Server.

Zertifikat einer kommerziellen CA

Erzeugen Sie einen neuen Schlüssel und einen CSR. Verwenden Sie den alten Schlüssel nicht aus Gewohnheit weiter.

$ openssl req -new -newkey rsa:2048 -nodes \
    -keyout example.com.key -out example.com.csr \
    -subj "/CN=example.com" \
    -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Reichen Sie den CSR ein, schließen Sie die Domainvalidierung ab (E-Mail, DNS-Eintrag oder HTTP-Datei) und laden Sie das Zertifikat samt Zwischenzertifikatskette herunter.
Führen Sie im SAN-Feld jeden Hostnamen auf, den Sie brauchen. example.com deckt www.example.com nicht ab, und ein Wildcard-Zertifikat für *.example.com deckt weder die nackte Domain noch a.b.example.com ab.

Verwaltet durch Hoster, CDN oder Load Balancer

Sehen Sie in der Verwaltungsoberfläche des Anbieters nach. Verwaltete Zertifikate lassen sich meist aus einem einzigen Grund nicht erneuern: Die Domain lässt sich nicht mehr validieren. Der DNS-Eintrag, der auf den Anbieter zeigte, wurde geändert, ein für die Validierung nötiger CNAME wurde gelöscht, oder ein CAA-Record sperrt die CA des Anbieters aus.

Schritt 3: Mit vollständiger Kette installieren

Server müssen das Endzertifikat senden, gefolgt von dem oder den Zwischenzertifikaten. Das Wurzelzertifikat wird nicht gesendet. Bei certbot ist das die Datei fullchain.pem:

# nginx
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Ein fehlendes Zwischenzertifikat ist tückisch, weil Desktop-Browser den Mangel oft überdecken, indem sie Zwischenzertifikate nachladen oder aus dem Cache nehmen, während curl, Android-Apps und andere Server scheitern. Testen Sie mit einem strengen Client:

$ curl -sSI https://example.com >/dev/null && echo chain ok

Prüfen Sie, ob Zertifikat und Schlüssel zusammengehören:

$ openssl x509 -noout -pubkey -in fullchain.pem | openssl sha256
$ openssl pkey -pubout -in privkey.pem | openssl sha256

Beide Hashwerte müssen identisch sein.

Schritt 4: Den Dienst neu laden

Der häufigste Grund für „Ich habe erneuert, und es ist immer noch abgelaufen“: Der Webserver hält das alte Zertifikat noch im Arbeitsspeicher.

$ sudo nginx -t && sudo systemctl reload nginx
$ sudo apachectl configtest && sudo systemctl reload apache2

Machen Sie bei ACME-Clients das Neuladen zum Bestandteil der Erneuerung, zum Beispiel mit certbot renew --deploy-hook "systemctl reload nginx". Dasselbe gilt für Postfix, Dovecot, HAProxy und alles andere, was die Datei liest.

Schritt 5: Von außen überprüfen

Wiederholen Sie den Befehl openssl s_client aus Schritt 1 und sehen Sie sich das neue notAfter an. Prüfen Sie anschließend:

sowohl example.com als auch www.example.com und alle weiteren verwendeten Namen
IPv4 und IPv6 getrennt (openssl s_client -4 / -6), wenn Sie beides veröffentlichen
jeden Knoten hinter dem Load Balancer
Mail- und andere TLS-Ports

Browser halten eine offene Verbindung unter Umständen eine Weile. Testen Sie in einem frischen privaten Fenster, bevor Sie schließen, es habe nicht funktioniert.

Warum das immer wieder passiert: Die Laufzeiten werden kürzer

Öffentlich vertrauenswürdige Zertifikate sind seit September 2020 auf 398 Tage begrenzt, und Let's Encrypt stellt von Anfang an Zertifikate mit 90 Tagen Laufzeit aus. Im April 2025 hat das CA/Browser Forum einen Zeitplan beschlossen, der die Höchstlaufzeit weiter senkt: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Auch der Zeitraum, in dem eine abgeschlossene Domainvalidierung wiederverwendet werden darf, schrumpft.

Praktisch heißt das: Ein Kalendereintrag und eine manuelle Verlängerung einmal im Jahr sind ein Verfahren mit Ablaufdatum. Bei Zertifikaten mit 47 Tagen Laufzeit erneuert niemand mehr von Hand. Beachten Sie außerdem, dass Let's Encrypt 2025 den Versand von Ablaufwarnungen per E-Mail eingestellt hat. Dieses Sicherheitsnetz gibt es also auch nicht mehr.

Checkliste zur Vorbeugung

Ausstellung und Erneuerung automatisieren, und zwar mit ACME, wo immer die Plattform es zulässt. Auch viele kommerzielle CAs unterstützen ACME.
Früh erneuern. ACME-Clients erneuern standardmäßig, wenn noch etwa ein Drittel der Laufzeit übrig ist. So bleiben Wochen, um einen Fehlschlag zu bemerken.
Von außen überwachen, unabhängig vom Erneuerungsmechanismus. Die Prüfung muss das Zertifikat betrachten, das der Server ausliefert, nicht die Datei auf der Festplatte. Alarmieren Sie bei 21, 14 und 7 Tagen.
Jeden Endpunkt erfassen: Subdomains, Mailserver, VPN-Gateways, interne Tools, den Ursprungsserver hinter dem CDN. Das vergessene Zertifikat ist das, das abläuft.
Den Deploy-Hook testen. Eine Erneuerung ohne Neuladen ist ein Ausfall, der nur aufgeschoben ist.
Die Validierung funktionsfähig halten: Port 80 für HTTP-01 erreichbar, DNS-API-Zugangsdaten für DNS-01 gültig, CAA-Records mit den CAs, die Sie verwenden.
Alarme an eine Teamadresse senden, nicht an das Postfach einer einzelnen Person.

Häufige Fehler

Das Zertifikat erneuern und den Server nicht neu laden.
Das Endzertifikat ohne Zwischenzertifikat installieren.
www oder die nackte Domain in der SAN-Liste vergessen.
Das Zertifikat am Edge (CDN) erneuern, während das Zertifikat des Ursprungsservers unbemerkt abläuft. Je nach Modus des CDN führt das zu 5xx-Fehlern vom Edge statt zu einer Browserwarnung.
Nutzern raten, sich durch die Warnung zu klicken. Das trainiert genau die Gewohnheit, auf die Angreifer setzen.
Die Zertifikatsprüfung in einem API-Client „vorübergehend“ abschalten.
Ein Zertifikatsproblem vermuten, wenn die eigentliche Ursache eine DNS-Änderung ist, die die Nutzer zu einem anderen Server geschickt hat. Gehört das ausgelieferte Zertifikat jemand anderem, prüfen Sie zuerst, wohin der Name zeigt.

Mit OrbitProbe prüfen

Der SSL-Check von OrbitProbe verbindet sich mit Ihrem Hostnamen und berichtet über das SSL/TLS-Zertifikat, das tatsächlich ausgeliefert wird: Aussteller, Gültigkeitsdaten und verbleibende Tage, die abgedeckten Hostnamen, das ausgehandelte TLS-Protokoll, ob der Kette vertraut wird, und HSTS. Führen Sie ihn nach jeder Erneuerung aus, einmal für die nackte Domain und einmal für www. Ist bei demselben Vorfall auch die E-Mail betroffen, deckt die DNS-Checkliste für E-Mails im Spam die TLS- und DNS-Seite der Zustellung ab.