SSL-Zertifikate rechtzeitig prüfen und überwachen

Was passiert, wenn ein Zertifikat abläuft?

Ein TLS-Zertifikat bestätigt, dass ein öffentlicher Schlüssel zu einem Domainnamen gehört, und ist von einer Zertifizierungsstelle (Certificate Authority, CA) signiert. Das Format ist im Standard X.509 beschrieben (siehe RFC 5280 in den Quellen); Begriffe wie SNI oder Intermediate erklärt das Glossar. Jedes Zertifikat hat ein Gültigkeitsende. Danach lehnen Browser, Apps und Programmierschnittstellen die Verbindung ab: Besucher sehen eine ganzseitige Warnung wie „Ihre Verbindung ist nicht privat“ (Fehlercodes wie NET::ERR_CERT_DATE_INVALID), Skripte brechen mit Fehlern wie „certificate has expired“ ab, und Zahlungs- oder API-Schnittstellen, die Ihr Zertifikat prüfen, verweigern die Zusammenarbeit.

Der entscheidende Punkt: Der Server läuft weiter. Ein einfacher Test, der nur prüft, ob Port 443 antwortet, bleibt grün. Ein HTTP-Monitor, der Zertifikate strikt prüft, schlägt dagegen fehl. Das Thema ist deshalb ein Standardfall dafür, warum Monitoring mehr als einen Ping braucht (siehe Ausfallursachen von Websites).

Wie lange sind Zertifikate gültig – und warum werden die Laufzeiten kürzer?

Die Gültigkeitsdauer hängt von der Zertifizierungsstelle und den Branchenregeln ab. Let’s Encrypt stellt Zertifikate mit 90 Tagen Laufzeit aus und empfiehlt, sie automatisch etwa 30 Tage vor Ablauf zu erneuern. Bei kommerziellen Zertifikaten war die Höchstdauer lange etwa ein Jahr. Nach unserem Kenntnisstand hat das CA/Browser Forum eine stufenweise Verkürzung beschlossen, die 2026 bei einer Höchstdauer von 200 Tagen beginnt und bis 2029 weiter sinken soll. Prüfen Sie die aktuellen Regeln bei Ihrer CA, da sie sich ändern können.

Praktisch heißt das: Manuelle Jahresverlängerungen werden unrealistisch. Wer heute noch Zertifikate von Hand einspielt, sollte auf Automatisierung wechseln und deren Ergebnis überwachen. Das Ausstellungsprotokoll ACME ist in RFC 8555 beschrieben; Clients wie Certbot oder acme.sh setzen es um.

Warum scheitert die automatische Erneuerung?

Die Erfahrung zeigt: Die meisten Ablauf-Ausfälle entstehen nicht, weil niemand an Zertifikate gedacht hat, sondern weil die Automatik leise ausgefallen ist. Die häufigsten Ursachen:

Ein zusätzlicher Stolperstein: Früher schickte Let’s Encrypt Erinnerungs-E-Mails bei bevorstehendem Ablauf. Soweit uns bekannt, wurde das 2025 eingestellt; verlassen Sie sich daher nicht auf Hinweise der CA, sondern auf eigene Überwachung.

Was gehört zu einer vollständigen Zertifikatsprüfung?

Das Ablaufdatum ist nur eine von mehreren Eigenschaften. Eine gründliche Prüfung umfasst:

• Restlaufzeit: Wie viele Tage bleiben bis zum Ende der Gültigkeit?
• Hostname: Steht der Domainname (und www) im Feld „Subject Alternative Name“? Ein Wildcard-Zertifikat *.example.com deckt example.com selbst nicht ab.
• Zertifikatskette: Sind die Zwischenzertifikate (Intermediates) mitgeliefert? Fehlt eines, funktioniert die Seite im Desktop-Browser oft noch (er lädt es nach), in Apps und Skripten nicht.
• Vertrauenswürdigkeit: Ist die ausstellende CA im System bekannt? Selbstsignierte Zertifikate zeigen immer Warnungen.
• Protokollversion: Werden veraltete Protokolle abgeschaltet und TLS 1.2 oder 1.3 verwendet?

Mit openssl lassen sich die wichtigsten Angaben direkt abfragen:

# Ablaufdatum und Aussteller anzeigen
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# Restlaufzeit prüfen: Exit-Code 0, wenn noch mindestens 14 Tage gültig
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend $((14*24*3600))

# Bei Certbot: Laufzeiten aller verwalteten Zertifikate und Trockenlauf der Erneuerung
sudo certbot certificates
sudo certbot renew --dry-run

Wichtig ist der Parameter -servername: Hinter einer IP-Adresse können mehrere Domains liegen, und der Server wählt das Zertifikat nach diesem Namen (SNI). Ohne Angabe sehen Sie womöglich das Standardzertifikat des Servers statt das der gewünschten Domain.

Wie viel Vorlauf brauchen Sie? Ein Rechenbeispiel

Welche Fehlerbilder gibt es, und was bedeuten sie?

