ERR_CERT_DATE_INVALID: vad det betyder och hur du åtgärdar det

NET::ERR_CERT_DATE_INVALID är Chromes sätt att säga att webbplatsens certifikat inte är giltigt just nu: antingen har certifikatet gått ut (eller är ännu inte giltigt), eller så går klockan fel på din egen enhet, så att ett helt korrekt certifikat ser utgånget ut. Googles egna data visar att den andra orsaken är mycket vanligare än de flesta tror: på Windows ligger en felaktig systemklocka bakom 33,5 % av alla certifikatvarningar i Chrome, mot 4,23 % för certifikat som faktiskt har gått ut (Acer m.fl., ACM CCS 2017). Den här guiden visar hur du skiljer de två fallen åt på under en minut, hur du åtgärdar vart och ett som besökare eller webbplatsägare, och hur du hindrar felet från att komma tillbaka.

Vad NET::ERR_CERT_DATE_INVALID faktiskt betyder

Varje TLS-certifikat bär två tidsstämplar: ett startdatum (notBefore) och ett slutdatum (notAfter). När Chrome, Edge eller någon annan Chromium-baserad webbläsare öppnar en HTTPS-anslutning jämför den dessa två datum med den aktuella tiden enligt din enhet. Om "nu" hamnar utanför fönstret vägrar webbläsaren att lita på certifikatet och visar en helsidesvarning med koden NET::ERR_CERT_DATE_INVALID.

Det finns bara tre sätt att hamna utanför fönstret, och de pekar på olika personer:

Andra webbläsare rapporterar samma underliggande tillstånd under andra namn. Firefox använder SEC_ERROR_EXPIRED_CERTIFICATE för ett utgånget certifikat och MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE för ett vars startdatum fortfarande ligger i framtiden. Safari visar "Den här anslutningen är inte privat" och nämner utgångsdatumet bara i detaljerna. Åtgärderna nedan gäller för alla.

Besökare eller webbplatsägare? Ta reda på det på 30 sekunder

Innan du ändrar något, ta reda på vilken sida av anslutningen som är fel:

1. Öppna två eller tre andra HTTPS-webbplatser. Om alla visar samma varning ligger problemet i din enhet, nästan säkert i klockan. Om bara en webbplats fallerar ligger problemet på den servern.
2. Titta på datumet i aktivitetsfältet eller menyraden. En enhet som just fått nytt batteri eller stått oanvänd i månader startar ofta med ett datum flera år tillbaka. Om årtalet är fel har du hittat orsaken.
3. Testa webbplatsen från en annan enhet eller ett annat nätverk. Om din mobil på mobildata öppnar sidan utan varning är det datorn som avviker.
4. Om du äger webbplatsen, kontrollera certifikatet utifrån. En gratis FortifyNet-skanning läser det aktiva certifikatet från internet och visar exakta notBefore- och notAfter-datum, oberoende av någon enhets klocka.

Därför är det oftare din klocka än webbplatsen

Forskare från Google och Carnegie Mellon studerade över 300 miljoner varningsrapporter från Chrome för att ta reda på vad som faktiskt utlöser dem. Resultatet, publicerat som "Where the Wild Warnings Are" på ACM CCS 2017, är slående: på Windows orsakade en felaktig systemklocka 33,5 % av alla certifikatvarningar, åtta gånger fler än certifikat som faktiskt hade gått ut. På macOS var fördelningen 8,71 % mot 4,39 %, och på Android 8,46 % mot 2,73 %.

Andel av Chromes certifikatvarningar som orsakas av en felaktig enhetsklocka respektive ett faktiskt utgånget eller ännu ogiltigt servercertifikat, per operativsystem. Källa: Acer m.fl., "Where the Wild Warnings Are", ACM CCS 2017, tabell 1.

Två detaljer till från samma studie spelar roll för åtgärden. Nästan alla felaktiga klockor låg i det förflutna, inte i framtiden: klientklockan gick mer än 24 timmar efter i 6,7 % av rapporterna och mer än 24 timmar före i bara 0,05 %. Och när ett certifikat faktiskt hade gått ut var det oftast nyligen: 57 % av de utgångna certifikaten hade gått ut för mindre än 30 dagar sedan, vilket är signaturen för en förnyelse som någon glömde, inte en övergiven webbplats.

