So verhindern Sie das Ablaufen von SSL-Zertifikaten

Jedes SSL/TLS-Zertifikat hat ein Enddatum. Ist es überschritten, vertrauen Browser der Website nicht mehr und zeigen Besuchern eine Warnseite. Die Website selbst läuft weiter, daher bemerken Verfügbarkeitsprüfungen, die nur einen Statuscode abfragen, es unter Umständen gar nicht. Das Ablaufen eines Zertifikats gehört zu den am leichtesten vermeidbaren Ausfallursachen, und diese Anleitung zeigt, wie Sie es verhindern.

Was ein SSL/TLS-Zertifikat leistet

Ein Zertifikat erfüllt zwei Aufgaben, wenn ein Browser eine https://-Adresse öffnet:

• Es weist die Identität nach. Es besagt, dass dieser Server berechtigt ist, für diesen Domainnamen zu antworten, und eine Zertifizierungsstelle, der der Browser vertraut, bürgt dafür.
• Es ermöglicht die Verschlüsselung. Es enthält den öffentlichen Schlüssel, den Browser und Server nutzen, um eine verschlüsselte Verbindung aufzubauen.

Der Begriff SSL ist veraltet. Moderne Verbindungen nutzen TLS, doch man spricht weiterhin vom „SSL-Zertifikat“, und diese Anleitung tut das auch.

Ein Zertifikat enthält ein Startdatum (notBefore) und ein Enddatum (notAfter). Außerhalb dieses Zeitfensters ist es nicht gültig. Das ist im X.509-Standard definiert, RFC 5280.

Warum der Ablauf wichtig ist

Läuft ein Zertifikat ab:

• zeigen Browser eine Warnung über die ganze Seite und machen das Weitergehen schwer.
• können Suchmaschinen-Crawler, Zahlungsanbieter und API-Clients die Verbindung verweigern.
• können mobile Apps und Integrationen, die mit Ihrem Server sprechen, ohne sichtbare Meldung ausfallen.
• halten Besucher die Website oft für gehackt.

Am Server ist nichts defekt. Deshalb übersieht man das Problem leicht, und es richtet schnell echten Schaden an.

So prüfen Sie den Gültigkeitszeitraum eines Zertifikats

Jede öffentliche Website können Sie selbst prüfen, ohne Spezialwerkzeuge.

Im Browser

Die genauen Menübezeichnungen unterscheiden sich je nach Browser und Version. In den meisten Desktop-Browsern:

1. Öffnen Sie die Website.
2. Klicken Sie auf das Symbol links neben der Adressleiste (ein Schloss oder ein Verbindungssymbol).
3. Wählen Sie den Eintrag zur Verbindung oder zum Zertifikat und öffnen Sie die Zertifikatsdetails.
4. Lesen Sie die Daten „Gültig ab“ und „Gültig bis“ ab.

Mit OpenSSL

Unter Linux und macOS ist OpenSSL meist installiert. Dieser Befehl verbindet sich mit der Website und gibt die Daten aus:

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

Ersetzen Sie example.com durch Ihre Domain. Das Ergebnis sieht so aus (die Daten hier sind Beispiele):

notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

Was die einzelnen Teile tun:

• openssl s_client -connect example.com:443 öffnet eine TLS-Verbindung zu Port 443 und gibt aus, was der Server sendet.
• -servername example.com sendet den Hostnamen während des Handshakes (SNI, Server Name Indication). Viele Server betreiben mehrere Websites unter einer Adresse und wählen anhand des Namens, welches Zertifikat sie vorlegen. Ohne ihn bekommen Sie womöglich das Zertifikat einer anderen Website zu sehen.
• </dev/null schließt die Eingabe sofort, damit der Befehl endet, statt zu warten.
• 2>/dev/null blendet die Verbindungsdetails aus, die in den Fehlerstrom gehen.
• openssl x509 -noout -dates liest das Zertifikat aus der Pipe und gibt nur Start- und Enddatum aus.

