ERR_CERT_DATE_INVALID: прострочений сертифікат чи годинник

Що означає ERR_CERT_DATE_INVALID

Кожен TLS-сертифікат містить дві мітки часу, "Valid from" і "Valid to" (поля X.509 notBefore і notAfter). Під час рукостискання браузер порівнює ці мітки часу зі своїм власним уявленням про поточний час. Якщо вікно чинності сертифіката вже закрилося, ще не відкрилося, чи годинник браузера з якоїсь причини розміщує "зараз" поза цим вікном, рукостискання зупиняється ще до того, як браузер дійде до перевірки, хто видав сертифікат. Chrome й Edge показують NET::ERR_CERT_DATE_INVALID. Firefox показує SEC_ERROR_EXPIRED_CERTIFICATE для випадку простроченого сертифіката. Safari показує "This certificate has expired" чи "This certificate is not yet valid."

Дві абсолютно різні ситуації дають однакове попередження, і браузер не може вам сказати, яка саме: сертифікат справді прострочений чи ще не чинний, або з сертифікатом усе гаразд, а годинник клієнта неправильний. Обидва варіанти провалюють те саме порівняння.

Як з'являється помилка

У браузері сторінка взагалі не завантажується, і замість іконки помилки замочка на інакше завантаженій сторінці з'являється попередження на весь екран. Клік на "Advanced" показує конкретну причину і, в Chrome, власні дати сертифіката.

З командного рядка curl повідомляє про той самий збій точніше:

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

Ще не чинний сертифікат дає схожий рядок "certificate is not yet valid." Логи сервера й застосунку на боці власника сайту зазвичай узагалі нічого не показують для цієї помилки, бо TLS-рукостискання провалюється ще до того, як будь-який HTTP-запит потрапляє в лог. Докази лежать у сертифікаті й клієнті, а не в логу доступу вебсервера.

Що спричиняє ERR_CERT_DATE_INVALID

• У сертифіката закінчився термін дії. Поновлення не відбулося до дати "Valid to", найчастіше тому, що автоматизоване завдання поновлення мовчки перестало запускатися.
• Сертифікат ще не чинний. Рідше: сертифікат видали чи перевидали з датою "Valid from" трохи в майбутньому, або сервер почав віддавати новий сертифікат раніше, ніж відкрилося його вікно.
• У проміжного сертифіката в ланцюжку закінчився термін дії. Кінцевий сертифікат може бути цілком чинним, поки проміжний, який сервер усе ще надсилає, уже прострочений, а деякі клієнти перевіряють кожен сертифікат у ланцюжку.
• Годинник пристрою відвідувача неправильний. Ноутбук, що місяцями був вимкнений, телефон з вимкненою автоматичною синхронізацією часу, чи пристрій із мертвою батареєю CMOS можуть завантажитися з датою, зсунутою на роки в будь-який бік.
• Віртуальна машина чи контейнер із застарілим годинником. Віртуальні машини, які знімали в снапшот, клонували чи відновлювали після довгої паузи, часто завантажуються з годинником, що не наздогнав реальний час, доки не завершиться синхронізація NTP.
• Неправильно налаштований часовий пояс чи неправильна дата, встановлена вручну користувачем чи пристроєм-кіоском без власного джерела часу.

Як зрозуміти, хто винен

Найшвидший спосіб розділити - перевірити сертифікат з іншого пристрою, ніж той, що постраждав. Якщо другий пристрій із завідомо правильним годинником, чи контрольна точка поза вашою мережею, завантажує сайт без попередження про дату, із сертифікатом усе гаразд, а проблема локальна для годинника саме того одного пристрою. Якщо кожна точка спостереження повідомляє однакову прострочену чи ще не чинну дату, уваги потребує сам сертифікат. Запуск SSL-перевірки з кількох локацій одночасно вирішує це за один крок замість позичання другого ноутбука для тестування.

Як виправити ERR_CERT_DATE_INVALID

Якщо ви відвідувач

