ERR_CERT_DATE_INVALID: verlopen certificaat of verkeerde klok, en de oplossing

Wat ERR_CERT_DATE_INVALID betekent

Elk TLS-certificaat draagt twee tijdstempels, "Valid from" en "Valid to" (de X.509-velden notBefore en notAfter). Tijdens de handshake vergelijkt de browser die tijdstempels met zijn eigen idee van de huidige tijd. Is het venster van het certificaat gesloten, of nog niet geopend, of plaatst de klok van de browser "nu" om welke reden dan ook buiten dat venster, dan stopt de handshake voordat de browser zelfs maar controleert wie het certificaat heeft uitgegeven. Chrome en Edge tonen NET::ERR_CERT_DATE_INVALID. Firefox toont SEC_ERROR_EXPIRED_CERTIFICATE voor het verlopen geval. Safari toont "This certificate has expired" of "This certificate is not yet valid."

Twee losse situaties leveren precies dezelfde waarschuwing op, en de browser kan u niet vertellen welke van de twee het is: het certificaat is echt verlopen of nog niet geldig, of het certificaat is prima en de klok van de client staat verkeerd. Beide falen dezelfde vergelijking.

Hoe de fout verschijnt

In een browser laadt de pagina nooit en verschijnt er een volledige tabwaarschuwing in plaats van een slotje-foutpictogram op een verder geladen pagina. Klikken op "Advanced" toont de specifieke reden en, in Chrome, de eigen datums van het certificaat.

Vanaf de commandoregel rapporteert curl dezelfde storing met meer precisie:

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

Een nog-niet-geldig certificaat levert een vergelijkbare regel op met de tekst "certificate is not yet valid." Server- en applicatielogs aan de kant van de sitebeheerder tonen voor deze fout meestal helemaal niets, omdat de TLS-handshake al faalt voordat er enig HTTP-verzoek wordt gelogd. Het bewijs zit in het certificaat en de client, niet in het toegangslog van de webserver.

Wat ERR_CERT_DATE_INVALID veroorzaakt

• Het certificaat is verlopen. Vernieuwing gebeurde niet voor de "Valid to"-datum, meestal omdat een geautomatiseerde vernieuwingstaak stilzwijgend is gestopt.
• Het certificaat is nog niet geldig. Minder vaak: een certificaat werd uitgegeven of opnieuw uitgegeven met een "Valid from"-datum die iets in de toekomst ligt, of een server begon een nieuw certificaat te serveren voordat het venster ervan geopend was.
• Een tussenliggend certificaat in de keten is verlopen. Het eindcertificaat kan volledig actueel zijn terwijl een tussencertificaat dat de server nog steeds meestuurt zijn eigen vervaldatum is gepasseerd, en sommige clients controleren elk certificaat in de keten.
• De klok van het apparaat van de bezoeker staat verkeerd. Een laptop die maanden uit is geweest, een telefoon met automatische tijdsynchronisatie uitgeschakeld, of een apparaat met een dode CMOS-batterij kan opstarten met een datum die jaren afwijkt in beide richtingen.
• Een virtuele machine of container met een verouderde klok. VM's die een snapshot kregen, gekloond werden, of hervat werden na een lange pauze, starten vaak op met een klok die nog niet is bijgewerkt totdat een NTP-synchronisatie voltooid is.
• Een verkeerd geconfigureerde tijdzone of een handmatig ingestelde onjuiste datum, door een gebruiker of een kioskachtig apparaat dat geen eigen tijdbron heeft.

Hoe u vaststelt wiens fout het is

De snelste manier om dit te scheiden is het certificaat te controleren vanaf iets anders dan het getroffen apparaat. Laadt een tweede apparaat met een aantoonbaar correcte klok, of een meetpunt buiten uw eigen netwerk, de site zonder datumwaarschuwing, dan is het certificaat in orde en zit het probleem lokaal bij de klok van dat ene apparaat. Rapporteert elk uitkijkpunt dezelfde verlopen of nog-niet-geldige datum, dan verdient het certificaat zelf aandacht. Een SSL-controle vanaf meerdere locaties tegelijk laten draaien beslecht dit in één stap in plaats van een tweede laptop te lenen om mee te testen.