Für eine Ja-Nein-Frage verwenden Sie stattdessen -checkend mit einer Anzahl von Sekunden. Diese fragt, ob das Zertifikat in 30 Tagen (2.592.000 Sekunden) noch gültig sein wird:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null |
openssl x509 -noout -checkend 2592000

Sie gibt Certificate will not expire aus und endet mit 0, wenn das Zertifikat dann noch gültig ist. Ist es bis dahin abgelaufen, endet sie mit einem Wert ungleich null. So lässt sie sich leicht in einem Skript verwenden.

So funktioniert die Zertifikatsverlängerung

Ein Zertifikat lässt sich nicht verlängern. Eine Verlängerung bedeutet, bei der Zertifizierungsstelle ein neues Zertifikat für dieselben Namen mit neuen Daten zu beziehen und es dort zu installieren, wo der Server es nutzen kann.

Zwei Schritte zählen, und oft erinnert man sich nur an den ersten:

1. Ausstellen. Die Zertifizierungsstelle prüft, ob Sie die Domain kontrollieren, und stellt Ihnen ein neues Zertifikat aus.
2. Einspielen. Das neue Zertifikat und der Schlüssel werden dorthin gelegt, wo der Webserver sie liest, und der Server wird angewiesen, sie zu laden.

Bis der zweite Schritt erledigt ist, liefert der Server weiter das alte Zertifikat aus, und das alte Enddatum gilt weiter. Eine erneuerte Datei auf der Festplatte ist kein erneuertes Zertifikat im Produktivbetrieb.

Automatische Verlängerung

Die meisten Zertifizierungsstellen erwarten heute, dass die Verlängerung automatisiert ist. Let's Encrypt zum Beispiel stellt Zertifikate aus, die standardmäßig 90 Tage gelten, und sein Integrationsleitfaden empfiehlt, zu verlängern, wenn noch etwa ein Drittel der Laufzeit übrig ist, damit ein fehlgeschlagener Versuch wiederholt werden kann.

Typische Werkzeuge, etwa Certbot und die ACME-Clients, die in viele Hosting-Panels und Webserver eingebaut sind, erledigen das nach Zeitplan. Sie versuchen die Verlängerung regelmäßig, ersetzen die Zertifikatsdateien, wenn es fällig ist, und können danach einen Befehl ausführen, etwa den Webserver neu zu laden.

Was auch immer Sie verwenden: Richten Sie es so ein, dass Sie sehen können, dass es funktioniert:

• Wissen Sie, wo es läuft und wie oft.
• Wissen Sie, wer informiert wird, wenn es fehlschlägt.
• Führen Sie einen Testlauf aus, wenn das Werkzeug ihn unterstützt. Certbot hat certbot renew --dry-run.

Zertifikate werden kürzer

Die Laufzeiten von Zertifikaten werden branchenweit verkürzt, wodurch die manuelle Verlängerung immer unpraktischer wird:

• Das CA/Browser Forum, das Gremium, das die Regeln für öffentliche Zertifikate festlegt, hat einen Zeitplan verabschiedet, der die maximale Gültigkeit von 398 Tagen auf 47 Tage senkt. Zertifikate, die ab dem 15. März 2026 ausgestellt werden, dürfen bis zu 200 Tage gelten, ab dem 15. März 2027 bis zu 100 Tage und ab dem 15. März 2029 bis zu 47 Tage.
• Let's Encrypt hat angekündigt, dass sein Standardprofil im Februar 2027 auf 64 Tage und im Februar 2028 auf 45 Tage umgestellt wird.

Wenn Sie einmal im Jahr von Hand verlängern, planen Sie die Automatisierung ein. Prüfen Sie die aktuellen Regeln Ihrer Zertifizierungsstelle, denn Zeitpläne können sich ändern.

Warum die automatische Verlängerung scheitern kann

