Przejdź do treści głównej

Poradniki / Napraw to: poradniki na błędy, które naprawdę się zdarzają

ERR_CERT_DATE_INVALID: wygasły certyfikat albo zły zegar - naprawa

ERR_CERT_DATE_INVALID oznacza, że przeglądarka odrzuciła certyfikat witryny, bo zawiodła kontrola daty: certyfikat wygasł, jeszcze nie jest ważny, albo własny zegar urządzenia jest błędny. To konkretnie problem daty, nie zaufania czy nazwy hosta, więc naprawa dotyczy albo certyfikatu, albo zegara, który go odczytuje.

Co oznacza ERR_CERT_DATE_INVALID

Każdy certyfikat TLS niesie dwa znaczniki czasu, "Valid from" i "Valid to" (pola X.509 notBefore i notAfter). Podczas handshake'u przeglądarka porównuje te znaczniki czasu z własnym wyobrażeniem o aktualnym czasie. Jeśli okno certyfikatu się zamknęło, jeszcze się nie otworzyło, albo zegar przeglądarki umieszcza "teraz" poza tym oknem z dowolnego powodu, handshake zatrzymuje się, zanim przeglądarka w ogóle sprawdzi, kto wystawił certyfikat. Chrome i Edge pokazują NET::ERR_CERT_DATE_INVALID. Firefox pokazuje SEC_ERROR_EXPIRED_CERTIFICATE dla przypadku wygaśnięcia. Safari pokazuje "This certificate has expired" albo "This certificate is not yet valid."

Dwie zupełnie różne sytuacje produkują identyczne ostrzeżenie, a przeglądarka nie potrafi powiedzieć, która to: certyfikat naprawdę wygasł albo jeszcze nie jest ważny, albo certyfikat jest w porządku, a to zegar klienta jest błędny. Oba przypadki zawodzą to samo porównanie.

Jak pojawia się błąd

W przeglądarce strona nigdy się nie ładuje i zamiast ikony błędu na kłódce na w pełni załadowanej stronie pojawia się ostrzeżenie na całą kartę. Kliknięcie "Zaawansowane" pokazuje konkretny powód, a w Chrome też własne daty certyfikatu.

Z linii poleceń curl zgłasza tę samą awarię z większą precyzją:

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

Certyfikat jeszcze nieważny produkuje podobną linię "certificate is not yet valid." Logi serwera i aplikacji po stronie właściciela witryny zwykle nic nie pokazują dla tego błędu, bo handshake TLS zawodzi, zanim jakiekolwiek żądanie HTTP zostanie zalogowane. Dowody leżą w certyfikacie i kliencie, nie w logu dostępu serwera WWW.

Co powoduje ERR_CERT_DATE_INVALID

  • Certyfikat wygasł. Odnowienie nie nastąpiło przed datą "Valid to", najczęściej dlatego, że zautomatyzowane zadanie odnowienia po cichu przestało działać.
  • Certyfikat jeszcze nie jest ważny. Rzadszy przypadek: certyfikat został wystawiony albo ponownie wystawiony z datą "Valid from" nieco w przyszłości, albo serwer zaczął serwować nowy certyfikat, zanim jego okno się otworzyło.
  • Certyfikat pośredni w łańcuchu wygasł. Certyfikat liścia może być całkowicie aktualny, podczas gdy pośredni certyfikat, który serwer wciąż wysyła, minął własną datę wygaśnięcia, a niektóre klienty sprawdzają każdy certyfikat w łańcuchu.
  • Zegar urządzenia odwiedzającego jest błędny. Laptop wyłączony od miesięcy, telefon z wyłączoną automatyczną synchronizacją czasu albo urządzenie z padniętą baterią CMOS może uruchomić się z datą przesuniętą o lata w dowolnym kierunku.
  • Maszyna wirtualna albo kontener z nieaktualnym zegarem. Maszyny wirtualne, które zostały zrzucone do snapshotu, sklonowane albo wznowione po długiej przerwie, często uruchamiają się z zegarem, który nie nadgonił, dopóki nie zakończy się synchronizacja NTP.
  • Źle skonfigurowana strefa czasowa albo błędnie ustawiona ręcznie data ustawiona przez użytkownika albo urządzenie typu kiosk bez własnego źródła czasu.

Jak rozpoznać, kto zawinił

