Вчера сайт открывался нормально, а сегодня Chrome перекрыл страницу предупреждением ERR_CERT_DATE_INVALID. Браузер сообщает вполне конкретную вещь. Сертификат, который участвует в TLS-соединении, по часам компьютера ещё не начал действовать либо уже перестал действовать.
Я начинаю диагностику не с очистки кеша и переустановки браузера, а с двух проверок. Сначала смотрю дату, время и часовой пояс на устройстве. Затем открываю тот же сайт с другого устройства и через другую сеть. Если ошибка появляется на множестве сайтов, проблема почти всегда находится на компьютере или в сети. Если не работает один домен у всех пользователей, исправлять сертификат должен владелец сайта.
Что именно проверяет браузер
При HTTPS-соединении сервер передаёт клиенту сертификат сайта и обычно несколько промежуточных сертификатов. В каждом сертификате указаны две временные границы. Поле Not Before задаёт момент начала действия, поле Not After задаёт момент окончания.
Браузер сравнивает границы со временем на устройстве пользователя. В исходном коде Chromium ERR_CERT_DATE_INVALID описан именно так. Полученный сертификат по часам клиента выглядит просроченным или ещё не действующим. Среди возможных причин разработчики называют неверные часы, ошибку конфигурации сервера и попытку предъявить старый сертификат.
Серверные часы в такой проверке не служат главным ориентиром. Даже если время на сервере сбилось, браузер всё равно сравнивает даты сертификата со своими часами. Неверное время сервера может сорвать автоматическое продление, выпуск сертификата или работу OCSP stapling, но само по себе не меняет даты уже выпущенного сертификата.
Ошибка может относиться не только к сертификату домена. Иногда конечный сертификат остаётся действующим, но сервер отправляет устаревший промежуточный сертификат. Разные операционные системы и браузеры могут построить разные цепочки доверия, поэтому сайт способен открываться на новом телефоне и одновременно ломаться на старом компьютере.
Chrome и Edge обычно показывают код NET::ERR_CERT_DATE_INVALID. Firefox использует другие обозначения, например SEC_ERROR_EXPIRED_CERTIFICATE, SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE или ошибку, связанную с ответом OCSP из будущего. Названия различаются, но проверять нужно те же часы, даты сертификата и цепочку доверия.
Инструкции ниже предназначены для легальной диагностики собственных устройств, сайтов и серверов. Не отключайте проверку сертификатов для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений. Учитывайте законы своей страны, особенно России.
Как пользователю найти источник ошибки
Одна проверка редко даёт точный ответ. Я использую короткую последовательность, которая отделяет сбой сайта от проблем устройства и сети.
- Проверяю дату, время и часовой пояс.
- Открываю два или три известных HTTPS-сайта.
- Пробую проблемный адрес на телефоне через мобильную сеть.
- Смотрю срок действия и издателя сертификата.
- Проверяю антивирус, прокси, VPN и корпоративный шлюз.
| Результат проверки | Вероятная причина | Куда смотреть |
|---|---|---|
| Ошибка появляется почти на всех HTTPS-сайтах | Неверные часы, локальный перехват TLS, устаревшая система | Время, антивирус, прокси, обновления |
| Не открывается только один домен на разных устройствах | Просроченный сертификат или неправильная цепочка | Настройки сервера, CDN и балансировщика |
| Сайт работает через мобильную сеть, но не через Wi-Fi | Прокси, фильтр, страница авторизации или сбой роутера | Настройки сети и сертификат посредника |
| Ошибка возникает только на старом устройстве | Устаревшее хранилище корней или несовместимая цепочка | Обновления системы и состав цепочки |
| Ошибка появляется периодически | Один неисправный узел, адрес IPv6 или узел CDN | Все точки завершения TLS |
В Windows откройте параметры даты и времени, включите автоматическую установку времени и часового пояса, затем запустите синхронизацию. Для более точной проверки откройте Терминал Windows от имени администратора.
Get-Date
w32tm /query /status
w32tm /resyncGet-Date показывает текущее время, а w32tm /query /status помогает понять, синхронизировалась ли система с источником времени. Команда w32tm /resync запрашивает повторную синхронизацию. Если Windows сообщает, что данные времени недоступны, проверьте службу Windows Time, DNS и доступ к серверу NTP.
На Linux с systemd подойдут следующие команды.
timedatectl status
sudo timedatectl set-ntp trueВторая команда включает сетевую синхронизацию, если установленная служба времени поддерживает такой режим. После исправления часов полностью закройте браузер и запустите снова.
Если дата постоянно сбрасывается после отключения питания, причиной может служить разряженная батарейка часов реального времени на материнской плате. На ноутбуках похожее поведение также встречается после сбоя прошивки, длительного хранения без питания или неправильных настроек BIOS и UEFI.
Далее откройте сведения о сертификате на странице предупреждения. Сравните текущую дату с Not Before и Not After, затем посмотрите имя издателя. Просроченный на несколько дней сертификат одного сайта почти наверняка указывает на ошибку администратора. Сертификат, который начнёт действовать через месяц, при правильных часах означает неверно установленный файл или неправильную выдачу сертификата конкретным серверным узлом.
Имя издателя помогает найти локальный перехват HTTPS. Вместо публичного удостоверяющего центра браузер может показать антивирус, корпоративный шлюз, средство родительского контроля или неизвестную организацию. Такие программы расшифровывают соединение и создают новый сертификат для каждого сайта. Если локальный корневой или промежуточный сертификат просрочен, пользователь увидит ERR_CERT_DATE_INVALID сразу на множестве ресурсов.
На рабочем компьютере не удаляйте корпоративные сертификаты самостоятельно. Передайте администратору скриншот ошибки, адрес сайта, даты сертификата и имя издателя. На личном устройстве можно временно отключить сканирование зашифрованных соединений в антивирусе только для проверки. После теста верните защиту и обновите либо переустановите проблемный компонент.
В гостиницах, аэропортах и кафе сначала откройте страницу авторизации Wi-Fi. Сама по себе страница входа чаще вызывает ошибку имени сертификата, а не даты. ERR_CERT_DATE_INVALID появится, если сертификат шлюза или фильтра просрочен. Не вводите пароль от банка, почты или социальной сети в форму, которая появилась после предупреждения TLS.
Очистка кеша и cookie почти никогда не исправляет просроченный сертификат. Кеш не может изменить Not After. Переустановка браузера также не помогает, когда неправильный сертификат приходит с сервера, CDN или сетевого посредника.
Установка случайного корневого сертификата создаёт дополнительный риск. Корневой сертификат даёт его владельцу право подтверждать подлинность сайтов на устройстве. Сертификат Минцифры или другой доверенный корень может устранить ошибку неизвестного центра сертификации, но не продлит просроченный сертификат и не исправит ERR_CERT_DATE_INVALID.
Я также не советую нажимать кнопку продолжения, даже если браузер позволяет обойти предупреждение. При HSTS такой кнопки может не быть. Обход особенно опасен при входе в аккаунт, оплате, скачивании программ и передаче документов. Пользователь не способен по внешнему виду страницы отличить забытое продление от атаки посредника.
Что проверять владельцу сайта
Администратору нужно смотреть сертификат, который получает внешний клиент, а не файл на диске сервера. Сертификат мог успешно продлиться, но Nginx продолжил работать со старой копией. TLS также может завершаться на CDN, WAF, облачном балансировщике или отдельном reverse proxy, до которого новый файл не дошёл.
Проверить конечный сертификат можно через OpenSSL.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null
| openssl x509 -noout -subject -issuer -serial -dates -fingerprintПараметр -servername передаёт имя домена через SNI. Без SNI сервер с несколькими виртуальными хостами может вернуть сертификат другого сайта и направить диагностику по ложному пути.
Для проверки цепочки и имени домена используйте более строгий вариант.
openssl s_client
-connect example.com:443
-servername example.com
-verify_hostname example.com
-verify_return_error
-showcerts </dev/nullКоманда покажет сертификаты, которые реально отправил сервер, и завершит проверку ошибкой при проблеме доверия. Повторите тест для всех IP-адресов домена, включая IPv6. При нескольких узлах обращайтесь к каждому адресу напрямую, сохраняя исходное имя в -servername.
openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/nullТакой тест часто находит редкий сценарий. Три узла уже используют новый сертификат, а четвёртый несколько раз в день возвращает старый. Пользователь видит плавающую ошибку, которую администратор не может воспроизвести обычным обновлением страницы.
Отдельно проверьте сертификаты на следующих уровнях.
- Публичный CDN или WAF.
- Облачный и аппаратный балансировщик.
- IPv4- и IPv6-адреса.
- Все узлы кластера.
- Резервный дата-центр.
- Origin-сервер за CDN.
- Почтовые, API- и служебные поддомены.
Для сертификатов под управлением Certbot сначала посмотрите найденные конфигурации и даты.
sudo certbot certificates
sudo certbot renew --dry-run--dry-run проверяет будущую процедуру продления без замены рабочего сертификата. Обычная команда certbot renew пытается продлить сертификаты, для которых подошёл срок. Ручной режим Certbot без специальных authentication hooks автоматически не продлевается, хотя первоначальный выпуск мог пройти успешно.
sudo certbot renew
sudo nginx -t
sudo systemctl reload nginxДля Apache проверьте конфигурацию и перечитайте сертификаты.
sudo apachectl configtest
sudo systemctl reload apache2Nginx должен получить сертификат сайта вместе с промежуточными сертификатами. В типичной конфигурации Let’s Encrypt используется fullchain.pem.
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;Файл цепочки должен начинаться сертификатом сайта, после которого идут промежуточные сертификаты. Корневой сертификат сервер обычно не отправляет. Клиент уже должен доверять корню через системное или браузерное хранилище.
Частая ошибка появляется после копирования файлов из каталога Certbot. Администратор переносит cert.pem и privkey.pem в другой каталог, затем автоматическое продление обновляет оригиналы, а веб-сервер продолжает читать старые копии. Исправить ситуацию можно прямой ссылкой на управляемые файлы или deploy hook, который после успешного продления копирует сертификат и перезагружает нужную службу.
С марта 2026 года публичные TLS-сертификаты, выпущенные после вступления новых требований, не могут действовать дольше 200 дней. В 2027 году предел сократится до 100 дней, а в 2029 году до 47 дней. Такой график закрепляют правила CA/Browser Forum. Let’s Encrypt пока выдаёт обычные сертификаты на 90 дней и постепенно готовится к дальнейшему сокращению срока.
Ручное продление уже нельзя считать надёжной эксплуатационной схемой. Я настраиваю автоматическое продление, проверку через --dry-run, перезагрузку служб после выпуска и внешний мониторинг срока действия. Уведомление должно приходить до критического дня, а не после появления жалоб пользователей.
Ошибки, которые выглядят одинаково, но требуют разных решений
ERR_CERT_DATE_INVALID описывает временную проблему сертификата, но одинаковая страница в браузере может скрывать разные причины.
- Часы компьютера ушли вперёд, поэтому нормальный сертификат выглядит просроченным.
- Часы отстают, поэтому недавно выпущенный сертификат выглядит ещё не действующим.
- Владелец сайта не продлил сертификат.
- Сертификат продлился, но служба не перечитала новый файл.
- Один узел кластера или адрес IPv6 продолжает отдавать старую версию.
- CDN использует собственный просроченный сертификат, хотя origin настроен правильно.
- Сервер отправляет устаревший промежуточный сертификат.
- Антивирус или корпоративный прокси создаёт сертификаты через просроченный локальный центр.
- Старое устройство не умеет построить рабочую альтернативную цепочку.
Поэтому универсального совета вроде «очистите кеш» нет. Правильное решение зависит от масштаба сбоя, издателя сертификата, его временных границ и точки, где завершается TLS.
Что означает ERR_CERT_DATE_INVALID
Chrome считает сертификат сайта или сертификат выбранной цепочки просроченным либо ещё не действующим. Причиной также могут быть неправильные часы устройства.
Почему ошибка появилась на всех сайтах сразу
Сначала проверьте дату, время и часовой пояс. Затем посмотрите издателя сертификата. Массовая ошибка также встречается при перехвате HTTPS антивирусом, прокси, вредоносной программой или корпоративным шлюзом.
Можно ли исправить ошибку установкой корневого сертификата
Нет, если сертификат действительно просрочен. Новый корневой сертификат меняет доверие к издателю, но не меняет даты начала и окончания действия серверного сертификата.
Почему после продления сайт всё равно показывает старый сертификат
Веб-сервер могли не перезагрузить. Старый файл также может находиться на CDN, балансировщике, отдельном узле, IPv6-адресе или в каталоге, который Certbot не обновляет.
Поможет ли очистка кеша Chrome
Обычно нет. Кеш не продлевает сертификат и не исправляет часы. Перезапуск браузера имеет смысл после устранения причины, но начинать диагностику с удаления данных не нужно.
Можно ли открыть сайт через кнопку продолжения
Технически браузер иногда разрешает обход, но безопасным такой доступ не становится. Не вводите пароли, платёжные данные и не скачивайте файлы. На сайтах с HSTS обход может быть полностью запрещён.
Порядок действий остаётся простым. Пользователь проверяет часы, другой сайт, другое устройство, другую сеть и издателя сертификата. Владелец сайта проверяет внешний сертификат, полную цепочку, все узлы, CDN, IPv6 и автоматическое продление. Пока причина не установлена, обходить предупреждение и добавлять неизвестные корневые сертификаты нельзя. ERR_CERT_DATE_INVALID редко требует переустановки браузера, но почти всегда требует понять, чьим часам или чьему сертификату больше нельзя доверять.
