ERR_CERT_DATE_INVALID: Bedeutung und Lösung

NET::ERR_CERT_DATE_INVALID ist Chromes Art zu sagen, dass das Zertifikat der Website gerade jetzt nicht gültig ist: Entweder ist das Zertifikat abgelaufen (oder noch nicht gültig), oder die Uhr Ihres eigenen Geräts geht falsch, sodass ein einwandfreies Zertifikat abgelaufen wirkt. Googles eigene Daten zeigen, dass die zweite Ursache weit häufiger ist, als die meisten erwarten: Unter Windows steckt eine falsche Systemuhr hinter 33,5 % aller Zertifikatswarnungen in Chrome, gegenüber 4,23 % für tatsächlich abgelaufene Zertifikate (Acer et al., ACM CCS 2017). Dieser Leitfaden zeigt, wie Sie beide Fälle in unter einer Minute unterscheiden, wie Sie jeden davon als Besucher oder als Website-Betreiber beheben und wie Sie verhindern, dass der Fehler zurückkommt.

Was NET::ERR_CERT_DATE_INVALID wirklich bedeutet

Jedes TLS-Zertifikat trägt zwei Zeitstempel: ein Startdatum (notBefore) und ein Enddatum (notAfter). Wenn Chrome, Edge oder ein anderer Chromium-basierter Browser eine HTTPS-Verbindung öffnet, vergleicht er diese beiden Daten mit der aktuellen Zeit, die Ihr Gerät meldet. Fällt "jetzt" außerhalb dieses Fensters, verweigert der Browser dem Zertifikat das Vertrauen und zeigt eine ganzseitige Warnung mit dem Code NET::ERR_CERT_DATE_INVALID.

Es gibt nur drei Wege, außerhalb des Fensters zu landen, und sie zeigen auf unterschiedliche Personen:

Andere Browser melden denselben Zustand unter anderen Namen. Firefox verwendet SEC_ERROR_EXPIRED_CERTIFICATE für ein abgelaufenes Zertifikat und MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE für eines, dessen Startdatum noch in der Zukunft liegt. Safari zeigt "Diese Verbindung ist nicht privat" und erwähnt den Ablauf nur in den Details. Die Lösungen unten gelten für alle.

Besucher oder Website-Betreiber? In 30 Sekunden herausfinden

Bevor Sie etwas ändern, klären Sie, welche Seite der Verbindung falsch liegt:

1. Öffnen Sie zwei oder drei andere HTTPS-Websites. Zeigen alle dieselbe Warnung, liegt das Problem an Ihrem Gerät, fast sicher an der Uhr. Schlägt nur eine Website fehl, liegt das Problem auf diesem Server.
2. Sehen Sie auf das Datum in der Taskleiste oder Menüleiste. Ein Gerät, dessen Batterie gerade getauscht wurde oder das monatelang unbenutzt war, startet oft mit einem Datum, das Jahre zurückliegt. Stimmt das Jahr nicht, haben Sie die Ursache gefunden.
3. Prüfen Sie die Website von einem anderen Gerät oder Netzwerk aus. Öffnet Ihr Smartphone über Mobilfunkdaten die Seite ohne Warnung, ist der Computer der Ausreißer.
4. Wenn die Website Ihnen gehört, prüfen Sie das Zertifikat von außen. Ein kostenloser FortifyNet-Scan liest das aktive Zertifikat aus dem Internet und zeigt die exakten notBefore- und notAfter-Daten, unabhängig von jeder Geräteuhr.

Warum dieser Fehler öfter an Ihrer Uhr liegt als an der Website

Forscher von Google und der Carnegie Mellon University haben mehr als 300 Millionen Chrome-Warnmeldungen untersucht, um herauszufinden, was sie wirklich auslöst. Das Ergebnis, veröffentlicht als "Where the Wild Warnings Are" auf der ACM CCS 2017, ist bemerkenswert: Unter Windows verursachte eine falsche Systemuhr 33,5 % aller Zertifikatswarnungen, achtmal mehr als tatsächlich abgelaufene Zertifikate. Unter macOS lag das Verhältnis bei 8,71 % zu 4,39 %, unter Android bei 8,46 % zu 2,73 %.

