ERR_CERT_DATE_INVALID: abgelaufenes Zertifikat oder falsche Uhr

Was ERR_CERT_DATE_INVALID bedeutet

Jedes TLS-Zertifikat trägt zwei Zeitstempel, "Valid from" und "Valid to" (die X.509-Felder notBefore und notAfter). Während des Handshakes vergleicht der Browser diese Zeitstempel mit seiner eigenen Vorstellung der aktuellen Zeit. Ist das Zeitfenster des Zertifikats geschlossen, oder noch nicht geöffnet, oder platziert die Uhr des Browsers "jetzt" aus irgendeinem Grund außerhalb dieses Fensters, stoppt der Handshake, bevor der Browser überhaupt prüft, wer das Zertifikat ausgestellt hat. Chrome und Edge zeigen NET::ERR_CERT_DATE_INVALID. Firefox zeigt SEC_ERROR_EXPIRED_CERTIFICATE für den abgelaufenen Fall. Safari zeigt "This certificate has expired" oder "This certificate is not yet valid".

Zwei unterschiedliche Situationen erzeugen exakt dieselbe Warnung, und der Browser kann Ihnen nicht sagen, welche es ist: Das Zertifikat ist tatsächlich abgelaufen oder noch nicht gültig, oder das Zertifikat ist in Ordnung und die Uhr des Clients geht falsch. Beide scheitern am selben Vergleich.

Wie sich der Fehler zeigt

Im Browser lädt die Seite gar nicht erst, und statt eines Schloss-Symbol-Fehlers auf einer sonst geladenen Seite erscheint eine ganzseitige Warnung. Ein Klick auf "Erweitert" zeigt den genauen Grund und, in Chrome, die eigenen Daten des Zertifikats.

Von der Kommandozeile aus meldet curl denselben Fehlschlag präziser:

curl -v https://example.com/
...
* SSL certificate problem: certificate has expired
* Closing connection

Ein noch nicht gültiges Zertifikat erzeugt eine ähnliche Zeile mit "certificate is not yet valid". Server- und Anwendungslogs auf Seiten des Website-Betreibers zeigen für diesen Fehler meist gar nichts, denn der TLS-Handshake scheitert, bevor überhaupt eine HTTP-Anfrage protokolliert wird. Der Beleg liegt im Zertifikat und im Client, nicht im Zugriffslog des Webservers.

Was ERR_CERT_DATE_INVALID verursacht

• Das Zertifikat ist abgelaufen. Die Verlängerung fand nicht vor dem "Valid to"-Datum statt, meist weil ein automatisierter Verlängerungsjob still aufgehört hat zu laufen.
• Das Zertifikat ist noch nicht gültig. Seltener: Ein Zertifikat wurde mit einem "Valid from"-Datum leicht in der Zukunft ausgestellt oder neu ausgestellt, oder ein Server hat begonnen, ein neues Zertifikat auszuliefern, bevor dessen Fenster geöffnet war.
• Ein Zwischenzertifikat in der Kette ist abgelaufen. Das Endzertifikat kann völlig aktuell sein, während ein Zwischenzertifikat, das der Server noch sendet, seinen eigenen Ablauf überschritten hat, und manche Clients prüfen jedes Zertifikat in der Kette.
• Die Uhr des Besuchergeräts geht falsch. Ein Laptop, der monatelang aus war, ein Handy mit deaktivierter automatischer Zeitsynchronisation, oder ein Gerät mit toter CMOS-Batterie kann mit einem um Jahre falschen Datum starten, in beide Richtungen.
• Eine virtuelle Maschine oder ein Container mit veralteter Uhr. VMs, die einen Snapshot hatten, geklont oder nach einer langen Pause fortgesetzt wurden, starten häufig mit einer Uhr, die erst nachzieht, sobald eine NTP-Synchronisation abgeschlossen ist.
• Eine falsch konfigurierte Zeitzone oder ein falsch manuell gesetztes Datum, gesetzt von einem Nutzer oder einem Kiosk-Gerät ohne eigene Zeitquelle.

So finden Sie heraus, wer schuld ist

Am schnellsten prüfen Sie das Zertifikat von einem anderen Ort als dem betroffenen Gerät aus. Lädt ein zweites Gerät mit nachweislich korrekter Uhr, oder ein Prüfpunkt außerhalb Ihres eigenen Netzwerks, die Website ohne Datumswarnung, ist das Zertifikat in Ordnung, und das Problem liegt lokal an der Uhr dieses einen Geräts. Meldet jeder Blickwinkel dasselbe abgelaufene oder noch nicht gültige Datum, braucht das Zertifikat selbst Aufmerksamkeit. Eine SSL-Prüfung von mehreren Standorten gleichzeitig klärt das in einem Schritt, statt sich einen zweiten Laptop zum Testen zu leihen.