1. Спершу перевірте дату, час і часовий пояс на своєму пристрої. Це найпоширеніша причина, спричинена самим собою, особливо на пристроях Android із вимкненою автоматичною синхронізацією часу, старих ноутбуках, що довго лежали без використання, і машинах із батареєю CMOS, що виходить з ладу. Увімкніть "Set time automatically" і переконайтеся, що правильний саме рік, а не лише циферблат.
2. Спробуйте сайт на іншому пристрої чи в іншій мережі. Якщо там він завантажується чисто, причина - годинник вашого початкового пристрою (чи captive-портал, що перехоплює з'єднання), а не сайт.
3. Прочитайте фактичні дати на сторінці попередження, перш ніж робити щось іще. Панель "Advanced" у Chrome й переглядач сертифікатів показують "Valid from" і "Valid to" простим текстом, що одразу скаже, чи сертифікат прострочений, ще не чинний, чи винятком є саме ваш годинник.
4. Не переходьте далі на сайті, що обробляє щось чутливе, якщо сертифікат справді прострочений. Після виправлення годинника перезавантажте сторінку; не просто повторюйте ту саму зламану спробу.

Якщо ви керуєте сайтом

1. Прочитайте власні дати сертифіката напряму замість того, щоб покладатися на нагадування в календарі:

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

   Це виводить notBefore і notAfter прямо із сертифіката, який сервер справді видає зараз.
2. Якщо ви використовуєте Let's Encrypt, перевірте завдання поновлення, а не лише сам сертифікат. Сертифікати Let's Encrypt за задумом живуть 90 днів і поновлюються автоматично приблизно за 30 днів до кінця, але автоматизація може тижнями мовчки зазнавати збою, доки хтось помітить: systemctl status certbot.timer (чи еквівалентний запис у cron) підтверджує, що таймер усе ще увімкнений і спрацьовує, а certbot renew --dry-run проганяє шлях поновлення, нічого не змінюючи насправді. Прочитайте /var/log/letsencrypt/letsencrypt.log на предмет фактичного збою, який майже завжди один із: облікові дані API для DNS-01-виклику прострочилися, зміна брандмауера заблокувала шлях HTTP-01-виклику, чи вичерпано ліміти частоти запитів Let's Encrypt через повторне усунення несправностей.
3. Перевірте весь ланцюжок, який надсилає ваш сервер, а не лише кінцевий сертифікат:

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

   Деякі сервери продовжують віддавати старий проміжний сертифікат із диска після заміни кінцевого. Кожен сертифікат у ланцюжку потребує чинного вікна валідності, оскільки деякі клієнти перевіряють увесь шлях.
4. Перевірте власний системний годинник сервера. Сервер із неправильним часом може видавати автоматичні поновлення з неправильною датою "Valid from", а також може провалювати власну перевірку OCSP і рукостискання незалежно від сертифіката. Переконайтеся, що NTP запущений і синхронізований.
5. Поновіть чи перевидайте сертифікат, тоді перезавантажте вебсервер. Поновлений сертифікат на диску нічого не робить, доки процес, що обслуговує TLS, його не підхопить: nginx -s reload, systemctl reload apache2 чи еквівалент для балансувальника навантаження чи edge-вузла CDN, що тримає власну копію.
6. Підтвердьте виправлення ззовні власної інфраструктури після перезавантаження, оскільки браузер чи ОС на вашій машині можуть кешувати старий сертифікат на час сесії.

Як запобігти ERR_CERT_DATE_INVALID

Сертифікат, у якого закінчується термін дії, не дає жодного попередження нікому, хто спеціально за ним не стежить: сайт продовжує працювати аж до тієї самої секунди, коли вікно закривається, а тоді кожен відвідувач одночасно бачить те саме попередження. Запланована SSL-перевірка, що читає дати сертифіката й сповіщає до дедлайну, а не після того, як відвідувачі почнуть повідомляти про зламаний сайт, перетворює мовчазний збій поновлення на тікет із виправленням, у якого є дні запасу. Перевірки SSL і терміну дії домену HostTracker відстежують фактичне вікно чинності сертифіката ззовні вашої інфраструктури й сповіщають електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами, перш ніж воно закінчиться; запустіть перевірку зараз за допомогою інструмента перевірки SSL-сертифіката. Супутній посібник про перевірку терміну дії SSL-сертифіката детальніше описує, як це налаштувати.

Пов'язані помилки

• ERR_CERT_AUTHORITY_INVALID - дати сертифіката в порядку, але браузер не довіряє тому, хто його видав.
• ERR_CERT_COMMON_NAME_INVALID - сертифікат чинний і йому довіряють, але його видали не для того імені хоста, що в адресному рядку.
• ERR_SSL_PROTOCOL_ERROR - рукостискання провалилося ще до того, як узагалі дійшло до якогось сертифіката, зазвичай через невідповідність версії TLS, порту чи конфігурації.

Часті запитання

Чи безпечно переходити далі при попередженні ERR_CERT_DATE_INVALID?

Лише якщо ви впевнені, що причина - годинник вашого власного пристрою, оскільки це можна перевірити незалежно. Якщо сам сертифікат справді прострочений, перехід далі прибирає ту єдину перевірку, що підтверджує, що ви спілкуєтеся зі справжнім сервером через зашифрований, перевірений канал.

Чому це трапляється одразу після скидання чи розпакування пристрою?

Скинутий до заводських налаштувань чи довго не використовуваний пристрій часто завантажується з внутрішнім годинником, скинутим до дати за замовчуванням, іноді на роки в минулому. Доки він не підключиться до інтернету й автоматично не синхронізує час, будь-який HTTPS-сайт може провалюватися з помилкою дати, а не лише один.

Чи виправляє очищення кешу браузера ERR_CERT_DATE_INVALID?

Рідко. Ця помилка - живе порівняння між датами сертифіката й поточним годинником, яке оцінюється заново при кожному з'єднанні, тож очищення кешу не змінює результат. А виправлення годинника чи сертифіката - змінює.

Чому в мого сертифіката Let's Encrypt закінчився термін дії без жодного попередження?

Бо поновлення має бути повністю автоматичним, ніхто не перевіряє його вручну, тож зламане завдання cron, прострочені облікові дані DNS API чи змінене правило брандмауера можуть тижнями мовчки зупиняти поновлення без жодного видимого симптому, доки сертифікат справді не закінчиться.

Чи можуть CDN чи балансувальник навантаження змінити те, що бачать відвідувачі для цієї помилки?

Так. Якщо edge-вузол CDN тримає прострочений сертифікат, кожен відвідувач бачить помилку незалежно від того, який сертифікат має origin-сервер, тож перевіряйте саме той шар, що фактично завершує TLS для запиту, який провалився.

Як часто варто перевіряти термін дії свого сертифіката?

Щоденної автоматизованої перевірки достатньо, щоб виявити збій поновлення з запасом у тижні, оскільки сертифікати Let's Encrypt чинні 90 днів, а більшість інших сертифікатів - від 90 днів до року.