SSL-Zertifikat überwachen: So läuft dein Zertifikat nie wieder unbemerkt ab

Ein abgelaufenes SSL-Zertifikat gehört zu den ärgerlichsten Ausfällen überhaupt. Der Server läuft, die Anwendung ist gesund, und trotzdem sieht jeder Besucher eine ganzseitige Sicherheitswarnung statt deiner Website. Shop, Kundenportal und API sind damit praktisch nicht erreichbar. Besonders ärgerlich: Das Ablaufdatum stand vom ersten Tag an im Zertifikat. Wenn du dein SSL-Zertifikat überwachen lässt, siehst du das Problem Wochen im Voraus kommen.

In diesem Artikel erklären wir, warum Zertifikate trotz automatischer Verlängerung ablaufen, wie du das Ablaufdatum selbst prüfst, warum das Thema durch kürzere Laufzeiten gerade wichtiger wird und worauf es bei einer verlässlichen Überwachung ankommt.

Was passiert, wenn ein SSL-Zertifikat abläuft

Streng genommen sprechen wir heute von TLS-Zertifikaten, denn das alte SSL-Protokoll ist seit vielen Jahren abgelöst. Im Alltag hat sich der Begriff SSL-Zertifikat aber gehalten, deshalb verwenden wir ihn auch hier.

Ist das Zertifikat abgelaufen, bauen Browser keine normale Verbindung mehr auf. Chrome zeigt zum Beispiel den Fehler NET::ERR_CERT_DATE_INVALID, Firefox SEC_ERROR_EXPIRED_CERTIFICATE. Zwar lässt sich die Warnung in vielen Fällen übergehen, aber bei einem Shop oder einem Login-Formular tut das kaum jemand, und das zu Recht. Ist für deine Domain HSTS aktiv, bieten Browser diese Möglichkeit gar nicht erst an.

Noch härter trifft es Maschinen: API-Clients, Webhooks, mobile Apps, Zahlungs- und Versanddienstleister. Die meisten HTTP-Bibliotheken brechen die Verbindung bei einem ungültigen Zertifikat sofort mit einem Fehler ab. Eine Integration, die gestern noch lief, scheitert heute, und die Fehlermeldung landet in einem Log, das niemand liest.

Warum Zertifikate trotz Automatisierung ablaufen

Seit Let's Encrypt ist die automatische Verlängerung der Normalfall. Certbot, Caddy, Traefik, Laravel Forge und viele Hosting-Oberflächen erneuern Zertifikate selbstständig. Trotzdem laufen Zertifikate ab, denn die Automatisierung kann an mehreren Stellen still scheitern:

• Die Domain-Validierung schlägt fehl. Bei der HTTP-01-Challenge muss die Zertifizierungsstelle eine Datei unter /.well-known/acme-challenge/ abrufen. Eine neue Firewall-Regel, Geoblocking, ein vorgeschalteter Proxy oder ein Wartungsmodus, der jede Anfrage mit einer Fehlerseite beantwortet, kann das verhindern. Bei der DNS-01-Challenge reicht ein abgelaufener API-Token beim DNS-Anbieter.
• Die Domain zeigt woanders hin. Nach einem Server-Umzug versucht der alte Server weiterhin, sein Zertifikat zu verlängern, während die Domain längst auf den neuen zeigt. Auf dem neuen Server wurde die Verlängerung dagegen nie eingerichtet.
• Der Verlängerungsjob läuft nicht. Der systemd-Timer oder Cronjob von Certbot fehlt nach einer Neuinstallation, ein Container wird ohne den Erneuerungsprozess neu gebaut, oder ein Deployment überschreibt die Crontab.
• Das neue Zertifikat wird nicht ausgeliefert. Webserver wie Nginx und Apache lesen Zertifikate beim Start oder beim Neuladen der Konfiguration. Wird das Zertifikat auf der Festplatte erneuert, der Webserver aber nicht neu geladen, liefert er weiter das alte aus, bis es abläuft. Dasselbe gilt für Load Balancer oder CDNs, auf die ein Zertifikat manuell hochgeladen wurde.
• Ein CAA-Eintrag blockiert die Ausstellung. Erlaubt ein CAA-Eintrag im DNS nur eine bestimmte Zertifizierungsstelle, scheitert jede Ausstellung durch eine andere. Das passiert gern, wenn ein Kunde oder eine frühere Agentur den Eintrag gesetzt hat.
• Manuell gekaufte Zertifikate. Bei Zertifikaten, die einmal im Jahr gekauft und eingespielt werden, hängt alles an einer Person und einem Kalendereintrag. Verlässt diese Person das Unternehmen, verlässt auch das Wissen das Haus.
• Erinnerungsmails kommen nicht mehr an. Let's Encrypt hat den Versand von Ablauf-Erinnerungen per E-Mail am 4. Juni 2025 eingestellt. Wer sich auf diese Mails als Sicherheitsnetz verlassen hat, hat es nicht mehr. Bei gekauften Zertifikaten gehen Erinnerungen oft an eine Adresse, die niemand mehr liest.