Anteil der Chrome-Zertifikatswarnungen, die durch eine falsche Geräteuhr beziehungsweise durch ein tatsächlich abgelaufenes oder noch nicht gültiges Serverzertifikat verursacht wurden, nach Betriebssystem. Quelle: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017, Tabelle 1.

Zwei weitere Details aus derselben Studie sind für die Lösung wichtig. Fast alle falschen Uhren lagen in der Vergangenheit, nicht in der Zukunft: Die Client-Uhr ging in 6,7 % der Meldungen mehr als 24 Stunden nach und nur in 0,05 % mehr als 24 Stunden vor. Und wenn ein Zertifikat tatsächlich abgelaufen war, lag das meist kurz zurück: 57 % der abgelaufenen Zertifikate waren weniger als 30 Tage zuvor abgelaufen, die Handschrift einer vergessenen Verlängerung, nicht einer aufgegebenen Website.

Das Chrome-Team nutzte diese Daten, um den Bildschirm "Ihre Uhr geht nach" zu bauen, den Sie vielleicht schon gesehen haben. Zunächst stützte er sich auf eine einfache Heuristik, die die Systemzeit mit dem Build-Datum des Browsers verglich und nur 68 % der Uhrfehler erkannte. Im Mai 2017 lieferte Chrome einen sicheren Zeitdienst aus, der bei einem Datumsfehler einen Google-Server nach der echten Zeit fragt, was die Erkennung auf 96 % hob. Zeigt Chrome den uhrspezifischen Bildschirm, korrigierten 53 % der Nutzer ihre Uhr, bevor sie ihn schlossen, gegenüber 3,9 % bei der generischen Warnung. Dieser Bildschirm hat absichtlich keinen Link "Trotzdem fortfahren"; der einzige Weg weiter führt über die korrigierte Uhr.

ERR_CERT_DATE_INVALID als Besucher beheben

Windows 10 und 11

Öffnen Sie die Einstellungen, gehen Sie zu Zeit und Sprache und dann zu Datum und Uhrzeit. Aktivieren Sie "Uhrzeit automatisch festlegen" und "Zeitzone automatisch festlegen" und klicken Sie unter Zusätzliche Einstellungen auf "Jetzt synchronisieren". Driftet die Uhr nach jedem Neustart erneut, ist die CMOS-Batterie auf dem Mainboard vermutlich leer; die Forscher nannten sterbende CMOS-Batterien als einen wahrscheinlichen Grund dafür, dass so viele Windows-Uhren falsch gehen. Aus einer Eingabeaufforderung mit Administratorrechten können Sie die Synchronisierung auch mit w32tm /resync erzwingen.

macOS

Öffnen Sie die Systemeinstellungen, dann Allgemein und Datum und Uhrzeit, und aktivieren Sie "Datum und Uhrzeit automatisch einstellen". Achten Sie darauf, dass auch die Zeitzone automatisch gesetzt wird. Ist die Option ausgegraut, trennen Sie zuerst jede VPN-Verbindung und versuchen Sie es erneut.

Android und iPhone

Unter Android öffnen Sie die Einstellungen, dann System und Datum und Uhrzeit, und aktivieren "Zeit automatisch einstellen" (manche Hersteller nennen es "Netzwerkzeit verwenden"). Auf iPhone und iPad gehen Sie zu Einstellungen, Allgemein, Datum und Uhrzeit und aktivieren "Automatisch einstellen". Ein Gerät, das lange ausgeschaltet war oder dessen SIM-Karte entfernt wurde, kann mit einem veralteten Datum starten.

Wenn die Uhr stimmt und der Fehler bleibt