So beheben Sie ERR_CERT_DATE_INVALID

Wenn Sie Besucher sind

1. Prüfen Sie zuerst Datum, Uhrzeit und Zeitzone Ihres Geräts. Das ist die mit Abstand häufigste selbst verursachte Ursache, besonders bei Android-Geräten mit deaktivierter automatischer Zeitsynchronisation, älteren, unbenutzt herumliegenden Laptops, und Rechnern mit schwacher CMOS-Batterie. Schalten Sie "Zeit automatisch einstellen" ein und bestätigen Sie, dass das Jahr stimmt, nicht nur das Ziffernblatt.
2. Probieren Sie die Website auf einem anderen Gerät oder Netzwerk. Lädt sie dort sauber, ist die Uhr Ihres ursprünglichen Geräts (oder ein Captive Portal, das die Verbindung abfängt) die Ursache, nicht die Website.
3. Lesen Sie die tatsächlichen Daten auf der Warnseite, bevor Sie sonst etwas tun. Chromes "Erweitert"-Bereich und der Zertifikat-Betrachter zeigen beide "Valid from" und "Valid to" im Klartext, was Ihnen sofort sagt, ob das Zertifikat abgelaufen, noch nicht gültig ist, oder ob Ihre Uhr der Ausreißer ist.
4. Klicken Sie sich nicht durch ein tatsächlich abgelaufenes Zertifikat auf einer Website, die irgendetwas Sensibles verarbeitet. Sobald die Uhr korrigiert ist, laden Sie neu; wiederholen Sie nicht einfach denselben kaputten Zustand.

Wenn Sie die Website betreiben

1. Lesen Sie die eigenen Daten des Zertifikats direkt aus, statt einer Kalendererinnerung zu vertrauen:

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

   Das gibt notBefore und notAfter direkt aus dem Zertifikat aus, das der Server gerade jetzt tatsächlich präsentiert.
2. Nutzen Sie Let's Encrypt, prüfen Sie den Verlängerungsjob, nicht nur das Zertifikat. Let's-Encrypt-Zertifikate gelten per Design 90 Tage und verlängern sich automatisch um die 30-Tage-Marke, aber die Automatisierung kann wochenlang still scheitern, bevor es jemand bemerkt: systemctl status certbot.timer (oder der entsprechende Cron-Eintrag) bestätigt, dass der Timer noch aktiviert ist und auslöst, und certbot renew --dry-run durchläuft den Verlängerungspfad, ohne etwas Produktives zu ändern. Lesen Sie /var/log/letsencrypt/letsencrypt.log für den tatsächlichen Fehlschlag, fast immer eines von: eine DNS-01-Challenge, deren API-Zugangsdaten abgelaufen sind, eine Firewall-Änderung, die den HTTP-01-Challenge-Pfad blockiert, oder Let's Encrypts Ratenlimits, die während wiederholter Fehlersuche erreicht wurden.
3. Prüfen Sie die gesamte Kette, die Ihr Server sendet, nicht nur das Endzertifikat:

   openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null   | openssl x509 -noout -dates -in -

   Manche Server liefern weiterhin ein altes Zwischenzertifikat von der Platte, nachdem sie das Endzertifikat ausgetauscht haben. Jedes Zertifikat in der Kette braucht ein aktuelles Gültigkeitsfenster, da manche Clients den gesamten Pfad validieren.
4. Prüfen Sie die eigene Systemuhr des Servers. Ein Server mit falscher Zeit kann automatisierte Verlängerungen mit einem falschen "Valid from"-Datum ausstellen, und kann auch seine eigene OCSP- und Handshake-Validierung unabhängig von der Zertifikatsprüfung zum Scheitern bringen. Bestätigen Sie, dass NTP läuft und synchronisiert ist.
5. Verlängern oder erneuern Sie das Zertifikat, laden Sie dann den Webserver neu. Ein auf der Platte liegendes, verlängertes Zertifikat bewirkt nichts, bis der Prozess, der TLS bedient, es aufnimmt: nginx -s reload, systemctl reload apache2, oder das Äquivalent für einen Load Balancer oder eine CDN-Edge mit eigener Kopie.
6. Bestätigen Sie die Lösung von außerhalb Ihrer eigenen Infrastruktur, nach dem Neuladen, da ein Browser oder Betriebssystem auf Ihrem Rechner das alte Zertifikat für eine Sitzung zwischenspeichern kann.

