«Сертификат недействителен»: разбор ERR_CERT_AUTHORITY_INVALID и ERR_CERT_DATE_INVALID

Ошибка «сертификат недействителен» выглядит для пользователя как одна проблема: браузер не пускает на сайт. Для владельца сайта это целый класс сбоев HTTPS: от просроченного Let’s Encrypt до неправильной цепочки сертификатов, неустановленного промежуточного CA, ошибки SNI или сбитого времени на клиентском устройстве.

Чаще всего в Chrome и других браузерах на Chromium встречаются коды NET::ERR_CERT_AUTHORITY_INVALID и NET::ERR_CERT_DATE_INVALID — первый означает, что браузер не смог выстроить доверие к сертификату, второй — что сертификат не проходит проверку по времени.

Разберём, чем отличаются эти ошибки, как их диагностировать с клиентской и серверной стороны, какие команды использовать и как настроить мониторинг сертификатов, чтобы не узнавать о проблеме от клиентов.

Что означают ERR_CERT_AUTHORITY_INVALID и ERR_CERT_DATE_INVALID

NET::ERR_CERT_AUTHORITY_INVALID означает, что браузер не доверяет центру сертификации, выпустившему сертификат, либо не может построить корректную цепочку доверия до известного корневого сертификата.

Типичные формулировки:

• Chrome: Your connection is not private, NET::ERR_CERT_AUTHORITY_INVALID;
• Edge: похожее предупреждение с тем же кодом;
• Firefox: SEC_ERROR_UNKNOWN_ISSUER;
• Safari: «This Connection Is Not Private».

Ошибка не всегда означает, что сертификат «поддельный». Часто он настоящий, но сервер отдал неполную цепочку — например, только доменный сертификат без intermediate. Браузер не смог дойти до доверенного root CA и заблокировал соединение.

NET::ERR_CERT_DATE_INVALID означает, что сертификат не проходит проверку по времени. Он может быть:

• просрочен: текущая дата позже Not After;
• ещё не действителен: текущая дата раньше Not Before;
• выпущен корректно, но на устройстве пользователя сбиты дата, время или часовой пояс;
• заменён не на всех балансировщиках, поэтому часть пользователей видит старый сертификат.

Обе ошибки возникают до полноценной загрузки страницы: TLS-рукопожатие ломается раньше уровня HTTP, поэтому привычный код 200, 301, 404 или 500 может вообще не появиться. Если нужно освежить базу, полезно сначала разобраться, как работает HTTPS, SSL/TLS и сертификаты.

Как браузер решает, доверять сертификату или нет

При открытии https://example.com браузер проверяет не одну строку «сертификат есть», а набор условий.

1) Цепочка доверия — сервер отправляет leaf-сертификат домена и один или несколько intermediate-сертификатов. Браузер пытается построить путь до корневого сертификата, который уже есть в хранилище доверенных CA операционной системы или самого браузера. Если путь не строится, появляется ERR_CERT_AUTHORITY_INVALID.

2) Имя домена — сертификат должен быть выпущен именно для открываемого имени. Проверяется поле Subject Alternative Name, обычно DNS:example.com, DNS:www.example.com или wildcard вроде DNS:*.example.com. Ошибка имени обычно имеет отдельный код, например ERR_CERT_COMMON_NAME_INVALID, но на практике пользователи часто называют её «сертификат недействителен».

3) Срок действия — браузер сравнивает текущую дату с полями Not Before и Not After. Если сертификат ещё не начался или уже закончился, возникает ERR_CERT_DATE_INVALID.

4) Назначение сертификата — в расширениях Key Usage и Extended Key Usage должно быть разрешено использование для сервера, например TLS Web Server Authentication. Сертификат для почты, клиента или внутренней подписи не должен использоваться как публичный HTTPS-сертификат.

