ERR_CERT_AUTHORITY_INVALID — ошибка Chrome и других Chromium-браузеров, которая означает, что браузер не доверяет удостоверяющему центру (CA), выпустившему проверку SSL сайта. Типичные причины: самоподписанный сертификат, неполная цепочка без промежуточного сертификата, неизвестный CA, SSL-инспекция антивируса или сбитые дата и время. Владелец сайта чинит ошибку установкой fullchain и сертификатом от доверенного CA, посетитель — проверкой часов и антивируса.
В этом руководстве разберём, как браузер строит цепочку доверия, все шесть типовых причин NET::ERR_CERT_AUTHORITY_INVALID, пошаговую диагностику через openssl и отдельные инструкции для владельца сайта и для обычного пользователя. Отдельная секция — про российские сертификаты Russian Trusted CA на сайтах Сбера и госуслуг: почему браузеры на них ругаются и что делать посетителям.
Что значит NET::ERR_CERT_AUTHORITY_INVALID
При открытии HTTPS-сайта браузер проверяет цепочку доверия: сертификат сайта должен быть подписан промежуточным сертификатом (intermediate), а тот — корневым сертификатом из хранилища доверенных корней. Chrome с 2022 года использует собственное хранилище в рамках Chrome Root Program: если цепочка не сходится к корню из этого списка, соединение помечается как небезопасное и вместо страницы показывается ошибка ERR_CERT_AUTHORITY_INVALID. Сам протокол и роль сертификатов в TLS подробно описаны в документации MDN по Transport Layer Security.
В других браузерах ошибка выглядит иначе, но механика та же: Firefox показывает SEC_ERROR_UNKNOWN_ISSUER или MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, Safari — «Это соединение не является частным». Важно: ошибка говорит о недоверии к издателю сертификата, а не об истёкшем сроке (для этого есть ERR_CERT_DATE_INVALID) и не о несовпадении имени (ERR_CERT_COMMON_NAME_INVALID). Краткая справка по ошибке — в нашем глоссарий: ERR_CERT_AUTHORITY_INVALID.
Причины ошибки ERR_CERT_AUTHORITY_INVALID
Самоподписанный сертификат
Сертификат подписан не удостоверяющим центром, а собственным ключом сервера. Такие сертификаты нормальны для локальной разработки и внутренних панелей (роутеры, NAS, dev-стенды), но публичный браузер им не доверяет по определению: издателя нет ни в одном хранилище корней. Подробно о том, где self-signed уместен и чем его заменить, — в статье про самоподписанные сертификаты.
Неполная цепочка: не отдан промежуточный сертификат
Самая частая причина на боевых сайтах. Сервер отдаёт только конечный (leaf) сертификат без промежуточного, и браузер не может достроить цепочку до корня. Коварство в том, что Chrome на десктопе часто скачивает недостающий intermediate сам (механизм AIA fetching), поэтому «у меня всё работает», а Firefox, мобильные браузеры и API документацию-клиенты вроде curl падают с ошибкой. Разбор этого сценария — в статье о неполной цепочке сертификатов.
Недоверенный или неизвестный удостоверяющий центр
Сертификат выпущен CA, корня которого нет в хранилище браузера. Сюда попадают внутренние корпоративные CA, отозванные из доверия центры и российские удостоверяющие центры: корень Russian Trusted Root CA от Минцифры не входит в хранилища Chrome, Firefox и Safari, поэтому сайты с такими сертификатами дают ERR_CERT_AUTHORITY_INVALID у большинства посетителей.
Антивирус с SSL-инспекцией
Kaspersky, ESET, Bitdefender и другие антивирусы умеют «просматривать» HTTPS-трафик: они разрывают соединение и переподписывают его собственным корневым сертификатом. Если этот корень не установился в системное хранилище (или браузер использует своё), любой сайт начинает выдавать ошибку доверия. Диагностический признак: в цепочке сертификата виден издатель с именем антивируса.
Сбитые дата и время на устройстве
Проверка цепочки включает проверку сроков действия каждого сертификата. Если часы устройства уехали на месяцы или годы (севшая батарейка CMOS, отключённая синхронизация NTP), валидные сертификаты выглядят просроченными или ещё не действующими, и браузер может показывать ошибки доверия на всех сайтах подряд.
Корпоративный прокси или Wi-Fi с перехватом
Корпоративные шлюзы (Zscaler, Squid с SSL-bump, FortiGate) перехватывают TLS так же, как антивирусы. На рабочем ноутбуке корень компании обычно предустановлен и всё работает, а на личном устройстве в той же сети каждый HTTPS-сайт даёт ERR_CERT_AUTHORITY_INVALID. Это не поломка сайта — это политика сети.
Таблица: причина → кто чинит → решение
| Причина | Кто чинит | Решение |
|---|---|---|
| Самоподписанный сертификат | Владелец сайта | Выпустить сертификат у доверенного CA (например, Let’s Encrypt) |
| Неполная цепочка (нет intermediate) | Владелец сайта | Указать в конфиге сервера fullchain, а не только leaf-сертификат |
| Неизвестный CA (в т. ч. российские УЦ) | Владелец сайта / пользователь | Перевыпустить у публичного CA; посетителю — браузер с нужным корнем |
| Антивирус с SSL-инспекцией | Пользователь | Отключить проверку HTTPS в антивирусе или переустановить его корень |
| Сбитые дата и время | Пользователь | Включить автосинхронизацию времени, проверить часовой пояс |
| Корпоративный прокси | Пользователь / ИТ-отдел | Установить корневой сертификат организации или сменить сеть |
Как исправить владельцу сайта
Шаг 1. Диагностика цепочки через openssl
Подключитесь к серверу и посмотрите, какие сертификаты он реально отдаёт. Флаг -servername обязателен: без него при SNI-хостинге сервер может вернуть другой сертификат.
openssl s_client -connect example.com:443 -servername example.com -showcertsСмотрите на последнюю строку Verify return code. Ключевые значения:
- 21 (unable to verify the first certificate) — сервер не отдаёт промежуточный сертификат: чините fullchain;
- 18 (self signed certificate) — самоподписанный сертификат: нужен выпуск у доверенного CA;
- 19 (self signed certificate in certificate chain) — цепочка упирается в неизвестный корень: внутренний или недоверенный CA, либо трафик перехватывается;
- 0 (ok) — цепочка валидна, ищите проблему на стороне клиента.
Проверить, что leaf-сертификат действительно подписан вашим промежуточным, можно локально:
openssl verify -untrusted intermediate.pem certificate.pemШаг 2. Отдавайте полную цепочку (fullchain)
В nginx в директиве ssl_certificate должен быть файл, содержащий и сертификат сайта, и промежуточные сертификаты — для Let’s Encrypt это fullchain.pem, а не cert.pem:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}В Apache 2.4.8+ промежуточные сертификаты добавляются в тот же файл, что указан в SSLCertificateFile (отдельная директива SSLCertificateChainFile устарела). После правки перезагрузите веб-сервер и повторите проверку openssl — Verify return code должен стать 0.
Шаг 3. Перевыпустите сертификат у доверенного CA
Если сертификат самоподписанный или выпущен УЦ без корня в браузерах, единственное надёжное решение — сертификат от публичного центра. Бесплатный вариант — Let’s Encrypt: certbot сам соберёт fullchain и настроит автопродление. Подробности — в официальной документации Let’s Encrypt.
sudo certbot --nginx -d example.com -d www.example.comКак исправить пользователю
Если ошибка появляется на чужом сайте (а тем более на многих сайтах сразу), проблема почти наверняка на вашей стороне. Действуйте по порядку:
- Проверьте дату и время. Включите автоматическую синхронизацию времени и правильный часовой пояс — это лечит массовые ошибки сертификатов чаще всего.
- Проверьте антивирус. Временно отключите проверку защищённых соединений (HTTPS-сканирование). Если ошибка исчезла — переустановите корневой сертификат антивируса или оставьте инспекцию выключенной.
- Смените сеть. Ошибка есть только на рабочем или общественном Wi-Fi? Трафик перехватывает прокси — обратитесь в ИТ-отдел или используйте другую сеть.
- Откройте сайт в другом браузере или в режиме инкогнито — так вы исключите влияние расширений.
Чего делать не стоит: не нажимайте «Перейти на сайт (небезопасно)» и не добавляйте постоянные исключения для сайтов, где вводите пароли или платёжные данные. Ошибка доверия — это ровно тот сигнал, который отличает настоящий сайт от подменённого атакующим.
Российские сертификаты: Сбер, госсайты и Russian Trusted CA
С 2022 года часть российских банков и госресурсов использует сертификаты Национального удостоверяющего центра Минцифры (Russian Trusted Sub CA). Его корневой сертификат не включён в хранилища Chrome, Firefox и Safari, поэтому эти браузеры показывают на таких сайтах ERR_CERT_AUTHORITY_INVALID — это ожидаемое поведение, а не взлом. Почему так сложилось и какие сайты затронуты, мы разбираем в отдельной статье про российские удостоверяющие центры.
У посетителя есть два пути: использовать браузер с предустановленным российским корнем (Яндекс Браузер или Atom) — это самый безопасный вариант; либо установить корневой сертификат Минцифры вручную, скачав его только с официальной страницы Госуслуг (gosuslugi.ru). Никогда не ставьте корневые сертификаты из мессенджеров, писем или со сторонних сайтов: установленный корень позволяет его владельцу выпускать сертификаты для любого домена, и поддельный корень означает полный перехват вашего HTTPS-трафика.
Как проверить сертификат и цепочку онлайн
Чтобы не собирать диагностику по частям, воспользуйтесь нашей бесплатной проверкой SSL-сертификата и цепочки: сервис покажет издателя, срок действия, полную цепочку до корня, отдаваемые сервером промежуточные сертификаты и предупредит, если fullchain настроен неверно. Это быстрый способ понять, увидят ли ошибку ваши посетители, — проверка идёт с внешнего сервера, а не из вашего браузера с его кешем и антивирусом.
Частые вопросы
Можно ли просто нажать «Всё равно перейти»?
Для чужих сайтов — не стоит: ошибка доверия неотличима от активной атаки с подменой сертификата, и введённые данные может читать посредник. Исключение допустимо для собственного оборудования — роутера или dev-стенда с самоподписанным сертификатом, когда вы точно знаете, что это за узел и почему у него такой сертификат.
Почему ошибка есть в Firefox, но нет в Chrome?
Классический признак неполной цепочки. Chrome на десктопе умеет докачивать недостающий промежуточный сертификат по ссылке AIA из сертификата, а Firefox и большинство мобильных браузеров этого не делают. Сайт «работает у владельца в Chrome» и падает у части посетителей. Решение одно — отдавать fullchain на сервере.
Чем ERR_CERT_AUTHORITY_INVALID отличается от ERR_CERT_DATE_INVALID?
ERR_CERT_AUTHORITY_INVALID — браузер не доверяет издателю сертификата (цепочка не сходится к доверенному корню). ERR_CERT_DATE_INVALID — сертификат просрочен или ещё не начал действовать. А ошибка ERR_SSL_VERSION_OR_CIPHER_MISMATCH вообще не про доверие: она про несовместимость версий протокола TLS и шифров между клиентом и сервером.
Поможет ли очистка кеша браузера?
Почти никогда: проверка сертификата выполняется при каждом TLS-рукопожатии, а не берётся из кеша страниц. Очистка может помочь только в редком случае закешированного состояния HSTS для домена. Сначала проверяйте время, антивирус и саму цепочку через openssl или онлайн-проверку — это устраняет причину, а не симптом.
Сертификат от Let’s Encrypt точно уберёт ошибку?
Да, при правильной установке. Корень ISRG Root X1, к которому сходятся цепочки Let’s Encrypt, входит в хранилища всех современных браузеров. Важно отдавать fullchain.pem и настроить автопродление: сертификаты Let’s Encrypt живут 90 дней, и просроченный сертификат даст уже другую ошибку — ERR_CERT_DATE_INVALID.