Najszybszy sposób podziału to sprawdzenie certyfikatu skądinąd niż z dotkniętego urządzenia. Jeśli drugie urządzenie ze znanym poprawnym zegarem, albo punkt kontrolny spoza Twojej własnej sieci, ładuje witrynę bez ostrzeżenia o dacie, certyfikat jest w porządku, a problem jest lokalny dla zegara tego jednego urządzenia. Jeśli każdy punkt obserwacji zgłasza tę samą wygasłą albo jeszcze nieważną datę, sam certyfikat wymaga uwagi. Uruchomienie kontroli SSL z kilku lokalizacji naraz rozstrzyga to w jednym kroku, zamiast pożyczać drugiego laptopa do testów.

Jak naprawić ERR_CERT_DATE_INVALID

Jeśli jesteś odwiedzającym

  1. Sprawdź najpierw datę, godzinę i strefę czasową swojego urządzenia. To pojedyncza najczęstsza przyczyna zawiniona przez samego siebie, zwłaszcza na urządzeniach z Androidem z wyłączoną automatyczną synchronizacją czasu, starszych, długo nieużywanych laptopach i maszynach z awarią baterii CMOS. Włącz "Ustaw czas automatycznie" i potwierdź, że rok jest poprawny, nie tylko tarcza zegara.
  2. Wypróbuj witrynę na innym urządzeniu albo w innej sieci. Jeśli ładuje się tam czysto, przyczyną jest zegar Twojego oryginalnego urządzenia (albo captive portal przechwytujący połączenie), nie witryna.
  3. Przeczytaj rzeczywiste daty na stronie ostrzeżenia, zanim zrobisz cokolwiek innego. Panel "Zaawansowane" Chrome i przeglądarka certyfikatów pokazują w czystym tekście "Valid from" i "Valid to", co od razu mówi, czy certyfikat wygasł, jeszcze nie jest ważny, czy to Twój zegar jest odstający.
  4. Nie klikaj dalej przy certyfikacie, który jest naprawdę wygasły, na witrynie obsługującej cokolwiek wrażliwego. Po skorygowaniu zegara przeładuj; nie ponawiaj po prostu tego samego zepsutego stanu.

Jeśli prowadzisz witrynę

  1. Odczytaj bezpośrednio własne daty certyfikatu zamiast ufać przypomnieniu w kalendarzu:
    openssl s_client -connect example.com:443 -servername example.com /dev/null   | openssl x509 -noout -dates
    To wypisuje notBefore i notAfter wprost z certyfikatu, który serwer faktycznie teraz prezentuje.
  2. Jeśli używasz Let's Encrypt, sprawdź zadanie odnowienia, nie tylko sam certyfikat. Certyfikaty Let's Encrypt z założenia trwają 90 dni i odnawiają się automatycznie mniej więcej po 30 dniach, ale automatyzacja może po cichu zawodzić tygodniami, zanim ktokolwiek to zauważy: systemctl status certbot.timer (albo odpowiedni wpis crona) potwierdza, że timer jest wciąż włączony i się uruchamia, a certbot renew --dry-run przechodzi ścieżkę odnowienia bez zmiany czegokolwiek na żywo. Przeczytaj /var/log/letsencrypt/letsencrypt.log pod kątem rzeczywistej awarii, która niemal zawsze jest jedną z: wygasłych poświadczeń API dla wyzwania DNS-01, zmiany zapory blokującej ścieżkę wyzwania HTTP-01, albo osiągnięcia limitów Let's Encrypt podczas powtarzanego rozwiązywania problemów.
  3. Sprawdź pełny łańcuch, który wysyła Twój serwer, nie tylko certyfikat liścia:
    openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null   | openssl x509 -noout -dates -in -
    Niektóre serwery wciąż serwują stary certyfikat pośredni z dysku po wymianie liścia. Każdy certyfikat w łańcuchu potrzebuje aktualnego okna ważności, bo niektóre klienty walidują całą ścieżkę.
  4. Zweryfikuj własny zegar systemowy serwera. Serwer z błędnym czasem może wystawiać zautomatyzowane odnowienia z niepoprawną datą "Valid from", a także może zawieść własną walidację OCSP i handshake'u niezależnie od certyfikatu. Potwierdź, że NTP działa i jest zsynchronizowany.
  5. Odnów albo wystaw ponownie certyfikat, a potem przeładuj serwer WWW. Odnowiony certyfikat leżący na dysku nic nie robi, dopóki nie podchwyci go proces serwujący TLS: nginx -s reload, systemctl reload apache2 albo odpowiednik dla load balancera albo brzegu CDN trzymającego własną kopię.
  6. Potwierdź naprawę spoza własnej infrastruktury po przeładowaniu, bo przeglądarka albo system operacyjny na Twojej maszynie mogą cache'ować stary certyfikat na czas sesji.

Jak zapobiec ERR_CERT_DATE_INVALID

