ERR_CERT_DATE_INVALID: mitä se tarkoittaa ja miten korjaat sen

NET::ERR_CERT_DATE_INVALID on Chromen tapa kertoa, ettei sivuston varmenne ole voimassa juuri nyt: joko varmenne on vanhentunut (tai ei ole vielä voimassa), tai oman laitteesi kello on väärässä, jolloin täysin kelvollinen varmenne näyttää vanhentuneelta. Googlen omat tiedot osoittavat, että jälkimmäinen syy on paljon yleisempi kuin useimmat luulevat: Windowsissa väärässä oleva järjestelmän kello on 33,5 prosentin takana kaikista Chromen varmennevaroituksista, kun oikeasti vanhentuneiden varmenteiden osuus on 4,23 prosenttia (Acer ym., ACM CCS 2017). Tämä opas näyttää, miten erotat tapaukset toisistaan alle minuutissa, miten korjaat kumman tahansa kävijänä tai sivuston omistajana, ja miten estät virheen palaamisen.

Mitä NET::ERR_CERT_DATE_INVALID oikeasti tarkoittaa

Jokaisessa TLS-varmenteessa on kaksi aikaleimaa: alkupäivä (notBefore) ja loppupäivä (notAfter). Kun Chrome, Edge tai mikä tahansa Chromium-pohjainen selain avaa HTTPS-yhteyden, se vertaa näitä kahta päivämäärää laitteesi ilmoittamaan nykyhetkeen. Jos "nyt" osuu ikkunan ulkopuolelle, selain kieltäytyy luottamasta varmenteeseen ja näyttää koko sivun varoituksen koodilla NET::ERR_CERT_DATE_INVALID.

Ikkunan ulkopuolelle voi päätyä vain kolmella tavalla, ja ne osoittavat eri henkilöihin:

Muut selaimet raportoivat saman tilan eri nimillä. Firefox käyttää koodia SEC_ERROR_EXPIRED_CERTIFICATE vanhentuneelle varmenteelle ja MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE varmenteelle, jonka alkupäivä on vielä tulevaisuudessa. Safari näyttää "Tämä yhteys ei ole yksityinen" ja mainitsee vanhentumisen vain lisätiedoissa. Alla olevat korjaukset pätevät kaikkiin.

Kävijä vai sivuston omistaja? Selvitä 30 sekunnissa

Ennen kuin muutat mitään, selvitä kumpi yhteyden pää on väärässä:

1. Avaa kaksi tai kolme muuta HTTPS-sivustoa. Jos kaikki näyttävät saman varoituksen, vika on laitteessasi, lähes varmasti sen kellossa. Jos vain yksi sivusto epäonnistuu, vika on sillä palvelimella.
2. Katso päivämäärä tehtäväpalkista tai valikkopalkista. Laite, jonka akku on juuri vaihdettu tai joka on ollut kuukausia käyttämättä, käynnistyy usein vuosia vanhalla päivämäärällä. Jos vuosi on väärin, syy on löytynyt.
3. Testaa sivusto toisella laitteella tai toisessa verkossa. Jos puhelimesi avaa sivuston mobiilidatalla ilman varoitusta, tietokoneesi on poikkeus.
4. Jos omistat sivuston, tarkista varmenne ulkopuolelta. Ilmainen FortifyNet-skannaus lukee käytössä olevan varmenteen internetistä ja näyttää sen tarkat notBefore- ja notAfter-päivämäärät riippumatta minkään laitteen kellosta.

Miksi syy on useammin kellosi kuin sivusto

Googlen ja Carnegie Mellonin tutkijat kävivät läpi yli 300 miljoonaa Chromen varmennevaroitusraporttia selvittääkseen, mikä ne todella laukaisee. ACM CCS 2017 -konferenssissa julkaistu tulos "Where the Wild Warnings Are" on hätkähdyttävä: Windowsissa väärässä oleva järjestelmän kello aiheutti 33,5 prosenttia kaikista varmennevaroituksista, kahdeksan kertaa enemmän kuin oikeasti vanhentuneet varmenteet. macOS:ssä jako oli 8,71 prosenttia vastaan 4,39 prosenttia ja Androidissa 8,46 prosenttia vastaan 2,73 prosenttia.