Automatisch heißt nicht zuverlässig. Das sind die häufigen Gründe, aus denen Verlängerungen scheitern, ohne dass es jemand bemerkt:

• Der geplante Job ist stehen geblieben. Der Server wurde neu aufgesetzt, der Timer ging verloren oder der Job wurde nie aktiviert.
• Die Domain-Prüfung scheitert. Die Zertifizierungsstelle muss Ihre Website oder Ihre DNS-Einträge erreichen, um die Kontrolle zu bestätigen. Eine geänderte Firewall, eine umgezogene DNS-Zone, eine Weiterleitung, die nun die Challenge abfängt, oder ein vorgeschaltetes CDN können das stören.
• Das neue Zertifikat wird nicht geladen. Die Datei wird ersetzt, aber der Webserver wird nie neu geladen und behält das alte im Speicher.
• Ein anderer Server hält das Zertifikat. Ein Load Balancer, ein CDN oder ein zweiter Host liefert eine eigene Kopie aus, die kein Job aktualisiert.
• Ein Name wurde hinzugefügt oder entfernt. Das Zertifikat deckt nicht mehr alle verwendeten Hostnamen ab.
• Das Konto oder die Zugangsdaten sind abgelaufen. Ein API-Token für die DNS-Validierung wurde widerrufen, oder die Kontakt-E-Mail des Kontos existiert nicht mehr.
• Ratenbegrenzungen oder Änderungen bei der Zertifizierungsstelle. Zu viele Versuche oder eine Änderung der Regeln des Ausstellers können eine Anfrage ablehnen.

Der zweite und der dritte Grund sind in der Praxis die häufigsten, und keiner zeigt sich in den Zertifikatsdaten, bis es zu spät ist.

Zertifikatsketten und Probleme beim Einspielen

Ein Server sollte sein eigenes Zertifikat (das Endzertifikat) und die Zwischenzertifikate senden, die es mit einem vertrauenswürdigen Root verbinden. Fehlt ein Zwischenzertifikat, können manche Clients den Pfad trotzdem aufbauen und andere nicht. Die Website sieht dann in Ihrem Browser gut aus und scheitert in einer App, einem Kommandozeilenwerkzeug oder einem älteren Smartphone.

Anzeichen für dieses Problem:

• Die Website funktioniert in einem Desktop-Browser, scheitert aber mit curl oder aus einem Skript.
• openssl s_client endet mit einer Meldung, dass das erste Zertifikat nicht verifiziert werden kann.
• Nur manche Geräte beschweren sich.

Um die Kette anzusehen, die der Server sendet, ergänzen Sie -showcerts:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Suchen Sie am Ende der Ausgabe die Zeile, die mit Verify return code beginnt. 0 (ok) bedeutet, dass OpenSSL einen vertrauenswürdigen Pfad aufbauen konnte.

Weitere Fehler beim Einspielen, auf die Sie achten sollten: Zertifikat und Schlüssel passen nicht zusammen, auf einem von mehreren Servern wird ein altes Zertifikat ausgeliefert, oder die Website wird über einen Namen aufgerufen, den das Zertifikat nicht aufführt.

Den Ablauf des Zertifikats überwachen

Auch bei Automatisierung ist die Überwachung des Enddatums das Sicherheitsnetz. Sie fängt jeden der obigen Fehler auf, denn sie sieht auf das, was ausgeliefert wird, nicht auf das, was ausgeliefert werden sollte.

Eine gute Ablaufprüfung:

• Liest das Zertifikat, das Besucher erhalten, unter der echten Adresse.
• Warnt früh genug, um zu handeln, mit Tagen Spielraum, nicht Stunden.
• Warnt die Person, die das Problem beheben kann.
• Warnt erneut, wenn das Problem nicht behoben ist, oder lässt die Warnung zumindest nicht verloren gehen.

In UptimeWire

Für jede Website, deren Adresse mit https:// beginnt, prüft UptimeWire das Zertifikat getrennt von der Verfügbarkeitsprüfung. So verhält es sich:

