ERR_CERT_DATE_INVALID: vypršelý certifikát nebo špatné hodiny

Co znamená ERR_CERT_DATE_INVALID

Každý TLS certifikát nese dva časové údaje, "Valid from" a "Valid to" (pole X.509 notBefore a notAfter). Během handshake prohlížeč porovná tyto časové údaje s vlastní představou o aktuálním čase. Pokud se okno platnosti certifikátu už uzavřelo, ještě se neotevřelo, nebo hodiny prohlížeče z jakéhokoli důvodu umístí "teď" mimo toto okno, handshake se zastaví dřív, než se prohlížeč vůbec dostane ke kontrole, kdo certifikát vydal. Chrome a Edge zobrazí NET::ERR_CERT_DATE_INVALID. Firefox zobrazí u vypršelého případu SEC_ERROR_EXPIRED_CERTIFICATE. Safari zobrazí "This certificate has expired" nebo "This certificate is not yet valid."

Dvě odlišné situace vyprodukují identické varování a prohlížeč vám neřekne, o kterou jde: certifikátu skutečně vypršela platnost nebo ještě není platný, nebo je certifikát v pořádku a hodiny klienta se pletou. Obě selžou na stejném porovnání.

Jak se chyba projevuje

V prohlížeči se stránka vůbec nenačte a místo ikony chyby zámku na jinak načtené stránce se objeví varování přes celou záložku. Kliknutí na "Advanced" ukáže konkrétní důvod a v Chrome i vlastní data certifikátu.

Z příkazové řádky curl hlásí stejné selhání přesněji:

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

Ještě neplatný certifikát vyprodukuje podobný řádek se zněním "certificate is not yet valid." Logy serveru a aplikace na straně provozovatele webu u této chyby obvykle neukážou vůbec nic, protože TLS handshake selže dřív, než se zaznamená jakýkoli HTTP požadavek. Důkaz se nachází v certifikátu a klientovi, ne v přístupovém logu webového serveru.

Co způsobuje ERR_CERT_DATE_INVALID

• Certifikátu vypršela platnost. Obnova neproběhla před datem "Valid to", nejčastěji proto, že automatizovaná úloha obnovy potichu přestala běžet.
• Certifikát ještě není platný. Méně časté: certifikát byl vydán nebo znovu vydán s datem "Valid from" mírně v budoucnosti, nebo server začal obsluhovat nový certifikát dřív, než se jeho okno otevřelo.
• Vypršel mezilehlý certifikát v řetězci. Koncový certifikát může být naprosto aktuální, zatímco mezilehlý certifikát, který server pořád posílá, už překročil vlastní platnost, a některé klienty kontrolují každý certifikát v řetězci.
• Hodiny zařízení návštěvníka jdou špatně. Notebook, který byl měsíce vypnutý, telefon s vypnutou automatickou synchronizací času, nebo zařízení s vybitou baterií CMOS, se mohou nastartovat s datem posunutým o roky jedním nebo druhým směrem.
• Virtuální stroj nebo kontejner se zastaralými hodinami. VM, které byly snapshotnuté, klonované nebo obnovené po dlouhé pauze, často nastartují s hodinami, které dohoní realitu, až se dokončí synchronizace NTP.
• Špatně nastavené časové pásmo nebo nesprávně ručně zadané datum nastavené uživatelem nebo zařízením typu kiosek, které nemá vlastní zdroj času.

Jak zjistit, čí je to chyba

Nejrychlejší způsob, jak to rozlišit, je zkontrolovat certifikát odjinud než z postiženého zařízení. Pokud druhé zařízení se spolehlivě správnými hodinami, nebo kontrolní bod mimo vaši vlastní síť, načte web bez varování o datu, je certifikát v pořádku a problém je lokální, u hodin toho jednoho zařízení. Pokud každé místo hlásí stejné vypršelé nebo ještě neplatné datum, pozornost potřebuje samotný certifikát. Spuštění SSL kontroly z několika míst najednou to vyřeší v jednom kroku, místo abyste si na test půjčovali druhý notebook.

Jak opravit ERR_CERT_DATE_INVALID

Pokud jste návštěvník

1. Nejdřív zkontrolujte datum, čas a časové pásmo svého zařízení. Tohle je jednoznačně nejčastější příčina způsobená vlastní chybou, zvlášť u zařízení Android s vypnutou automatickou synchronizací času, starších notebooků, které ležely nepoužívané, a strojů se selhávající baterií CMOS. Zapněte "Nastavit čas automaticky" a ověřte, že sedí rok, ne jen ciferník hodin.
2. Zkuste web na jiném zařízení nebo síti. Pokud se tam načte bez problémů, příčinou jsou hodiny vašeho původního zařízení (nebo captive portál zachytávající spojení), ne web.
3. Přečtěte si skutečná data na varovné stránce, než uděláte cokoli dalšího. Panel "Advanced" v Chrome i prohlížeč certifikátu ukazují "Valid from" a "Valid to" v prostém textu, což vám hned řekne, jestli certifikátu vypršela platnost, ještě není platný, nebo se plete vaše hodiny.
4. Neproklikávejte se přes certifikát, kterému skutečně vypršela platnost, na webu zpracovávajícím cokoli citlivého. Jakmile hodiny opravíte, znovu stránku načtěte; jen neopakujte stejný rozbitý stav.

Pokud web provozujete

1. Přečtěte si vlastní data certifikátu přímo, místo abyste se spoléhali na připomínku v kalendáři:

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

   Tohle vypíše notBefore a notAfter přímo z certifikátu, který server právě teď skutečně nabízí.