Chrome-teamet använde dessa data för att bygga skärmen "Din klocka går efter" som du kanske har sett. Först byggde den på en enkel heuristik som jämförde systemtiden med webbläsarens byggdatum, vilket bara fångade 68 % av klockfelen. I maj 2017 lanserade Chrome en säker tidstjänst som frågar en Google-server om den verkliga tiden när ett datumfel upptäcks, vilket höjde träffsäkerheten till 96 %. När Chrome visar den klockspecifika skärmen rättade 53 % av användarna sin klocka innan de stängde den, jämfört med 3,9 % när de bara såg den generiska varningen. Skärmen saknar avsiktligt länken "fortsätt ändå", så enda vägen förbi är att rätta klockan.

Åtgärda ERR_CERT_DATE_INVALID som besökare

Windows 10 och 11

Öppna Inställningar, gå till Tid och språk och sedan Datum och tid. Slå på "Ställ in tid automatiskt" och "Ställ in tidszon automatiskt" och klicka sedan på "Synkronisera nu" under Ytterligare inställningar. Om klockan driver igen efter varje omstart är CMOS-batteriet på moderkortet troligen slut; forskarna pekade på döende CMOS-batterier som en trolig förklaring till att så många Windows-klockor går fel. Från en kommandotolk med administratörsrättigheter kan du också tvinga fram en synkronisering med w32tm /resync.

macOS

Öppna Systeminställningar, sedan Allmänt och Datum och tid, och slå på "Ställ in datum och tid automatiskt". Se till att även tidszonen ställs in automatiskt. Om alternativet är nedtonat, koppla först bort eventuell VPN och försök igen.

Android och iPhone

På Android öppnar du Inställningar, sedan System och Datum och tid, och aktiverar "Ställ in tid automatiskt" (vissa tillverkare kallar det "Använd nätverkets tid"). På iPhone och iPad går du till Inställningar, Allmänt, Datum och tid och aktiverar "Ställ in automatiskt". En enhet som varit avstängd länge eller fått SIM-kortet urtaget kan starta med ett gammalt datum.

Om klockan är rätt och felet kvarstår

• Gamla enheter och utgångna rotcertifikat. Certifikat betros via en kedja som slutar i ett rotcertifikat på din enhet, och även rötter går ut. När Let's Encrypts korssignerade kedja gick ut den 30 september 2024 slutade enheter med Android 7.0 och äldre att lita på webbplatser med Let's Encrypt-certifikat, medan Android 7.1 och nyare, som redan litade direkt på ISRG Root X1, inte påverkades (Let's Encrypt). På en enhet som inte kan uppdateras är Firefox ofta lösningen, eftersom den har ett eget rotlager i stället för att använda operativsystemets.
• Antivirus med HTTPS-skanning. Säkerhetsprodukter som inspekterar HTTPS-trafik installerar ett eget rotcertifikat och signerar om varje webbplats du besöker. CCS 2017-studien spårade en våg av datumfel på korrekt konfigurerade webbplatser till antivirusprogram vars eget rotcertifikat hade gått ut. Att tillfälligt stänga av HTTPS- eller "webbsköld"-skanningen avslöjar om det är orsaken; en uppdatering av produkten brukar lösa det.
• Uppdatera webbläsaren och rensa SSL-tillståndet. En föråldrad webbläsare kan sakna nyare rotcertifikat. På Windows rensar Internetalternativ, Innehåll, "Rensa SSL-tillstånd" de cachade certifikat som Chrome och Edge delar med systemet.

Åtgärda ERR_CERT_DATE_INVALID som webbplatsägare

Om besökare rapporterar felet och webbplatsen fallerar från mer än en enhet är certifikatet självt problemet. Gå igenom dessa steg:

Steg 1: läs de verkliga datumen. Fråga efter certifikatet som servern faktiskt levererar med OpenSSL:

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

Utdata skriver ut notBefore och notAfter. Om notAfter ligger i det förflutna har certifikatet gått ut. Om notBefore ligger i framtiden är det ännu inte giltigt.

Steg 2: förnya och ladda om. Med en ACME-klient som Certbot hämtar sudo certbot renew ett nytt certifikat, men webbservern fortsätter att leverera det gamla från minnet tills du laddar om den (sudo systemctl reload nginx eller motsvarande för Apache). Vår guide till förnyelse täcker alla större plattformar och CDN:er.

Steg 3: kontrollera hela kedjan. Ditt eget certifikat kan vara giltigt medan ett mellanliggande certifikat i kedjan har gått ut. Installera hela kedjan som utfärdaren gav dig (fullchain.pem, inte cert.pem), och kontrollera varje ändpunkt som terminerar TLS: ursprungsservern, lastbalanseraren och CDN-kanten kan alla ha varsin kopia.

Steg 4: se upp för fällan "ännu inte giltigt". Ett certifikat som blir giltigt exakt den minut det utfärdas fallerar för varje besökare vars klocka går ens lite efter. CCS-studien registrerade en topp av klockrelaterade varningar på Windows i september 2016 när Google rullade ut nyutfärdade certifikat med kort varsel. De flesta publika utfärdare bakdaterar numera starttiden något av just den anledningen, men om du driver en egen CA bör du sätta notBefore minst en timme bakåt.

Steg 5: verifiera utifrån. Certifikat har ingen spridningsfördröjning. Så snart servern laddats om visar en extern skanning de nya datumen.

Därför blir datumfel vanligare, inte ovanligare

Certifikatens livslängd krymper. Enligt CA/Browser Forums omröstning SC-081v3 sjönk den maximala livslängden för ett publikt TLS-certifikat från 398 till 200 dagar den 15 mars 2026, faller till 100 dagar i mars 2027 och till 47 dagar i mars 2029 (CA/Browser Forum). Let's Encrypt flyttar sin standard från 90 till 45 dagar (Let's Encrypt). Varje förnyelse är ett tillfälle att missa deadline, så en webbplats som förnyar för hand kommer att möta NET::ERR_CERT_DATE_INVALID flera gånger om året. Att automatisera utfärdandet med ACME, konfigurera omladdningskroken och övervaka utgångsdatum utifrån är inte längre valfritt.