5) Подписи и алгоритмы — браузер проверяет криптографические подписи в цепочке и отклоняет устаревшие или небезопасные варианты. Старые сертификаты с неподдерживаемыми алгоритмами могут перестать работать после обновления браузеров.

6) SNI — при TLS-рукопожатии клиент сообщает серверу имя сайта через Server Name Indication. Это нужно, чтобы один IP-адрес мог обслуживать много HTTPS-доменов. Если SNI не передан или сервер неправильно его обрабатывает, клиент может получить сертификат от другого сайта. Подробнее об этом механизме — в разборе SNI и ALPN.

Почему возникает ERR_CERT_AUTHORITY_INVALID

Ошибка ERR_CERT_AUTHORITY_INVALID почти всегда связана с доверием к издателю сертификата или цепочкой сертификатов.

1) Самоподписанный сертификат — частая ситуация на тестовых стендах, внутренних панелях и dev-серверах. Сертификат подписан сам собой, поэтому публичные браузеры ему не доверяют. Для локальной разработки это нормально, но для публичного сайта — нет: нужен сертификат от доверенного CA, например Let’s Encrypt, Sectigo, DigiCert или GlobalSign.

2) Внутренний корпоративный CA — в компаниях часто используют собственный центр сертификации. Он может быть установлен на рабочих ноутбуках сотрудников, но отсутствовать у внешних пользователей, мобильных устройств или серверов мониторинга. Для публичного сайта такой сертификат не подходит.

3) Неполная цепочка сертификатов — сервер отдаёт только доменный сертификат, но не отдаёт intermediate. На одном клиенте сайт может открываться, потому что intermediate уже закэширован, а на другом — падать с ERR_CERT_AUTHORITY_INVALID. У администратора «всё работает», а у части клиентов — нет.

4) Использован cert.pem вместо fullchain.pem — типичная ошибка при настройке Nginx с Let’s Encrypt: в ssl_certificate нужно указывать полный набор сертификатов, а не только leaf. Пример правильной настройки есть в инструкции как настроить HTTPS и бесплатный SSL-сертификат в Nginx.

5) Антивирус, прокси или корпоративный MITM — некоторые антивирусы и прокси перехватывают HTTPS, подменяя сертификат своим. Если их root CA не установлен корректно или сломан, пользователь видит ошибку доверия — при этом на сервере всё в порядке.

6) Captive portal в публичной сети — Wi-Fi в отеле, аэропорту или кафе может сначала перенаправлять на страницу авторизации. Если портал вмешивается в HTTPS-соединение, браузер ругается на сертификат. Обычно помогает открыть http://neverssl.com или страницу авторизации сети.

7) Устаревшее хранилище корневых сертификатов — старые версии Android, Windows, Java runtime, embedded-устройства и некоторые корпоративные образы могут не знать новые корневые CA. Современный сертификат кажется им недоверенным.

8) Неправильный сертификат на балансировщике или CDN — если сертификат обновили на origin-сервере, но забыли про CDN, ingress, reverse proxy или отдельный балансировщик, часть трафика продолжит получать старую или чужую цепочку.

Почему возникает ERR_CERT_DATE_INVALID

ERR_CERT_DATE_INVALID проще по смыслу, но не всегда проще в расследовании: проблема в датах — на сертификате или на устройстве клиента.

1) Сертификат истёк — самый очевидный случай. Let’s Encrypt выдаёт сертификаты на короткий срок, поэтому автоматическое продление должно работать без участия человека. Если certbot renew не запускался, не смог пройти challenge или обновил файлы без перезагрузки Nginx, браузеры начнут блокировать сайт.

2) Сертификат ещё не начал действовать — бывает при ручной установке нового сертификата, ошибке выпуска, проблемах с временем на сервере или неправильной цепочке. Поле Not Before может оказаться в будущем относительно клиента.