So beugen Sie ERR_CERT_DATE_INVALID vor

Ein ablaufendes Zertifikat warnt niemanden, der nicht gezielt darauf achtet: Die Website funktioniert weiter, bis genau in der Sekunde, in der das Fenster schließt, dann sehen alle Besucher gleichzeitig dieselbe Warnung. Eine geplante SSL-Prüfung, die die Daten des Zertifikats liest und vor der Frist alarmiert, statt erst, nachdem Besucher eine kaputte Website melden, macht aus einem stillen Verlängerungsfehler ein behebbares Ticket mit Tagen Vorlaufzeit. HostTrackers SSL- und Domain-Ablaufprüfungen verfolgen das tatsächliche Gültigkeitsfenster des Zertifikats von außerhalb Ihrer Infrastruktur und alarmieren per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr, bevor es abläuft; führen Sie jetzt eine SSL-Zertifikatsprüfung aus. Die begleitende Anleitung zum Prüfen des SSL-Zertifikatsablaufs behandelt die Einrichtung im Detail.

Verwandte Fehler

• ERR_CERT_AUTHORITY_INVALID - die Daten des Zertifikats sind in Ordnung, aber der Browser vertraut dem Aussteller nicht.
• ERR_CERT_COMMON_NAME_INVALID - das Zertifikat ist gültig und vertrauenswürdig, wurde aber nicht für den Hostnamen in der Adressleiste ausgestellt.
• ERR_SSL_PROTOCOL_ERROR - der Handshake scheiterte, bevor überhaupt ein Zertifikat erreicht wurde, meist eine falsch passende TLS-Version, ein falscher Port oder eine falsche Konfiguration.

Häufig gestellte Fragen

Ist es sicher, sich durch eine ERR_CERT_DATE_INVALID-Warnung zu klicken?

Nur wenn Sie sicher sind, dass die Ursache die Uhr Ihres eigenen Geräts ist, da Sie das unabhängig prüfen können. Ist das Zertifikat selbst tatsächlich abgelaufen, entfernt das Durchklicken die eine Prüfung, die bestätigt, dass Sie über einen verschlüsselten, verifizierten Kanal mit dem echten Server sprechen.

Warum passiert das direkt nach dem Zurücksetzen oder Auspacken eines Geräts?

Ein Werksreset oder ein lange unbenutztes Gerät startet oft mit einer auf ein Standarddatum zurückgesetzten internen Uhr, manchmal Jahre in der Vergangenheit. Bis es sich mit dem Internet verbindet und die Zeit automatisch synchronisiert, kann jede HTTPS-Website mit einem Datumsfehler scheitern, nicht nur eine.

Behebt das Leeren meines Browser-Caches ERR_CERT_DATE_INVALID?

Selten. Dieser Fehler ist ein Live-Vergleich zwischen den Daten des Zertifikats und der aktuellen Uhr, bei jeder Verbindung neu ausgewertet, ein Cache-Löschen ändert das Ergebnis also nicht. Das Korrigieren der Uhr oder des Zertifikats schon.

Warum ist mein Let's-Encrypt-Zertifikat ohne Warnung abgelaufen?

Weil die Verlängerung vollständig automatisch ablaufen soll, prüft sie niemand manuell, sodass ein kaputter Cron-Job, eine abgelaufene DNS-API-Zugangsdaten oder eine geänderte Firewall-Regel Verlängerungen wochenlang still stoppen können, ohne sichtbares Symptom, bis das Zertifikat tatsächlich abläuft.

Kann ein CDN oder Load Balancer ändern, was Besucher bei diesem Fehler sehen?

Ja. Hält die CDN-Edge ein abgelaufenes Zertifikat, sieht jeder Besucher den Fehler, unabhängig davon, welches Zertifikat der Ursprungsserver hat, prüfen Sie also die Schicht, die TLS für die fehlgeschlagene Anfrage tatsächlich terminiert.

Wie oft sollte ich das Ablaufdatum meines Zertifikats prüfen?

Eine tägliche automatisierte Prüfung reicht, um einen Verlängerungsfehler mit Wochen Vorlauf zu erfassen, da Let's-Encrypt-Zertifikate 90 Tage gültig sind und die meisten anderen Zertifikate 90 Tage bis ein Jahr laufen.