Besonders heikel wird ein Zertifikatsfehler in Kombination mit HSTS (HTTP Strict Transport Security, RFC 6797): Hat der Browser die Regel gespeichert, bietet er bei einem Zertifikatsfehler keine „Trotzdem fortfahren“-Option mehr an. Das ist gewollt und schützt Besucher, verschärft aber den Schaden eines Ablaufs. Mehr zu den Headern finden Sie in Security-Header prüfen.

Welche Fehler passieren in der Praxis besonders häufig?

Wie gehen Sie bei mehreren Domains und Subdomains vor?

In der Praxis betreuen Sie selten nur ein Zertifikat. Eine sinnvolle Vorgehensweise: Erfassen Sie in einer Liste jeden öffentlich erreichbaren Hostnamen mit Zertifikatstyp, Aussteller und Erneuerungsweg. Wildcard-Zertifikate decken viele Subdomains mit einem einzigen Ablaufdatum ab, das macht die Überwachung einfacher, bedeutet aber auch, dass ein Fehler gleich alle Subdomains trifft. Einzelzertifikate begrenzen den Schaden, verlangen aber mehr Verwaltung. Bei Multi-Domain-Zertifikaten (viele Namen in einem Zertifikat) genügt ein Monitor je Zertifikat, sofern Sie zusätzlich prüfen, dass der jeweilige Hostname noch im Zertifikat steht.

Vergessen Sie nicht die Dienste jenseits der Website: Mailserver (SMTPS, IMAPS), VPN-Gateways, Admin-Oberflächen und APIs nutzen oft eigene Zertifikate, die im Alltag niemand sieht. Eine Ablaufwarnung für diese Endpunkte ist häufig der einzige Weg, sie rechtzeitig zu bemerken.

Checkliste: Zertifikate im Griff behalten

1. Alle öffentlich erreichbaren Hostnamen auflisten (Hauptdomain, www, Subdomains, API, Mail).
2. Für jeden Namen die Zuständigkeit und die Erneuerungsart festhalten (ACME, Hoster, manuell).
3. Je Hostname einen SSL-Monitor mit Alarmkanal einrichten.
4. Bei ACME: Timer oder Cronjob per Heartbeat überwachen und einen Deploy-Hook zum Neuladen des Servers setzen.
5. Einmal pro Quartal certbot renew --dry-run (oder das Pendant Ihres Clients) laufen lassen.
6. Vor Umzügen und DNS-Änderungen das Zertifikat auf dem Ziel prüfen.
7. CAA-Einträge dokumentieren und bei CA-Wechsel anpassen.
8. Auch die Kette und die Hostnamen prüfen, nicht nur das Datum.

Grenzen und Einordnung

Eine Zertifikatsüberwachung sieht, was das Zertifikat am geprüften Endpunkt zeigt. Sie sieht nicht, ob an einem anderen Ort, etwa hinter einem Load Balancer mit mehreren Backends, ein Zertifikat abweicht. Auch interne Dienste ohne Zugang aus dem Internet lassen sich von außen nicht prüfen. Und eine bestandene Prüfung heißt nicht, dass die TLS-Konfiguration insgesamt optimal ist: Cipher-Auswahl, Protokollversionen oder Zertifikatstransparenz bewertet ein einfacher Ablaufmonitor nicht.

Außerdem gilt: Ein Monitor warnt, er erneuert nicht. Die Behebung bleibt Ihre Aufgabe oder die Ihres Hosters. Er verkürzt nur die Zeit zwischen „es wird eng“ und „wir handeln“. Wie die Messung grundsätzlich funktioniert und wo ihre Grenzen liegen, erklärt Grenzen automatischer Website-Prüfungen.

Wie setzen Sie das mit UPTIMESHIELD um?

Der SSL-Zertifikat-Monitor prüft strikt Kette und Hostname und zeigt die Restlaufzeit in Tagen. Die Warnungen gehen 30, 14, 7, 3 und 1 Tag vor Ablauf an Ihre Benachrichtigungskanäle; solange das Zertifikat bald abläuft, steht der Status auf „Beeinträchtigt“. Ein ungültiges, abgelaufenes oder zum Namen unpassendes Zertifikat zählt als Fehlschlag. Die Details zu dieser Prüfart finden Sie auf der Seite SSL-Überwachung und im Überblick der Monitortypen.

Empfohlenes Vorgehen: Legen Sie ein kostenloses Solo-Konto an, erstellen Sie für jeden öffentlichen Hostnamen einen SSL-Monitor und verbinden Sie mindestens zwei Benachrichtigungskanäle (bei E-Mail mit bestätigter Adresse). Den Erneuerungs-Cronjob überwachen Sie zusätzlich mit einem Heartbeat-Monitor, siehe Cronjobs mit Heartbeat überwachen. Eine erste Einschätzung ohne Konto liefert die Sofortprüfung im Uptime Checker, die auch die Restlaufzeit anzeigt.