3) Сбиты часы у пользователя — если на ноутбуке стоит 2019 год или неверный часовой пояс, почти любой нормальный сертификат может выглядеть просроченным или ещё недействительным. Первый шаг для пользователя — проверить системные дату, время и синхронизацию по NTP.

4) Обновили не все узлы — в кластере из нескольких web-серверов один узел может получить новый сертификат, а другой продолжит отдавать старый. Тогда ошибка плавающая: обновление страницы, другой регион CDN или другой балансировщик меняют результат.

5) Контейнер или образ содержит старые файлы — в Docker и Kubernetes сертификаты иногда попадают внутрь образа, а не монтируются как секрет или volume. Обновление на хосте не влияет на уже запущенный контейнер, и после рестарта может внезапно вернуться старый сертификат.

6) Сломался deploy-hook — certbot мог успешно обновить сертификат на диске, но не выполнить systemctl reload nginx или reload ingress-контроллера. Файлы новые, а процесс всё ещё держит старый сертификат в памяти.

Автоматизацию продления лучше проверять отдельно, а не надеяться на разовую настройку. Для Let’s Encrypt полезна инструкция как настроить автоматическое обновление сертификатов с помощью certbot.

Быстрая проверка со стороны пользователя

Если ошибка появилась у одного человека, не стоит сразу перезапускать продакшен. Сначала нужно понять: проблема локальная или серверная.

1) Проверить дату и время — убедиться, что включена автоматическая синхронизация времени, правильно выбран часовой пояс, дата не ушла на годы вперёд или назад. Это особенно актуально для ERR_CERT_DATE_INVALID.

2) Открыть сайт с другого устройства и сети — например, с мобильного интернета вместо офисного Wi-Fi. Если ошибка исчезла, вероятны корпоративный прокси, captive portal, антивирус или локальное хранилище сертификатов.

3) Проверить другой браузер — Chrome, Firefox и Safari используют разные механизмы доверия. Если проблема есть везде, вероятность серверной ошибки выше. Если только в одном браузере — стоит очистить кэш, обновить браузер и проверить расширения.

4) Посмотреть детали сертификата — в предупреждении браузера обычно можно открыть информацию о сертификате: издатель, срок действия, домены, цепочка. Нужно проверить, совпадает ли домен и нет ли явного Expired.

5) Не обходить предупреждение на важных сайтах — кнопка «перейти всё равно» не делает соединение безопасным. Для банков, админок, личных кабинетов и платежей это плохая идея. Исключение — контролируемый тестовый стенд, где вы точно знаете, что используется самоподписанный сертификат.

6) Проверить через curl — если есть терминал, команда curl -Iv https://example.com покажет, прошла ли TLS-проверка. Базовые приёмы работы с утилитой описаны в материале что такое curl и как им пользоваться.

Диагностика на сервере: команды и что смотреть

Для администратора важны три вопроса: какой сертификат реально отдаёт сервер, полная ли цепочка и совпадает ли результат на всех IP-адресах.

Базовая проверка через OpenSSL:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Ключевой параметр здесь — -servername example.com. Он передаёт SNI. Без него сервер может вернуть дефолтный сертификат, и диагностика будет неверной.

Смотрите на строки:

• Verify return code: 0 (ok) — цепочка доверия построена успешно;
• unable to get local issuer certificate — часто не хватает intermediate;
• self-signed certificate — сертификат самоподписанный или цепочка упирается в неизвестный root;
• certificate has expired — истёк срок;
• certificate is not yet valid — сертификат ещё не действует.

Чтобы вывести даты и issuer/subject:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Проверьте:

• notBefore и notAfter;
• issuer — кто выпустил сертификат;
• subjectAltName — есть ли нужный домен;
• соответствует ли сертификат окружению: production, staging, CDN, origin.

Если у домена несколько IP-адресов, проверяйте каждый отдельно. Сначала получите адреса через dig или host, затем используйте curl --resolve:

curl -Iv --resolve example.com:443:203.0.113.10 https://example.com/
curl -Iv --resolve example.com:443:203.0.113.11 https://example.com/

Так можно поймать ситуацию, когда один backend уже обновлён, а второй отдаёт старый сертификат. Это особенно полезно для балансировщиков, нескольких дата-центров и blue-green deployment.

Для Nginx проверьте, что используется именно полный chain-файл:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

После замены сертификата нужен reload:

nginx -t && systemctl reload nginx

Если используется HAProxy, Envoy, Traefik, Kubernetes ingress или CDN, проверять нужно не только origin. TLS может завершаться на любом из этих уровней, и ошибка в одном слое будет видна пользователю, даже если приложение настроено правильно.

Как исправить ERR_CERT_AUTHORITY_INVALID

Исправление зависит от причины, но общий принцип один: сервер должен отдавать корректный сертификат и полную цепочку до доверенного CA.

1) Заменить самоподписанный сертификат на публичный — для публичного сайта используйте сертификат от доверенного центра сертификации, бесплатный вариант — Let’s Encrypt. Самоподписанные сертификаты оставьте для локальной разработки, VPN, внутренних сервисов или тестовых окружений с явно установленным root CA.

2) Отдавать полную цепочку — в Nginx указывайте fullchain.pem, в Apache — файл с полной цепочкой, в балансировщике — bundle с leaf и intermediate. Не добавляйте root-сертификат без необходимости: обычно он уже есть в trust store клиента.

3) Проверить SNI и virtual hosts — убедитесь, что нужный сертификат привязан к нужному server_name, ingress host или frontend. Если домены обслуживаются на одном IP, ошибка в дефолтном vhost часто приводит к выдаче чужого сертификата.

4) Убрать staging-сертификаты из production — Let’s Encrypt staging использует недоверенную цепочку. Это удобно для тестирования лимитов и автоматизации, но не подходит для пользователей. Проверьте, что в production не остались staging endpoint и тестовые файлы.

5) Обновить цепочки на CDN и балансировщиках — если TLS завершается на CDN, сертификат нужно смотреть там. В режимах вроде Cloudflare Full или Full Strict проверяется ещё и сертификат на origin. Ошибка может быть как на edge, так и между CDN и origin.

6) Проверить старые клиенты — если жалобы приходят только со старых Android, Java-клиентов или embedded-устройств, проблема может быть в их trust store. Иногда помогает альтернативная цепочка, но чаще нужно обновлять клиентскую среду.

Как исправить ERR_CERT_DATE_INVALID

Для ERR_CERT_DATE_INVALID первое действие — сравнить даты на сертификате, сервере и клиенте.

1) Если сертификат истёк — выпустите новый и установите его на точку TLS-терминации: Nginx, Apache, HAProxy, CDN, ingress. Затем выполните reload сервиса и проверьте результат снаружи через openssl или curl.

2) Если новый сертификат уже на диске, но браузер видит старый — проверьте, был ли reload, и что процесс использует именно новые файлы, а не копию в другом каталоге. Частая ошибка — обновляется /etc/letsencrypt/live/example.com/fullchain.pem, а конфиг сервера указывает на старый путь.

3) Если часть запросов получает старый сертификат — проверьте все IP-адреса, backend-ноды, балансировщики и регионы CDN. Не ограничивайтесь проверкой с одного рабочего ноутбука.

4) Если сертификат «not yet valid» — проверьте системное время на сервере и клиенте, NTP, часовой пояс, а также дату выпуска сертификата. В нормальной инфраструктуре серверы должны синхронизировать время автоматически.

5) Если проблема после миграции — проверьте, не остался ли старый сертификат в Docker image, Kubernetes secret, secret manager или панели CDN. При переносе сайтов часто обновляют DNS и приложение, но забывают слой TLS.

6) Если renewal периодически ломается — посмотрите логи certbot, systemd timer или cron. Проверьте HTTP-01/DNS-01 challenge, доступность .well-known/acme-challenge/, права на файлы и deploy hooks.