Hoe u ERR_CERT_DATE_INVALID oplost

Bent u de bezoeker

1. Controleer eerst de datum, tijd en tijdzone van uw apparaat. Dit is verreweg de meest voorkomende zelf veroorzaakte oorzaak, vooral op Android-apparaten met automatische tijdsynchronisatie uitgeschakeld, oudere laptops die ongebruikt hebben gestaan, en machines met een falende CMOS-batterij. Zet "Automatisch tijd instellen" aan en bevestig dat het jaar klopt, niet alleen de wijzerplaat.
2. Probeer de site op een ander apparaat of netwerk. Laadt hij daar wel probleemloos, dan ligt de oorzaak bij de klok van uw oorspronkelijke apparaat (of een captive portal die de verbinding onderschept), niet bij de site.
3. Lees de daadwerkelijke datums op de waarschuwingspagina voordat u iets anders doet. Het "Advanced"-paneel van Chrome en de certificaatweergave tonen beide "Valid from" en "Valid to" in gewone tekst, wat u meteen vertelt of het certificaat verlopen is, nog niet geldig is, of dat uw eigen klok de uitzondering is.
4. Klik niet door bij een certificaat dat werkelijk verlopen is op een site die iets gevoeligs afhandelt. Zodra de klok is gecorrigeerd, laadt u opnieuw; probeer niet gewoon opnieuw in dezelfde kapotte toestand.

Beheert u de site

1. Lees de eigen datums van het certificaat rechtstreeks af in plaats van te vertrouwen op een agendaherinnering:

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

   Dit toont notBefore en notAfter rechtstreeks van het certificaat dat de server nu daadwerkelijk aanbiedt.
2. Gebruikt u Let's Encrypt, controleer dan de vernieuwingstaak, niet alleen het certificaat. Let's Encrypt-certificaten gaan per ontwerp 90 dagen mee en vernieuwen automatisch rond de dag-30-markering, maar de automatisering kan wekenlang stilzwijgend falen voordat iemand het merkt: systemctl status certbot.timer (of het equivalente cron-item) bevestigt dat de timer nog is ingeschakeld en afgaat, en certbot renew --dry-run doorloopt het vernieuwingspad zonder iets daadwerkelijk te wijzigen. Lees /var/log/letsencrypt/letsencrypt.log voor de daadwerkelijke storing, die vrijwel altijd een van deze is: een DNS-01-challenge waarvan de API-credentials verlopen zijn, een firewallwijziging die het HTTP-01-challengepad blokkeert, of een limiet van Let's Encrypt die is geraakt tijdens herhaald troubleshooten.
3. Controleer de volledige keten die uw server verstuurt, niet alleen het eindcertificaat:

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

   Sommige servers blijven een oud tussencertificaat vanaf schijf serveren nadat het eindcertificaat is vervangen. Elk certificaat in de keten heeft een actueel geldigheidsvenster nodig, aangezien sommige clients het hele pad valideren.
4. Verifieer de eigen systeemklok van de server. Een server met de verkeerde tijd kan geautomatiseerde vernieuwingen uitgeven met een onjuiste "Valid from"-datum, en kan ook zijn eigen OCSP- en handshakevalidatie laten falen, los van het certificaat. Bevestig dat NTP draait en gesynchroniseerd is.
5. Vernieuw of geef het certificaat opnieuw uit, en herlaad daarna de webserver. Een vernieuwd certificaat op schijf doet niets totdat het proces dat TLS serveert het oppikt: nginx -s reload, systemctl reload apache2, of het equivalent voor een loadbalancer of CDN-edge met een eigen kopie.
6. Bevestig de oplossing vanaf buiten uw eigen infrastructuur na het herladen, aangezien een browser of besturingssysteem op uw machine het oude certificaat een sessie lang kan cachen.