• Alte Geräte und abgelaufene Root-Zertifikate. Zertifikaten wird über eine Kette vertraut, die in einem Root-Zertifikat auf Ihrem Gerät endet, und auch Roots laufen ab. Als die kreuzsignierte Let's-Encrypt-Kette am 30. September 2024 ablief, vertrauten Geräte mit Android 7.0 und älter Websites mit Let's-Encrypt-Zertifikaten nicht mehr, während Android 7.1 und neuer, die ISRG Root X1 bereits direkt vertrauten, nicht betroffen waren (Let's Encrypt). Auf einem Gerät, das sich nicht aktualisieren lässt, ist Firefox oft der Ausweg, weil er einen eigenen Root-Speicher mitbringt, statt den des Betriebssystems zu nutzen.
• Antivirus mit HTTPS-Prüfung. Sicherheitsprodukte, die HTTPS-Verkehr inspizieren, installieren ein eigenes Root-Zertifikat und signieren jede besuchte Website neu. Die CCS-2017-Studie führte eine Welle von Datumsfehlern auf korrekt konfigurierten Websites auf eine Antivirus-Software zurück, deren eigenes Root-Zertifikat abgelaufen war. Das vorübergehende Abschalten der HTTPS- oder "Web-Schutz"-Prüfung verrät, ob das die Ursache ist; ein Update des Produkts behebt es meist.
• Browser aktualisieren und SSL-Status löschen. Einem veralteten Browser fehlen möglicherweise neuere Root-Zertifikate. Unter Windows löscht Internetoptionen, Inhalte, "SSL-Status löschen" die zwischengespeicherten Zertifikate, die Chrome und Edge mit dem System teilen.

ERR_CERT_DATE_INVALID als Website-Betreiber beheben

Wenn Besucher den Fehler melden und die Website von mehr als einem Gerät aus fehlschlägt, ist das Zertifikat selbst das Problem. Gehen Sie diese Schritte durch:

Schritt 1: Die echten Daten lesen. Fragen Sie das Zertifikat, das der Server tatsächlich ausliefert, mit OpenSSL ab:

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

Die Ausgabe zeigt notBefore und notAfter. Liegt notAfter in der Vergangenheit, ist das Zertifikat abgelaufen. Liegt notBefore in der Zukunft, ist es noch nicht gültig.

Schritt 2: Verlängern und neu laden. Mit einem ACME-Client wie Certbot holt sudo certbot renew ein neues Zertifikat, aber der Webserver liefert das alte weiter aus dem Speicher aus, bis Sie ihn neu laden (sudo systemctl reload nginx oder das Apache-Äquivalent). Unser Leitfaden zur Verlängerung deckt alle großen Plattformen und CDNs ab.

Schritt 3: Die ganze Kette prüfen. Ihr eigenes Zertifikat kann gültig sein, während ein Zwischenzertifikat in der Kette abgelaufen ist. Installieren Sie die vollständige Kette, die die CA geliefert hat (fullchain.pem, nicht cert.pem), und prüfen Sie jeden Endpunkt, der TLS terminiert: Ursprungsserver, Load Balancer und CDN-Edge können jeweils eine andere Kopie halten.

Schritt 4: Die Falle "noch nicht gültig" vermeiden. Ein Zertifikat, das genau in der Minute seiner Ausstellung gültig wird, schlägt bei jedem Besucher fehl, dessen Uhr auch nur leicht nachgeht. Die CCS-Studie verzeichnete im September 2016 einen Anstieg uhrbedingter Warnungen unter Windows, als Google kurzfristig frisch ausgestellte Zertifikate ausrollte. Die meisten öffentlichen CAs setzen den Startzeitpunkt deshalb inzwischen leicht in die Vergangenheit; betreiben Sie eine private CA, setzen Sie notBefore mindestens eine Stunde zurück.

Schritt 5: Von außen prüfen. Zertifikate kennen keine Ausbreitungsverzögerung. Sobald der Server neu geladen ist, zeigt ein externer Scan die neuen Daten.

Warum Datumsfehler häufiger werden, nicht seltener

Die Laufzeiten von Zertifikaten schrumpfen. Nach dem CA/Browser-Forum-Beschluss SC-081v3 sank die maximale Laufzeit eines öffentlichen TLS-Zertifikats am 15. März 2026 von 398 auf 200 Tage, fällt im März 2027 auf 100 Tage und im März 2029 auf 47 Tage (CA/Browser Forum). Let's Encrypt senkt seinen Standard von 90 auf 45 Tage (Let's Encrypt). Jede Verlängerung ist eine Gelegenheit, die Frist zu verpassen, sodass eine Website, die von Hand verlängert, NET::ERR_CERT_DATE_INVALID mehrmals im Jahr begegnen wird. Die Ausstellung per ACME zu automatisieren, den Reload-Hook zu konfigurieren und den Ablauf von außen zu überwachen ist nicht mehr optional.