2. Pokud používáte Let's Encrypt, zkontrolujte úlohu obnovy, ne jen certifikát. Certifikáty Let's Encrypt záměrně vydrží 90 dní a automaticky se obnovují kolem 30denní hranice, ale automatizace může týdny potichu selhávat, než si toho někdo všimne: systemctl status certbot.timer (nebo ekvivalentní záznam v cronu) potvrdí, že je časovač pořád zapnutý a spouští se, a certbot renew --dry-run provede cestu obnovy, aniž by cokoli živého změnil. Skutečné selhání si přečtěte v /var/log/letsencrypt/letsencrypt.log, což je téměř vždy jedno z: přihlašovací údaje API pro DNS-01 výzvu vypršely, změna firewallu blokuje cestu HTTP-01 výzvy, nebo se při opakovaném ladění narazilo na limity četnosti Let's Encrypt.
3. Zkontrolujte celý řetězec, který váš server posílá, ne jen koncový certifikát:

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

   Některé servery po výměně koncového certifikátu dál obsluhují starý mezilehlý certifikát z disku. Každý certifikát v řetězci potřebuje aktuální okno platnosti, protože některé klienty ověřují celou cestu.
4. Ověřte vlastní systémové hodiny serveru. Server se špatným časem může vydávat automatizované obnovy s nesprávným datem "Valid from" a nezávisle na certifikátu mu může selhat i vlastní ověření OCSP a handshake. Potvrďte, že NTP běží a je synchronizované.
5. Obnovte nebo znovu vydejte certifikát a pak restartujte webový server. Obnovený certifikát ležící na disku nic neudělá, dokud si ho nevyzvedne proces obsluhující TLS: nginx -s reload, systemctl reload apache2, nebo ekvivalent pro load balancer či edge CDN držící vlastní kopii.
6. Po restartu opravu potvrďte zvenčí vlastní infrastruktury, protože prohlížeč nebo operační systém na vašem stroji může starý certifikát po dobu relace cachovat.

Jak předejít ERR_CERT_DATE_INVALID

Vypršující certifikát nedá varování nikomu, kdo ho konkrétně nehlídá: web funguje až do přesné vteřiny, kdy se okno uzavře, a pak varování naráz uvidí každý návštěvník. Naplánovaná SSL kontrola, která čte data certifikátu a upozorní před termínem, místo aby čekala, až návštěvníci začnou hlásit rozbitý web, promění tiché selhání obnovy v opravitelný tiket s předstihem v řádu dnů. Kontroly SSL a vypršení domény HostTracker sledují skutečné okno platnosti certifikátu zvenčí vaší infrastruktury a upozorní e-mailem, SMS, hlasovým hovorem, přes Slack, Telegram a další ještě před vypršením; spusťte jednu hned pomocí kontroly SSL certifikátu. Doprovodný návod na kontrolu vypršení SSL certifikátu podrobněji popisuje, jak si to nastavit.

Související chyby

• ERR_CERT_AUTHORITY_INVALID - data certifikátu jsou v pořádku, ale prohlížeč nedůvěřuje tomu, kdo ho vydal.
• ERR_CERT_COMMON_NAME_INVALID - certifikát je platný a důvěryhodný, ale nebyl vydaný pro název hostitele v adresním řádku.
• ERR_SSL_PROTOCOL_ERROR - handshake selhal dřív, než se vůbec dostal k certifikátu, obvykle nesoulad verze TLS, portu nebo konfigurace.

Často kladené otázky

Je bezpečné proklikat se přes varování ERR_CERT_DATE_INVALID?

Jen pokud jste si jistí, že příčinou jsou hodiny vlastního zařízení, protože to si můžete nezávisle ověřit. Pokud certifikátu skutečně vypršela platnost, proklikání odstraní jedinou kontrolu, která potvrzuje, že komunikujete se skutečným serverem přes šifrovaný, ověřený kanál.

Proč se tohle stává hned po resetu nebo vybalení zařízení?

Zařízení po továrním resetu nebo dlouho nepoužívané se často nastartuje s vnitřními hodinami vrácenými na výchozí datum, někdy roky v minulosti. Dokud se nepřipojí k internetu a automaticky nesynchronizuje čas, může s chybou data selhat úplně každý HTTPS web, ne jen jeden.

Opraví ERR_CERT_DATE_INVALID vymazání cache prohlížeče?

Zřídka. Tahle chyba je živé porovnání mezi daty certifikátu a aktuálními hodinami, vyhodnocované znovu při každém spojení, takže vymazání cache výsledek nezmění. Oprava hodin nebo certifikátu ano.

Proč mému certifikátu Let's Encrypt vypršela platnost bez jakéhokoli varování?

Protože obnova má být plně automatická, nikdo ji ručně nekontroluje, takže rozbitá úloha cronu, vypršelý přihlašovací údaj API pro DNS, nebo změněné pravidlo firewallu mohou obnovy týdny potichu zastavit bez viditelného příznaku, dokud certifikátu skutečně nevyprší platnost.

Může CDN nebo load balancer ovlivnit, co návštěvníci u této chyby vidí?

Ano. Pokud edge CDN drží vypršelý certifikát, chybu uvidí každý návštěvník bez ohledu na to, jaký certifikát má server originu, takže zkontrolujte tu vrstvu, která pro selhaný požadavek skutečně ukončuje TLS.

Jak často bych měl kontrolovat datum vypršení svého certifikátu?

Na zachycení selhání obnovy s předstihem v řádu týdnů stačí denní automatizovaná kontrola, protože certifikáty Let's Encrypt jsou platné 90 dní a většina ostatních certifikátů běží 90 dní až rok.