Abgelaufenes SSL-Zertifikat beheben: Schritt für Schritt

Was „Zertifikat abgelaufen“ tatsächlich bedeutet

Jedes TLS-Zertifikat trägt zwei Daten: nicht vor und nicht nach. Der Browser vergleicht bei jeder Verbindung die Uhr mit diesen Daten. Nach dem nicht nach-Datum ist das Zertifikat kein gültiger Nachweis mehr, also weigert sich der Browser weiterzumachen und zeigt statt Ihrer Seite eine bildschirmfüllende Warnung.

Daraus folgen drei Dinge, und sie sind der Grund, warum das dringend und nicht kosmetisch ist:

• Auf Ihrem Server ist nichts kaputt. Die Seite läuft, die Dateien sind in Ordnung, die Datenbank ist in Ordnung. Ein Datum ist verstrichen.
• Es passiert nicht schleichend. Es gibt keinen eingeschränkten Betrieb – die Seite funktioniert bis zur Sekunde des Ablaufs, danach ist es für jeden Besucher eine Warnseite.
• Es betrifft mehr als Browser. API-Clients, Mobil-Apps, Webhooks von Zahlungsanbietern und alles, was eine strenge HTTP-Bibliothek nutzt, verweigern die Verbindung ebenfalls – meist mit einer weit weniger hilfreichen Meldung.

Die Lösung hat immer dieselbe Form: neues Zertifikat holen, einbinden, den Dienst neu laden, der es ausliefert. Die meiste Zeit geht bei diesem Problem in den zweiten und dritten Schritt, nicht in den ersten.

Zuerst bestätigen, dass es wirklich der Ablauf ist

Mehrere verschiedene Probleme erzeugen eine ähnlich aussehende Warnseite, und die Lösung ist jeweils völlig anders. Lesen Sie den Fehlercode, nicht die Überschrift.

• NET::ERR_CERT_DATE_INVALID – das ist der Ablauf (oder eine massiv falsch gestellte Serveruhr). Lesen Sie hier weiter.
• NET::ERR_CERT_COMMON_NAME_INVALID – das Zertifikat ist gültig, deckt aber den aufgerufenen Namen nicht. Häufig, wenn www oder eine neue Subdomain vergessen wurde.
• NET::ERR_CERT_AUTHORITY_INVALID – selbst ausgestellt, oder die ausstellende Stelle gilt nicht als vertrauenswürdig, oder im Auslieferungsumfang des Servers fehlt ein Zwischenzertifikat.
• SSL_ERROR_BAD_CERT_DOMAIN (so formuliert Firefox) – dieselbe Namensabweichung wie oben.

Prüfen Sie die Daten von außerhalb Ihres eigenen Rechners und nicht in dem Browser, den Sie schon offen haben, damit kein lokaler Cache und kein veralteter Proxy Sie in die Irre führt. Ein SSL Checker zeigt Aussteller, Gültigkeitsdaten, Resttage und alle vom Zertifikat gedeckten Namen. Liegt das Enddatum in der Vergangenheit, ist es bestätigt – und Sie wissen gleich, ob die Namen, die Sie brauchen, überhaupt im Zertifikat stehen, was Ihnen eine zweite Runde erspart.

Erneuern und einbinden: vier Schritte

Diese vier Schritte sind die ganze Arbeit. Den dritten überspringen die meisten.

1. Neues Zertifikat holen

Mit Let's Encrypt oder einem beliebigen ACME-Client ist das meist ein einzelner Befehl – certbot renew oder der Erneuern-Knopf im Panel. Wenn die Erneuerung fehlschlägt und nicht bloß überfällig ist, springen Sie weiter unten zum Abschnitt über fehlgeschlagene Erneuerungen: ein erneuter Aufruf scheitert genauso.

Bei einem kostenpflichtigen Zertifikat müssen Sie vielleicht eine neue CSR erzeugen, die Domain-Validierung erneut durchlaufen und die ausgestellten Dateien herunterladen. Behalten Sie den privaten Schlüssel, mit dem Sie die CSR erzeugt haben – ohne ihn ist das Zertifikat wertlos.

2. Die vollständige Kette einbinden, nicht nur das Zertifikat

Ihr Server muss Ihr Zertifikat und die Zwischenzertifikate ausliefern, die es mit einer vertrauenswürdigen Wurzel verbinden. Eine Zertifizierungsstelle gibt üblicherweise beides heraus: die Blattdatei und ein Bundle oder eine Kettendatei. Nur das Blatt einzubinden erzeugt bei manchen Clients einen Fehler „Aussteller ungültig“ und die unerklärliche Lage „bei mir im Browser geht es doch“ – weil Browser Zwischenzertifikate oft von anderen Seiten im Cache haben, ein frischer Client aber nicht.

