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. Включите "Устанавливать время автоматически" и убедитесь, что верен именно год, а не только положение стрелок.
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 отслеживают реальное окно действия сертификата извне вашей инфраструктуры и оповещают по email, 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, истекшие учетные данные API DNS или измененное правило файрвола могут молча остановить продления на недели без каких-либо видимых симптомов, пока сертификат действительно не истечет.

Может ли CDN или балансировщик нагрузки менять то, что посетители видят для этой ошибки?

Да. Если edge-узел CDN хранит просроченный сертификат, каждый посетитель увидит ошибку независимо от того, какой сертификат установлен на origin-сервере, поэтому проверяйте тот слой, который на самом деле терминирует TLS для провалившегося запроса.

Как часто нужно проверять срок действия своего сертификата?

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