Osuus Chromen varmennevaroitusraporteista, joiden syynä oli väärässä oleva laitteen kello tai oikeasti vanhentunut tai ei vielä voimassa oleva palvelinvarmenne, käyttöjärjestelmittäin. Lähde: Acer ym., "Where the Wild Warnings Are", ACM CCS 2017, taulukko 1.

Kaksi muuta saman tutkimuksen yksityiskohtaa vaikuttavat korjaukseen. Lähes kaikki väärässä olleet kellot olivat menneisyydessä, eivät tulevaisuudessa: asiakkaan kello oli yli 24 tuntia jäljessä 6,7 prosentissa raporteista ja yli 24 tuntia edellä vain 0,05 prosentissa. Ja kun varmenne oli oikeasti vanhentunut, se oli yleensä tapahtunut hiljattain: 57 prosenttia vanhentuneista varmenteista oli vanhentunut alle 30 päivää aiemmin, mikä on unohtuneen uusimisen tunnusmerkki, ei hylätyn sivuston.

Chrome-tiimi rakensi näiden tietojen pohjalta "Kellosi on jäljessä" -näkymän, jonka olet ehkä nähnyt. Aluksi se perustui yksinkertaiseen heuristiikkaan, joka vertasi järjestelmän aikaa selaimen käännöspäivään ja tunnisti vain 68 prosenttia kellovirheistä. Toukokuussa 2017 Chrome otti käyttöön turvallisen aikapalvelun, joka päivämäärävirheen kohdatessaan kysyy oikean ajan Googlen palvelimelta, mikä nosti tunnistuksen 96 prosenttiin. Kun Chrome näyttää kellokohtaisen näkymän, 53 prosenttia käyttäjistä korjasi kellonsa ennen sen sulkemista, kun yleisen varoituksen kohdalla osuus oli 3,9 prosenttia. Näkymässä ei tarkoituksella ole "jatka silti" -linkkiä, joten ainoa tie eteenpäin on kellon korjaaminen.

Korjaa ERR_CERT_DATE_INVALID kävijänä

Windows 10 ja 11

Avaa Asetukset, siirry kohtaan Aika ja kieli ja sitten Päivämäärä ja aika. Ota käyttöön "Aseta aika automaattisesti" ja "Aseta aikavyöhyke automaattisesti" ja napsauta Lisäasetukset-kohdassa "Synkronoi nyt". Jos kello lähtee jälleen väärään jokaisen uudelleenkäynnistyksen jälkeen, emolevyn CMOS-paristo on todennäköisesti tyhjä; tutkijat nimesivät hiipuvat CMOS-paristot yhdeksi todennäköiseksi syyksi siihen, miksi niin monen Windows-koneen kello on väärässä. Järjestelmänvalvojan komentokehotteesta voit myös pakottaa synkronoinnin komennolla w32tm /resync.

macOS

Avaa Järjestelmäasetukset, sitten Yleiset ja Päivämäärä ja aika, ja ota käyttöön "Aseta päivämäärä ja aika automaattisesti". Varmista, että myös aikavyöhyke asetetaan automaattisesti. Jos vaihtoehto on harmaana, katkaise ensin mahdollinen VPN-yhteys ja yritä uudelleen.

Android ja iPhone

Androidissa avaa Asetukset, sitten Järjestelmä ja Päivämäärä ja aika, ja ota käyttöön "Aseta aika automaattisesti" (jotkin valmistajat kutsuvat sitä nimellä "Käytä verkon aikaa"). iPhonessa ja iPadissa siirry kohtaan Asetukset, Yleiset, Päivämäärä ja aika ja ota käyttöön "Aseta automaattisesti". Pitkään sammutettuna ollut tai SIM-kortitta jäänyt laite voi käynnistyä vanhentuneella päivämäärällä.