Zeigen Sie in der Konfiguration auf die Datei mit der vollständigen Kette (bei Let's Encrypt heißt sie fullchain.pem) und auf den passenden privaten Schlüssel.

3. Den Dienst neu laden

Die Dateien zu schreiben ändert von sich aus nichts. Der laufende Prozess hat das alte Zertifikat beim Start in den Speicher geladen und liefert es weiter aus, bis man ihm etwas anderes sagt. Laden Sie nginx, Apache, Caddy, HAProxy, den Load Balancer oder was auch immer TLS terminiert neu. Das ist der mit Abstand häufigste Grund, warum ein korrekt erneuertes Zertifikat weiterhin als abgelaufen erscheint.

Wird TLS an anderer Stelle terminiert – einem CDN, einem Reverse Proxy, einem verwalteten Load Balancer, dem Edge einer Plattform –, dann braucht genau das das neue Zertifikat, und die Dateien auf Ihrem Origin-Server sind womöglich bedeutungslos.

4. Von außen prüfen

Fragen Sie den produktiven Hostnamen von außerhalb Ihres Netzes erneut ab und bestätigen Sie das neue Enddatum und die gedeckten Namen. Verlassen Sie sich nicht auf Ihren eigenen Browser, der Ihnen noch eine gecachte Verbindung oder eine Zwischenseite zeigen kann. Prüfen Sie www und den Apex getrennt, wenn beide die Seite ausliefern – sie können unterschiedliche Zertifikate haben.

Wenn die automatische Erneuerung still stehen blieb

Wenn Sie einen ACME-Client haben, bedeutet ein abgelaufenes Zertifikat, dass die Erneuerung seit Wochen fehlschlägt – meist in einem Cronjob, den niemand liest. Die üblichen Ursachen, grob nach Häufigkeit:

• Die HTTP-01-Challenge erreicht den Server nicht mehr. Eine neue Weiterleitung, die allen HTTP-Verkehr auf HTTPS schickt, eine Firewall-Regel oder eine Rewrite-Regel, die /.well-known/acme-challenge/ abfängt, bricht die Validierung. Dieser Pfad muss per unverschlüsseltem HTTP erreichbar bleiben.
• Das DNS hat sich geändert. Der Name zeigt jetzt woanders hin, die Challenge wird also von einem Host ausgeliefert, der das Token nicht hat. Wenn Sie kürzlich das Hosting gewechselt haben, ist es fast sicher das – fragen Sie den Namen ab und sehen Sie mit einem DNS-Abfrage-Tool nach, wohin er tatsächlich auflöst.
• Ein Name im Zertifikat existiert nicht mehr. ACME erneuert immer den ganzen Satz: eine stillgelegte Subdomain, die nicht mehr auflöst, lässt die gesamte Erneuerung scheitern, samt der noch aktiven Namen.
• Timer oder Cronjob laufen nicht. Nach einem Serverumzug oder einem System-Upgrade ist der systemd-Timer oder der Cron-Eintrag häufig einfach verschwunden.
• Der Client ist zu alt. Die ACME-v1-Endpunkte sind längst abgeschaltet; ein Client, der jahrelang nicht aktualisiert wurde, kann überhaupt nicht mehr erneuern.

Starten Sie die Erneuerung von Hand und lesen Sie den Fehler, statt sie erneut zu planen und zu hoffen. Ein Testlauf sagt Ihnen, ob der nächste automatische Versuch erfolgreich wäre – und das ist die einzige Frage, die zählt.

Wenn das Zertifikat in Ordnung ist, die Kette aber nicht

Manchmal ist Ihr eigenes Zertifikat reichlich gültig und die Seite scheitert dennoch. Die übliche Erklärung: ein Zwischenzertifikat der Kette ist abgelaufen, oder Ihr Server liefert eine veraltete Kette aus, die eine inzwischen abgelaufene kreuzsignierte Wurzel enthält.

Das führte 2021 zu einem berühmten Ausfall, als eine weit verbreitete Wurzel ablief: Tausende Seiten, die eine alte Kette auslieferten, begannen auf älteren Clients zu scheitern, während sie in aktuellen Browsern völlig in Ordnung aussahen. Das Symptom ist charakteristisch – moderne Desktop-Browser sind zufrieden, während ältere Geräte, manche Mobil-Apps und serverseitige HTTP-Clients die Verbindung ablehnen.

Die Lösung ist, die Kette einzubinden, die Ihre Zertifizierungsstelle heute veröffentlicht, und nicht die Datei von vor Jahren – und danach neu zu laden. Sehen Sie nach, was Ihr Server tatsächlich ausliefert, nicht was Sie glauben, und bestätigen Sie jedes Zertifikat der Kette samt eigenem Ablaufdatum mit dem Zertifikatsprüfer.

Warum es nach der Reparatur noch „abgelaufen“ sagt

Sie haben erneuert, eingebunden, neu geladen – und die Warnung steht weiter da. Arbeiten Sie das der Reihe nach durch:

• Etwas anderes terminiert TLS. Ein CDN oder Proxy vor Ihrem Origin liefert den Besuchern sein eigenes Zertifikat. Dort aktualisieren.
• Hinter dem Namen steht mehr als ein Server. Bei mehreren Backends hinter einem Load Balancer bedeutet ein Zertifikat auf nur einem davon, dass etwa die Hälfte Ihrer Besucher weiter das alte sieht – und dass ein Neuladen der Seite es manchmal behebt, ist der Hinweis.
• Ihr Browser zeigt Ihnen einen gecachten Zustand. Probieren Sie ein privates Fenster, einen anderen Browser oder eine Prüfung ganz von außerhalb Ihres Netzes.
• Mehrere virtuelle Hosts, nur einer aktualisiert. Der getestete Hostname ist nicht der, den der Besucher benutzt. Prüfen Sie jeden Namen einzeln.
• Das Neuladen hat gar nicht stattgefunden. Ein fehlgeschlagener Konfigurationstest bedeutet oft, dass der Dienst mit alter Konfiguration und altem Zertifikat weiterläuft. Schauen Sie auf den Dienststatus, nicht nur auf den Rückgabewert Ihres Befehls.

So passiert es nicht wieder

Der Ablauf ist der am besten vermeidbare Ausfall überhaupt, denn die Frist wird Monate im Voraus veröffentlicht.

• Erneuerung automatisieren – und die Automatisierung prüfen. Ein ACME-Client mit Timer und ein Testlauf, den Sie wirklich erfolgreich gesehen haben. Ungetestete Automatisierung ist keine Automatisierung.
• Resttage überwachen, nicht nur Erreichbarkeit. Ein Uptime-Check ist bis zur Sekunde des Ablaufs grün und sagt vorher nichts. Warnen Sie bei 21 Tagen und noch einmal bei 7.
• Die Namensliste des Zertifikats ehrlich halten. Entfernen Sie stillgelegte Subdomains, damit ein toter Name nicht die ganze Erneuerung scheitern lässt.
• Auf kürzere Laufzeiten achten. Zertifikatslaufzeiten werden seit Jahren kürzer und werden weiter kürzer. Jeder Prozess, der sich darauf verlässt, dass ein Mensch sich erinnert, wird brechen; Automatisierung ist nicht länger optional.
• Nach jeder Migration die Kette prüfen. Ein Hostingwechsel ist der Moment, in dem ein veraltetes Zwischenzertifikat oder ein vergessener TLS-Terminator auffällt.

Wer das vollständige Bild davon will, was in einem Zertifikat steht und wie man eine Kette liest: der Leitfaden zum Prüfen von SSL/TLS-Zertifikaten geht jedes Feld durch.

Häufige Fehler

• Das neue Zertifikat einbinden und den Dienst nicht neu laden. Die häufigste Ursache für „ich habe es behoben und es ist weiter kaputt“.
• Das Blatt ohne die Zwischenkette einbinden. Funktioniert in Ihrem Browser und scheitert bei anderen Clients.
• Eine fehlschlagende Erneuerung unverändert wiederholen. Sie scheitert identisch; lesen Sie zuerst den Fehler.
• Die Reparatur im schon benutzten Browser beurteilen. Prüfen Sie von außerhalb Ihres Netzes.
• Den Apex reparieren und www vergessen – oder umgekehrt.
• Den privaten Schlüssel löschen, während es hektisch ist. Ohne ihn lässt sich das neue Zertifikat nicht einbinden.
• Sich auf einen Uptime-Monitor verlassen, der vor dem Ablauf warnen soll. Das kann er nicht.

Kurzfassung

Ein abgelaufenes Zertifikat ist ein Datumsproblem, kein Serverproblem: bestätigen Sie, dass der Fehler wirklich NET::ERR_CERT_DATE_INVALID ist, stellen Sie ein neues Zertifikat aus, binden Sie die vollständige Kette mit dem passenden privaten Schlüssel ein, laden Sie den Dienst neu, der TLS terminiert, und prüfen Sie dann das neue Ablaufdatum von außerhalb Ihres Netzes. Sollte die Erneuerung automatisch laufen, finden Sie heraus, warum sie stehen blieb – meist ein blockierter ACME-Challenge-Pfad, eine DNS-Änderung oder eine stillgelegte Subdomain –, bevor Sie sie erneut planen. Überwachen Sie danach die Resttage, damit die nächste nie bei null ankommt. Prüfen Sie Zertifikat, Kette und exaktes Ablaufdatum jeder Domain mit dem kostenlosen SSL Checker und bestätigen Sie mit dem DNS-Lookup-Tool, wohin der Name zeigt.

Verwandte Tools und Leitfäden:

• SSL Checker – Prüfen Sie das SSL-Zertifikat jeder Domain: Aussteller, Ablaufdatum und verbleibende Tage.
• Sicherheits-Header-Prüfer – Prüfen Sie HSTS, CSP, X-Frame-Options und andere wichtige Sicherheitsheader.
• SSL Checker: ein vollständiger Leitfaden zum Prüfen von SSL/TLS-Zertifikaten – Lerne

Häufige Fragen