• Eigener Zeitplan. Zertifikatsprüfungen laufen alle paar Stunden nach einem eigenen Zeitplan, nicht im Verfügbarkeitsintervall. Eine Warnung kann deshalb Stunden nach dem Überschreiten der Schwelle eintreffen und nicht im genauen Moment.
• Vorlaufzeit der Warnung. Sie wählen, wie viele Tage vor dem Ablauf Sie gewarnt werden möchten. Standard sind 30 Tage, und die Einstellung gilt je Website. Eine Warnung wird gesendet, wenn das Zertifikat weniger Tage übrig hat als eingestellt.
• Einmalig gesendet. Die Warnung wird gesendet, wenn die Prüfung in den Warnzustand wechselt, nicht bei jeder Prüfung danach.
• Ungültige Zertifikate. Lässt sich das Zertifikat gar nicht validieren (zum Beispiel, weil es abgelaufen oder für den falschen Namen ausgestellt ist), werden Sie sofort gewarnt und warten nicht auf die Schwelle.
• Kanäle. Zertifikatswarnungen gehen per E-Mail und, wenn Sie es verbunden haben, per Telegram. Chat- und Webhook-Kanäle übertragen sie nicht.

UptimeWire verlängert oder ersetzt keine Zertifikate. Es sagt Ihnen, dass es Zeit ist zu handeln.

Was zu tun ist, wenn ein Zertifikat abgelaufen ist

1. Bestätigen Sie es. Prüfen Sie die Daten mit einem Browser oder dem OpenSSL-Befehl oben, unter der echten Adresse.
2. Finden Sie heraus, wo das Zertifikat ausgeliefert wird. Das kann Ihr Webserver sein, ein Load Balancer, ein CDN oder ein Hosting-Panel.
3. Verlängern Sie es. Führen Sie das Verlängerungswerkzeug aus oder beantragen Sie ein neues Zertifikat bei Ihrer Zertifizierungsstelle. Ist die Automatisierung gescheitert, lesen Sie deren Log, um den Grund zu finden.
4. Spielen Sie es ein. Installieren Sie das neue Zertifikat und laden Sie den Dienst neu, der es ausliefert.
5. Prüfen Sie erneut von außen. Lesen Sie die Daten unter der Live-Adresse ab und prüfen Sie die Kette.
6. Finden Sie die Ursache. Beheben Sie, warum die Automatisierung gescheitert ist, sonst passiert dasselbe bei der nächsten Verlängerung.
7. Informieren Sie bei Bedarf die Betroffenen. Haben Kunden die Warnung gesehen, lohnt sich ein kurzer Hinweis auf einer Statusseite oder per E-Mail.

Checkliste zur Vorbeugung

• Jeder öffentliche Hostname ist aufgeführt, mit dem Zertifikat, das ihn abdeckt, und dem Ort, an dem es ausgeliefert wird.
• Die Verlängerung ist automatisch, und Sie wissen, wo sie läuft.
• Jemand erhält die Fehlermeldung des Verlängerungsjobs.
• Der Webserver wird nach dem Ersetzen des Zertifikats neu geladen.
• Die Kette ist vollständig (Verify return code: 0 (ok)).
• Das Enddatum wird von außen überwacht, mit einer Vorlaufzeit der Warnung von mindestens zwei Wochen.
• Die Warn-E-Mail geht an ein Postfach, das ein Mensch liest.
• Sie prüfen die Daten nach jedem Wechsel von Server, CDN oder Hosting.
• Domain-Registrierung und DNS werden ebenfalls überwacht, denn sie fallen auf dieselbe unauffällige Weise aus. Siehe den Komplettleitfaden zur Überwachung der Website-Verfügbarkeit.

Zur anderen Seite des Problems, nämlich zu bemerken, wenn eine Website aus irgendeinem Grund nicht erreichbar ist, lesen Sie So überwachen Sie die Verfügbarkeit einer Website.