Jos kello on oikeassa ja virhe jatkuu

• Vanhat laitteet ja vanhentuneet juurivarmenteet. Varmenteisiin luotetaan ketjun kautta, joka päättyy laitteesi juurivarmenteeseen, ja myös juuret vanhenevat. Kun Let's Encryptin ristiinallekirjoitettu ketju vanheni 30. syyskuuta 2024, Android 7.0:aa ja vanhempaa käyttävät laitteet lakkasivat luottamasta Let's Encrypt -varmenteita käyttäviin sivustoihin, kun taas Android 7.1 ja uudemmat, jotka luottivat jo suoraan ISRG Root X1 -juureen, eivät kärsineet (Let's Encrypt). Laitteella, jota ei voi päivittää, Firefox on usein kiertotie, koska se tuo mukanaan oman juurivarastonsa käyttöjärjestelmän varaston sijaan.
• Virustorjunta ja HTTPS-tarkastus. HTTPS-liikennettä tarkastavat tietoturvatuotteet asentavat oman juurivarmenteensa ja allekirjoittavat uudelleen jokaisen vierailemasi sivuston. CCS 2017 -tutkimus jäljitti aallon päivämäärävirheitä oikein määritetyillä sivustoilla virustorjuntaohjelmaan, jonka oma juurivarmenne oli vanhentunut. HTTPS- tai "verkkosuoja"-tarkastuksen tilapäinen poistaminen käytöstä kertoo, onko se syynä; tuotteen päivitys yleensä korjaa asian.
• Päivitä selain ja tyhjennä SSL-tila. Vanhentuneelta selaimelta voivat puuttua uudemmat juurivarmenteet. Windowsissa Internet-asetukset, Sisältö, "Tyhjennä SSL-tila" poistaa välimuistista varmenteet, jotka Chrome ja Edge jakavat järjestelmän kanssa.

Korjaa ERR_CERT_DATE_INVALID sivuston omistajana

Jos kävijät raportoivat virheestä ja sivusto epäonnistuu useammalta kuin yhdeltä laitteelta, ongelma on itse varmenteessa. Käy läpi nämä vaiheet:

Vaihe 1: lue todelliset päivämäärät. Kysy palvelimen oikeasti tarjoilema varmenne OpenSSL:llä:

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

Tuloste näyttää arvot notBefore ja notAfter. Jos notAfter on menneisyydessä, varmenne on vanhentunut. Jos notBefore on tulevaisuudessa, se ei ole vielä voimassa.

Vaihe 2: uusi ja lataa uudelleen. ACME-asiakkaalla kuten Certbotilla sudo certbot renew hakee uuden varmenteen, mutta web-palvelin tarjoilee vanhaa muistista, kunnes lataat sen uudelleen (sudo systemctl reload nginx tai Apachen vastaava). Uusimisoppaamme kattaa kaikki suuret alustat ja CDN-palvelut.

Vaihe 3: tarkista koko ketju. Oma varmenteesi voi olla voimassa, vaikka ketjun välivarmenne on vanhentunut. Asenna varmentajan toimittama koko ketju (fullchain.pem, ei cert.pem) ja tarkista jokainen TLS:n päättävä päätepiste: alkuperäpalvelimella, kuormantasaajalla ja CDN-reunalla voi kullakin olla eri kopio.

Vaihe 4: varo "ei vielä voimassa" -ansaa. Varmenne, joka tulee voimaan täsmälleen myöntämisminuutillaan, epäonnistuu jokaisella kävijällä, jonka kello on edes hieman jäljessä. CCS-tutkimus kirjasi piikin kelloon liittyvissä varoituksissa Windowsissa syyskuussa 2016, kun Google otti lyhyellä varoitusajalla käyttöön vastamyönnettyjä varmenteita. Useimmat julkiset varmentajat siirtävät nykyään alkuajan hieman menneisyyteen juuri tästä syystä, mutta jos ylläpidät omaa varmentajaa, aseta notBefore vähintään tunti taaksepäin.

Vaihe 5: varmista ulkopuolelta. Varmenteilla ei ole leviämisviivettä. Heti kun palvelin on ladattu uudelleen, ulkoinen skannaus näyttää uudet päivämäärät.

Miksi päivämäärävirheet yleistyvät, eivät harvene

Varmenteiden elinkaaret lyhenevät. CA/Browser Forumin äänestyksen SC-081v3 mukaan julkisen TLS-varmenteen enimmäisikä laski 398 päivästä 200 päivään 15. maaliskuuta 2026, putoaa 100 päivään maaliskuussa 2027 ja 47 päivään maaliskuussa 2029 (CA/Browser Forum). Let's Encrypt siirtää oletusarvonsa 90 päivästä 45 päivään (Let's Encrypt). Jokainen uusiminen on tilaisuus myöhästyä määräajasta, joten käsin uusiva sivusto kohtaa NET::ERR_CERT_DATE_INVALID-virheen useita kertoja vuodessa. Myöntämisen automatisointi ACME:lla, uudelleenlatauskoukun määrittäminen ja vanhenemisen valvonta ulkopuolelta eivät ole enää valinnaisia.