Где помогает мониторинг сертификатов

SSL-ошибки неприятны тем, что сайт может быть «живым» с точки зрения сервера, но недоступным для пользователей: процесс Nginx запущен, порт 443 открыт, backend отвечает, а браузер всё равно блокирует страницу из-за TLS.

Поэтому мониторинг доступности должен проверять не только TCP-порт или HTTP-статус, но и HTTPS-соединение целиком: DNS, TLS-рукопожатие, валидацию сертификата, ответ сервера. Statuser, например, проверяет сайт с заданным интервалом и присылает уведомление о сбое — это помогает заметить истёкший сертификат, сломанную цепочку или недоступный HTTPS раньше, чем начнут писать пользователи.

Отдельно стоит настроить мониторинг срока действия сертификата: хорошая проверка предупреждает заранее, а не в момент, когда Not After уже наступил. Полезно следить за:

• количеством дней до истечения;
• соответствием домена в SAN;
• валидностью цепочки;
• ошибками TLS-рукопожатия;
• разными endpoint: example.com, www.example.com, API-домены, админки, CDN и origin при необходимости.

При этом не нужно превращать мониторинг в источник шума — обычно достаточно регулярной проверки доступности и отдельного алерта о приближении истечения сертификата. Подробнее о смысле таких проверок — в статье почему важен мониторинг SSL-сертификатов.

Короткий чеклист для продакшена

1) Используйте доверенный CA — публичные сайты должны иметь сертификаты от доверенных центров сертификации, самоподписанные — только для контролируемых внутренних контуров.

2) Всегда отдавайте full chain — для Let’s Encrypt в Nginx нужен fullchain.pem, а не cert.pem.

3) Проверяйте сертификат с SNI — команды диагностики должны содержать -servername domain, иначе можно получить дефолтный сертификат и сделать неправильный вывод.

4) Автоматизируйте продление — настройте certbot renew, systemd timer или механизм вашего CA и обязательно проверьте reload после обновления.

5) Проверяйте все точки TLS-терминации — CDN, балансировщик, ingress, reverse proxy, origin. Сертификат может быть правильным на одном уровне и неправильным на другом.

6) Не забывайте про www и поддомены — сертификат для example.com не всегда покрывает www.example.com, api.example.com или admin.example.com.

7) Следите за временем — NTP на серверах обязателен. Сбитые часы ломают не только TLS, но и логи, токены и кэш.

8) Настройте внешний мониторинг — проверка из внешней сети лучше отражает пользовательский опыт, чем локальный curl с самого сервера.

FAQ

Почему сайт открывается у меня, но у клиента ERR_CERT_AUTHORITY_INVALID?
Возможны кэш intermediate-сертификата у вас, разные IP-адреса, CDN-регионы, корпоративный прокси у клиента или устаревшее хранилище корневых сертификатов на его устройстве.

Можно ли просто нажать «перейти всё равно»?
Для тестового стенда — иногда да, если вы понимаете риск. Для публичных сайтов, админок, платежей и личных кабинетов — нет: браузер предупреждает о реальной проблеме доверия.

Почему после продления Let’s Encrypt браузер всё равно показывает старый сертификат?
Чаще всего не был выполнен reload Nginx/Apache/HAProxy, обновился не тот путь, старый сертификат остался на CDN или одна из backend-нод не получила новые файлы.

Чем ERR_CERT_AUTHORITY_INVALID отличается от ERR_SSL_PROTOCOL_ERROR?
ERR_CERT_AUTHORITY_INVALID связан с доверием к сертификату или цепочкой. ERR_SSL_PROTOCOL_ERROR шире: это может быть несовместимость TLS-версий, шифров, некорректная настройка HTTPS или сбой рукопожатия. Есть отдельный разбор ERR_SSL_PROTOCOL_ERROR.