Abgelaufene SSL/TLS-Zertifikate: Warum sie Websites immer noch lahmlegen

Wenn ein TLS-Zertifikat abläuft, vertrauen Browser der Verbindung nicht mehr und zeigen statt Ihrer Website eine ganzseitige Warnung. APIs, mobile Apps und Integrationen, die sich mit demselben Host verbinden, scheitern meist vollständig, weil ihre Clients ein abgelaufenes Zertifikat ablehnen, ohne jemanden zu fragen. Die Website selbst kann einwandfrei laufen, für Besucher ist sie trotzdem nicht erreichbar.

Die Erneuerung ist seit Jahren automatisiert. Warum passiert das also immer noch? Weil die Automatisierung nur die Zertifikate abdeckt, an deren Automatisierung jemand gedacht hat. Ausfälle durch abgelaufene Zertifikate entstehen meist bei den vergessenen: einer Subdomain für eine Kampagne, einem Load Balancer mit manuell hochgeladenem Zertifikat, einem Mailserver oder einem Erneuerungsjob, der seit Wochen unbemerkt fehlschlägt.

Außerdem werden die Laufzeiten von Zertifikaten kürzer. Jeder Erneuerungsprozess wird also häufiger auf die Probe gestellt.

Die Laufzeiten von Zertifikaten schrumpfen

Das CA/Browser Forum legt die Regeln fest, an die sich allgemein vertrauenswürdige Zertifizierungsstellen halten. Im April 2025 verabschiedete es Ballot SC-081v3, und die aktuellen TLS Baseline Requirements (Abschnitt 6.3.2) legen diesen Zeitplan für die maximale Gültigkeit eines Zertifikats fest:

• ausgestellt vor dem 15. März 2026: höchstens 398 Tage,
• ausgestellt ab dem 15. März 2026: höchstens 200 Tage,
• ausgestellt ab dem 15. März 2027: höchstens 100 Tage,
• ausgestellt ab dem 15. März 2029: höchstens 47 Tage.

In der Praxis heißt das: Bis 2029 müsste ein manuell erneuertes Zertifikat ungefähr alle 6 bis 7 Wochen ersetzt werden. Jedes Zertifikat, das noch von Hand nach einer Kalendererinnerung erneuert wird, wird zu einem wiederkehrenden Ausfallrisiko.

Auf Erinnerungen der Zertifizierungsstelle sollten Sie sich ebenfalls nicht verlassen. Let's Encrypt zum Beispiel hat seine E-Mails zum Ablauf von Zertifikaten am 4. Juni 2025 eingestellt.

Warum Erneuerungen scheitern

Die üblichen Ursachen sind banal:

• Die Validierung schlägt fehl. Die HTTP-Validierung bricht nach einer Weiterleitung oder einer Firewall-Änderung, die DNS-Validierung nach einem Wechsel des DNS-Anbieters oder einem abgelaufenen API-Token.
• Die Erneuerung gelingt, aber der Dienst wird nicht neu geladen, sodass der Webserver weiter das alte Zertifikat ausliefert.
• Zertifikate wurden von Hand kopiert auf einen Load Balancer, ein CDN, eine Appliance oder einen Mailserver, den die Automatisierung nicht erreicht.
• Niemand ist für den Host zuständig. Staging-Server und alte Marketing-Subdomains haben oft Zertifikate, aber keinen Verantwortlichen. Siehe vergessene Staging- und Testserver.
• Das Konto oder die Zahlung für ein kommerzielles Zertifikat ist ausgelaufen.
• Die Zwischenzertifikatskette ist unvollständig, was manche Clients schon vor dem Ablauf ablehnen.

So prüfen Sie das Ablaufdatum selbst

Für einen einzelnen Host zeigt openssl die Daten, die der Server tatsächlich ausliefert:

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

Achten Sie auf notAfter. Prüfen Sie jeden Namen einzeln, auch www, API-Hosts und Mail-Hosts. Für einen Mailserver mit STARTTLS:

echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -enddate

Um Hosts zu finden, die Sie vergessen haben könnten, durchsuchen Sie die Certificate-Transparency-Logs auf crt.sh nach %.example.com. Dort ist jedes für Ihre Domain ausgestellte Zertifikat verzeichnet, auch für Subdomains, an die sich niemand erinnert. Unser Artikel zu Certificate-Transparency-Logs erklärt, wie Sie die Ergebnisse lesen.

So verhindern Sie, dass Zertifikate ablaufen

1. Automatisieren Sie Ausstellung und Erneuerung wo immer möglich mit ACME, und sorgen Sie dafür, dass der Erneuerungsjob den Dienst danach neu lädt.
2. Erneuern Sie rechtzeitig vor dem Ablauf, früh genug, um eine fehlgeschlagene Validierung noch beheben zu können.
3. Alarmieren Sie bei fehlgeschlagenen Erneuerungen, nicht nur bei erfolgreichen. Ein Cronjob, der mit einem Fehler endet und niemandem Bescheid gibt, ist die klassische Ursache.
4. Führen Sie ein Inventar aller Hosts mit Zertifikat, aufgebaut aus den Ergebnissen der Certificate Transparency, nicht aus dem Gedächtnis.
5. Überwachen Sie von außen. Prüfen Sie das Zertifikat, das der Server tatsächlich ausliefert, denn genau das sehen die Clients. Ein interner Vermerk „erneuert“ ist nicht dasselbe.
6. Entfernen Sie, was Sie nicht mehr nutzen. Eine Subdomain, die nichts mehr ausliefert, sollte ihren DNS-Eintrag und ihr Zertifikat verlieren.

Wenn ein Zertifikat bereits abgelaufen ist

• Erneuern oder stellen Sie es neu aus, spielen Sie es ein und laden Sie den Dienst neu.
• Bestätigen Sie mit openssl s_client von außerhalb Ihres Netzes, dass das neue notAfter-Datum ausgeliefert wird.
• Prüfen Sie, dass die vollständige Kette ausgeliefert wird, nicht nur das Endzertifikat.
• Prüfen Sie abhängige Clients: Mobile Apps, Integrationen von Partnern und Webhooks brauchen möglicherweise einen erneuten Versuch.
• Finden Sie heraus, warum der Alarm nicht ausgelöst wurde, und beheben Sie das.

Checkliste

• Inventar aller Hosts mit Zertifikaten, einschließlich Mail- und API-Hosts.
• ACME-Automatisierung mit Neuladen des Dienstes.
• Alarme bei fehlgeschlagenen Erneuerungen.
• Externe Prüfung des Ablaufdatums auf jedem Host.
• Vorbereitung auf Laufzeiten von 100 und 47 Tagen.

Auch Domains laufen ab, mit ganz anderen Folgen. Siehe was passiert, wenn Ihre Domain abläuft.

Wie Datahorses hilft

Datahorses überwacht Ihr Unternehmen von außen und prüft die Zertifikate, die Ihre Server tatsächlich ausliefern, einschließlich Ablauf, unvollständiger Ketten und selbstsignierter Zertifikate, mit Erinnerungen 30, 14 und 3 Tage bevor ein Zertifikat oder eine Domain abläuft. Wir greifen nicht auf Ihre Systeme zu und benötigen keinen Zugang. Sehen Sie sich an, was wir überwachen, und im Beispiel-Dashboard, wie das aussieht.