Aiheeseen liittyvät oppaat

• "Yhteys ei ole yksityinen": mitä se tarkoittaa ja miten se korjataan kuvaa varoitussivun, jolla tämä virhe näkyy.
• SSL-varmenne vanhentunut: mitä tapahtuu ja miten korjaat sen nopeasti syventyy palvelinpuolen syyhyn.
• Näin uusit SSL-varmenteen käy uusimisen läpi kaikilla suurilla alustoilla.
• ERR_CERT_AUTHORITY_INVALID: syyt ja korjaukset käsittelee ketjuvirheitä, jotka usein seuraavat kiireistä uusimista.

Usein kysytyt kysymykset

Onko NET::ERR_CERT_DATE_INVALID vaarallinen? Yleensä ei, mutta Chrome ei pysty erottamaan harmitonta kellovirhettä hyökkäyksestä, joten se estää sivun. Korjaa kello tai odota sivuston uusimista sen sijaan, että ohitat varoituksen, etenkin pankki- ja kirjautumissivuilla.

Miksi Chrome sanoo yhdellä sivustolla "Kellosi on jäljessä" mutta toisella "yhteys ei ole yksityinen"? Chrome näyttää kellokohtaisen näkymän vain, kun sen turvallinen aikatarkistus vahvistaa kellosi olevan väärässä. Jos tarkistus ei valmistu kolmessa sekunnissa tai ero on pieni, saat yleisen varoituksen samalla virhekoodilla.

Voinko ohittaa virheen? Yleisessä varoituksessa voit napsauttaa Lisäasetukset ja jatkaa, ellei sivusto käytä HSTS:ää, joka poistaa tämän vaihtoehdon. "Kellosi on jäljessä" -näkymässä ei tarkoituksella ole ohitusta; kellon korjaaminen on ainoa tie eteenpäin.

Kelloni on oikeassa ja vain yksi sivusto epäonnistuu. Mitä nyt? Sivuston varmenne on vanhentunut tai sen ketju on rikki. Mikään laitteellasi ei korjaa sitä; ilmoita sivuston omistajalle tai tarkista varmenteen päivämäärät itse ulkoisella skannauksella.

Miten estän tämän omalla sivustollani? Automatisoi uusiminen ACME:lla, määritä käyttöönottokoukku, joka lataa palvelimen uudelleen, ja valvo vanhenemista ulkopuolelta hälytyksillä 30, 14 ja 7 päivää ennen.

Tarkista varmenteesi päivämäärät ennen kävijöitäsi

Väärässä oleva kello on kävijän ongelma; vanhentunut varmenne on sinun. Aja ilmainen FortifyNet-skannaus ja näe varmenteesi tarkat voimassaolopäivät, koko ketju, protokollamääritykset, tietoturvaotsakkeet, DNS ja sähköpostin todennus noin 60 sekunnissa. Ei rekisteröitymistä.

---

Lähteet: Acer ym., "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.