Hoe u ERR_CERT_DATE_INVALID voorkomt

Een verlopend certificaat geeft geen enkele waarschuwing aan wie er niet specifiek op let: de site blijft werken tot precies de seconde dat het venster sluit, en dan ziet elke bezoeker tegelijk dezelfde waarschuwing. Een geplande SSL-controle die de datums van het certificaat afleest en waarschuwt vóór de deadline, in plaats van nadat bezoekers een kapotte site beginnen te melden, verandert een stille vernieuwingsstoring in een oplosbaar ticket met dagen voorsprong. HostTracker's SSL- en domeinvervalcontroles volgen het daadwerkelijke geldigheidsvenster van het certificaat vanaf buiten uw infrastructuur en waarschuwen via e-mail, sms, spraakoproep, Slack, Telegram en meer voordat het verloopt; voer er nu een uit met de SSL-certificaatcontrole. De bijbehorende handleiding over het controleren van het verlopen van SSL-certificaten behandelt dat opzetten in meer detail.

Gerelateerde fouten

• ERR_CERT_AUTHORITY_INVALID - de datums van het certificaat zijn prima, maar de browser vertrouwt niet wie het heeft uitgegeven.
• ERR_CERT_COMMON_NAME_INVALID - het certificaat is geldig en vertrouwd, maar werd niet uitgegeven voor de hostnaam in de adresbalk.
• ERR_SSL_PROTOCOL_ERROR - de handshake mislukte voordat er zelfs maar een certificaat werd bereikt, meestal een mismatch in TLS-versie, poort, of configuratie.

Veelgestelde vragen

Is het veilig om door een ERR_CERT_DATE_INVALID-waarschuwing heen te klikken?

Alleen als u zeker weet dat de oorzaak de klok van uw eigen apparaat is, aangezien u dat onafhankelijk kunt verifiëren. Is het certificaat zelf werkelijk verlopen, dan verwijdert doorklikken de ene controle die bevestigt dat u praat met de echte server via een versleuteld, geverifieerd kanaal.

Waarom gebeurt dit vlak na een reset of het uitpakken van een apparaat?

Een fabrieksreset of een lang ongebruikt apparaat start vaak op met de interne klok teruggezet naar een standaarddatum, soms jaren in het verleden. Totdat het verbinding maakt met internet en de tijd automatisch synchroniseert, kan elke HTTPS-site falen met een datumfout, niet alleen één.

Lost het wissen van mijn browsercache ERR_CERT_DATE_INVALID op?

Zelden. Deze fout is een live vergelijking tussen de datums van het certificaat en de huidige klok, vers geëvalueerd bij elke verbinding, dus een cachewis verandert de uitkomst niet. De klok of het certificaat corrigeren wel.

Waarom verliep mijn Let's Encrypt-certificaat zonder enige waarschuwing?

Omdat vernieuwing bedoeld is om volledig automatisch te gaan, controleert niemand het handmatig, dus kan een kapotte cronjob, een verlopen DNS-API-credential, of een gewijzigde firewallregel de vernieuwingen wekenlang stilzwijgend stopzetten zonder zichtbaar symptoom totdat het certificaat daadwerkelijk verloopt.

Kan een CDN of loadbalancer veranderen wat bezoekers zien bij deze fout?

Ja. Houdt de CDN-edge een verlopen certificaat aan, dan ziet elke bezoeker de fout ongeacht welk certificaat de origin-server heeft, dus controleer welke laag ook echt TLS afsluit voor het verzoek dat mislukte.

Hoe vaak moet ik de vervaldatum van mijn certificaat controleren?

Een dagelijkse geautomatiseerde controle is genoeg om een vernieuwingsstoring op te vangen met weken voorsprong, aangezien Let's Encrypt-certificaten 90 dagen geldig zijn en de meeste andere certificaten 90 dagen tot een jaar meegaan.