Verwandte Leitfäden

• "Dies ist keine sichere Verbindung": Bedeutung und Lösung beschreibt die Warnseite, auf der dieser Fehler erscheint.
• SSL-Zertifikat abgelaufen: Was passiert und wie Sie es schnell beheben geht tiefer auf die serverseitige Ursache ein.
• SSL-Zertifikat verlängern: Schritt für Schritt führt durch die Verlängerung auf allen großen Plattformen.
• ERR_CERT_AUTHORITY_INVALID: Ursachen und Lösungen behandelt die Kettenfehler, die oft auf eine hastige Verlängerung folgen.

FAQ

Ist NET::ERR_CERT_DATE_INVALID gefährlich? Meist nicht, aber Chrome kann einen harmlosen Uhrfehler nicht von einem Angriff unterscheiden und blockiert deshalb die Seite. Korrigieren Sie die Uhr oder warten Sie auf die Verlängerung der Website, statt die Warnung zu umgehen, besonders bei Bank- oder Login-Seiten.

Warum sagt Chrome auf einer Website "Ihre Uhr geht nach", auf einer anderen aber "keine sichere Verbindung"? Chrome zeigt den uhrspezifischen Bildschirm nur, wenn seine sichere Zeitprüfung bestätigt, dass Ihre Uhr falsch geht. Kann die Prüfung nicht innerhalb von drei Sekunden abgeschlossen werden oder ist die Abweichung klein, erhalten Sie die generische Warnung mit demselben Fehlercode.

Kann ich den Fehler umgehen? Bei der generischen Warnung können Sie auf Erweitert klicken und fortfahren, es sei denn, die Website nutzt HSTS, das diese Option entfernt. Auf dem Bildschirm "Ihre Uhr geht nach" gibt es absichtlich keine Abkürzung; nur die korrigierte Uhr führt weiter.

Meine Uhr stimmt und nur eine Website schlägt fehl. Was nun? Das Zertifikat der Website ist abgelaufen oder die Kette ist defekt. Nichts auf Ihrem Gerät kann das beheben; informieren Sie den Betreiber oder prüfen Sie die Zertifikatsdaten selbst mit einem externen Scan.

Wie verhindere ich das auf meiner eigenen Website? Automatisieren Sie die Verlängerung per ACME, konfigurieren Sie den Deploy-Hook, der den Server neu lädt, und überwachen Sie den Ablauf von außen mit Warnungen 30, 14 und 7 Tage vorher.

Prüfen Sie Ihre Zertifikatsdaten, bevor Ihre Besucher es tun

Eine falsche Uhr ist das Problem des Besuchers; ein abgelaufenes Zertifikat ist Ihres. Starten Sie einen kostenlosen FortifyNet-Scan, um die exakten Gültigkeitsdaten Ihres Zertifikats, die vollständige Kette, Protokollkonfiguration, Sicherheits-Header, DNS und E-Mail-Authentifizierung in etwa 60 Sekunden zu sehen. Keine Registrierung nötig.

---

Quellen: Acer et al., "Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors", ACM CCS 2017; Let's Encrypt, Shortening the Chain of Trust; CA/Browser Forum, Ballot SC-081v3; Let's Encrypt, From 90 to 45.