Relaterade guider

• "Din anslutning är inte privat": vad det betyder och hur du åtgärdar det beskriver varningssidan som felet visas på.
• SSL-certifikatet har gått ut: vad som händer och hur du snabbt åtgärdar det går djupare in på orsaken på serversidan.
• Så förnyar du ett SSL-certifikat går igenom förnyelse på alla större plattformar.
• ERR_CERT_AUTHORITY_INVALID: orsaker och åtgärder hanterar kedjefelen som ofta följer på en stressad förnyelse.

Vanliga frågor

Är NET::ERR_CERT_DATE_INVALID farligt? Oftast inte, men Chrome kan inte skilja ett ofarligt klockfel från en attack, så sidan blockeras. Rätta klockan eller vänta på att webbplatsen förnyar i stället för att klicka dig förbi, särskilt på bank- och inloggningssidor.

Varför säger Chrome "Din klocka går efter" på en webbplats men "anslutningen är inte privat" på en annan? Chrome visar bara den klockspecifika skärmen när dess säkra tidskontroll bekräftar att klockan går fel. Om kontrollen inte hinner slutföras inom tre sekunder, eller skillnaden är liten, får du den generiska varningen med samma felkod.

Kan jag kringgå felet? På den generiska varningen kan du klicka på Avancerat och fortsätta, om inte webbplatsen använder HSTS, som tar bort det alternativet. På skärmen "Din klocka går efter" finns avsiktligt ingen genväg; att rätta klockan är enda vägen förbi.

Min klocka är rätt och bara en webbplats fallerar. Vad nu? Webbplatsens certifikat har gått ut eller kedjan är trasig. Inget på din enhet kan lösa det; meddela webbplatsägaren, eller kontrollera certifikatets datum själv med en extern skanning.

Hur hindrar jag detta på min egen webbplats? Automatisera förnyelsen med ACME, konfigurera driftsättningskroken som laddar om servern, och övervaka utgångsdatum utifrån med larm 30, 14 och 7 dagar i förväg.

Kontrollera dina certifikatdatum innan besökarna gör det

En felaktig klocka är besökarens problem; ett utgånget certifikat är ditt. Kör en gratis FortifyNet-skanning och se certifikatets exakta giltighetsdatum, hela kedjan, protokollkonfiguration, säkerhetsheaders, DNS och e-postautentisering på ungefär 60 sekunder. Ingen registrering krävs.

---

Källor: Acer m.fl., "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.