Allen Fällen ist gemeinsam: Auf dem Server sieht alles normal aus, bis zu dem Moment, in dem das Zertifikat abläuft.

Kürzere Laufzeiten machen Überwachung wichtiger

Im April 2025 hat das CA/Browser Forum, in dem Zertifizierungsstellen und Browserhersteller die Regeln für öffentlich vertrauenswürdige TLS-Zertifikate festlegen, mit Ballot SC-081 einen Fahrplan für deutlich kürzere Laufzeiten beschlossen. Bis März 2026 durften Zertifikate bis zu 398 Tage gültig sein. Der Fahrplan sieht so aus:

Parallel dazu sinkt der Zeitraum, für den eine Domain-Validierung wiederverwendet werden darf, bis 2029 auf 10 Tage. Für dich bedeutet das: Ein jährlicher manueller Zertifikatstausch ist schon heute nicht mehr möglich, und bald wird auch ein halbjährlicher Rhythmus nicht mehr reichen. Ohne Automatisierung geht es nicht. Und jede zusätzliche Verlängerung ist eine weitere Gelegenheit, bei der etwas schiefgehen kann. Je häufiger verlängert wird, desto wichtiger ist eine unabhängige Kontrolle, die prüft, ob das Ergebnis auch wirklich beim Besucher ankommt.

Ablaufdatum prüfen: So geht es von Hand

Im Browser kannst du dir über das Symbol links neben der Adresse die Details des Zertifikats anzeigen lassen, darunter Aussteller und Gültigkeitszeitraum. Für mehrere Domains oder für Skripte ist die Kommandozeile praktischer:

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

Die Ausgabe sieht etwa so aus:

subject=CN=example.com
issuer=C=US, O=Let's Encrypt, CN=R11
notAfter=Dec  3 14:34:31 2026 GMT

Wichtig ist der Parameter -servername. Er setzt die Server Name Indication (SNI). Ohne ihn liefert ein Server, auf dem mehrere Websites laufen, unter Umständen ein Standardzertifikat aus, und du prüfst das falsche.

Für Skripte eignet sich -checkend. Die Option erwartet Sekunden und endet mit Exit-Code 1, wenn das Zertifikat innerhalb dieser Zeit abläuft. 1209600 Sekunden entsprechen 14 Tagen:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend 1209600

Mit openssl x509 -noout -ext subjectAltName siehst du außerdem, für welche Hostnamen das Zertifikat gilt. Das hilft, wenn nach einer Umstellung plötzlich www oder eine Subdomain fehlt.

Nutzt du Certbot, helfen dir drei Befehle auf dem Server:

sudo certbot certificates         # alle Zertifikate mit Ablaufdatum
sudo certbot renew --dry-run      # Verlängerung testen, ohne echte Zertifikate auszustellen
systemctl list-timers | grep certbot

Damit der Webserver ein erneuertes Zertifikat auch lädt, gehört ein Deploy-Hook dazu, zum Beispiel ein ausführbares Skript in /etc/letsencrypt/renewal-hooks/deploy/ mit dem Befehl systemctl reload nginx. Certbot führt Deploy-Hooks nur nach einer erfolgreichen Verlängerung aus.

Eines ersetzt der Blick auf den Server allerdings nicht: die Prüfung von außen. Entscheidend ist, welches Zertifikat bei deinen Besuchern ankommt, nicht welche Datei auf der Festplatte liegt.

Worauf es bei der SSL-Überwachung ankommt

Ein einmaliger Check hilft dir heute, aber nicht in drei Monaten. Eine verlässliche Überwachung erfüllt aus unserer Sicht diese Punkte:

• Das ausgelieferte Zertifikat wird von außen geprüft. So fällt auch auf, wenn das Zertifikat zwar erneuert, aber nie geladen wurde.
• Die Warnungen kommen rechtzeitig und in Stufen. Eine erste Warnung mit mehreren Wochen Vorlauf lässt dir Zeit für Validierungsprobleme oder eine Freigabe beim Kunden. Weitere Warnungen kurz vor dem Ablauf sorgen dafür, dass das Thema nicht untergeht. Viele ACME-Clients verlängern Let's-Encrypt-Zertifikate etwa 30 Tage vor Ablauf. Bekommst du für ein solches Zertifikat eine Warnung bei 14 Tagen, ist die automatische Verlängerung also offensichtlich mehrfach gescheitert.
• Auch ungültige Zertifikate fallen auf. Ein falscher Hostname, ein selbstsigniertes Zertifikat oder eine fehlende Zwischenzertifikatskette führen ebenfalls zu Fehlern. Gerade die fehlende Kette ist tückisch: Manche Browser gleichen sie aus, viele API-Clients und curl dagegen nicht.
• Der Alarm erreicht die richtige Person. Eine Warnung, die in einem Sammelpostfach verschwindet, ist keine Warnung. Schicke sie dorthin, wo das zuständige Team ohnehin arbeitet, und zwar ohne ständige Wiederholungen, die irgendwann ignoriert werden.
• Alle Hostnamen sind abgedeckt. Neben der Hauptdomain gehören www, API, Kundenportal, Staging-Umgebungen und ältere Landingpages dazu. Jeder Hostname kann ein eigenes Zertifikat haben.

Checkliste für Agenturen und kleine Teams

Wer viele Kunden-Websites betreut, hat schnell Dutzende Zertifikate im Einsatz. Diese Punkte haben sich bewährt:

1. Führe eine Liste aller Hostnamen pro Kunde, inklusive Subdomains. Nur was auf der Liste steht, wird auch überwacht.
2. Kläre die Zuständigkeit. Liegt das DNS beim Kunden, kann eine Änderung dort die Verlängerung brechen, ohne dass du davon erfährst. Halte fest, wer im Ernstfall Einträge ändern darf.
3. Teste nach jedem Umzug mit certbot renew --dry-run oder dem Gegenstück deines ACME-Clients, ob die Verlängerung auf dem neuen Server funktioniert.
4. Sorge für das Neuladen. Prüfe, ob nach einer Verlängerung der Webserver, Load Balancer oder Proxy das neue Zertifikat übernimmt.
5. Überwache den Verlängerungsjob selbst. Wenn du die Erneuerung über einen eigenen Cronjob steuerst, kannst du ihn mit einem Heartbeat absichern. Wie das funktioniert, zeigen wir in unserem Artikel Cronjobs überwachen mit Heartbeats.
6. Vergiss andere Dienste nicht. Auch Mailserver nutzen Zertifikate, etwa für IMAP auf Port 993. Die prüfst du mit openssl s_client -connect mail.example.com:993, für SMTP mit STARTTLS zusätzlich mit -starttls smtp.

So hilft dir Kaspar

In Kaspar aktivierst du für jeden Uptime-Monitor mit einer HTTPS-Adresse die Warnung vor dem Ablauf des SSL-Zertifikats. Einmal täglich lesen wir das Zertifikat aus, das dein Server tatsächlich ausliefert, und warnen dich 30, 14, 7 und 1 Tag vor dem Ablauf per E-Mail, Slack oder Telegram. Jede Stufe meldet sich genau einmal, und sobald das Zertifikat verlängert ist, schließt Kaspar die offene Warnung automatisch.

Unabhängig davon prüft der Uptime-Monitor deine Website in dem Intervall, das dein Tarif vorsieht. Ist das Zertifikat abgelaufen oder ungültig, schlägt die Prüfung mit einem TLS/SSL-Fehler fehl. Wie bei jedem anderen Fehler prüfen wir innerhalb von Sekunden gegen, bevor wir dich alarmieren. Die SSL-Ablaufprüfung ist in beiden Tarifen enthalten, Heartbeats für deine Verlängerungsjobs gibt es im Pro-Tarif. Alle Funktionen findest du auf unserer Startseite, die Tarife auf der Preisseite.

Fazit

Abgelaufene Zertifikate sind kein Schicksal, sondern ein Planungsproblem. Automatisiere die Verlängerung, sorge dafür, dass der Webserver das neue Zertifikat lädt, und lass das ausgelieferte Zertifikat von außen überwachen. Mit den kürzeren Laufzeiten der kommenden Jahre wird diese Kontrolle vom Nice-to-have zur Pflicht. Wenn du gleichzeitig auch die Erreichbarkeit deiner Website und defekte Links im Blick behalten willst, geht das in Kaspar in einem Konto.