Wygasający certyfikat nie daje żadnego ostrzeżenia nikomu, kto specjalnie tego nie obserwuje: witryna działa bez zarzutu aż do dokładnie tej sekundy, w której okno się zamyka, a potem każdy odwiedzający widzi to samo ostrzeżenie naraz. Zaplanowana kontrola SSL, która czyta daty certyfikatu i ostrzega przed terminem, zamiast po tym, jak odwiedzający zaczną zgłaszać zepsutą witrynę, zamienia cichą awarię odnowienia w naprawialne zgłoszenie z dniami wyprzedzenia. Kontrole SSL i wygaśnięcia domeny HostTrackera śledzą rzeczywiste okno ważności certyfikatu spoza Twojej infrastruktury i alarmują e-mailem, SMS-em, połączeniem głosowym, przez Slack, Telegram i inne kanały, zanim wygaśnie; uruchom teraz jedną za pomocą kontroli certyfikatu SSL. Towarzyszący poradnik o sprawdzaniu wygaśnięcia certyfikatu SSL szczegółowo opisuje konfigurację tego mechanizmu.

Powiązane błędy

  • ERR_CERT_AUTHORITY_INVALID - daty certyfikatu są w porządku, ale przeglądarka nie ufa temu, kto go wystawił.
  • ERR_CERT_COMMON_NAME_INVALID - certyfikat jest ważny i zaufany, ale nie został wystawiony dla nazwy hosta w pasku adresu.
  • ERR_SSL_PROTOCOL_ERROR - handshake zawiódł, zanim jakikolwiek certyfikat został w ogóle osiągnięty, zwykle niedopasowanie wersji TLS, portu albo konfiguracji.

Najczęściej zadawane pytania

Czy bezpiecznie jest kliknąć dalej przy ostrzeżeniu ERR_CERT_DATE_INVALID?

Tylko jeśli masz pewność, że przyczyną jest zegar Twojego własnego urządzenia, bo to możesz zweryfikować niezależnie. Jeśli sam certyfikat naprawdę wygasł, kliknięcie dalej usuwa jedyną kontrolę potwierdzającą, że rozmawiasz z prawdziwym serwerem przez zaszyfrowany, zweryfikowany kanał.

Dlaczego zdarza się to zaraz po zresetowaniu albo rozpakowaniu urządzenia?

Reset fabryczny albo długo nieużywane urządzenie często uruchamia się z wewnętrznym zegarem cofniętym do daty domyślnej, czasem sprzed lat. Dopóki nie połączy się z internetem i automatycznie nie zsynchronizuje czasu, każda witryna HTTPS może zawieść z błędem daty, nie tylko jedna.

Czy wyczyszczenie cache przeglądarki naprawia ERR_CERT_DATE_INVALID?

Rzadko. Ten błąd to porównanie na żywo między datami certyfikatu a aktualnym zegarem, oceniane od nowa przy każdym połączeniu, więc czyszczenie cache nie zmienia wyniku. Skorygowanie zegara albo certyfikatu zmienia.

Dlaczego mój certyfikat Let's Encrypt wygasł bez żadnego ostrzeżenia?

Bo odnowienie ma być w pełni automatyczne, nikt go ręcznie nie sprawdza, więc zepsute zadanie crona, wygasłe poświadczenie API DNS albo zmieniona reguła zapory mogą po cichu zatrzymać odnowienia na tygodnie bez żadnego widocznego objawu, aż certyfikat faktycznie minie.

Czy CDN albo load balancer mogą zmienić to, co widzą odwiedzający przy tym błędzie?

Tak. Jeśli brzeg CDN trzyma wygasły certyfikat, każdy odwiedzający widzi błąd niezależnie od tego, jaki certyfikat ma serwer źródłowy, więc sprawdź warstwę, która faktycznie terminuje TLS dla żądania, które zawiodło.

Jak często powinienem sprawdzać datę wygaśnięcia certyfikatu?

Codzienna zautomatyzowana kontrola wystarczy, żeby wyłapać awarię odnowienia z tygodniami wyprzedzenia, skoro certyfikaty Let's Encrypt są ważne 90 dni, a większość innych certyfikatów działa od 90 dni do roku.

Sprawdź teraz

Uruchom darmowe sprawdzenie na swojej stronie - bez zakładania konta.

SSL check

Monitoruj to na stałe

Otrzymasz powiadomienie w chwili awarii: HostTracker sprawdza z ponad 300 lokalizacji i powiadamia e-mailem, SMS-em, przez Slack, Telegram i nie tylko.

Funkcje HostTracker

Więcej w tej sekcji: Napraw to: poradniki na błędy, które naprawdę się zdarzają