Ошибки

NET::ERR_CERT_AUTHORITY_INVALID: что значит и как исправить

NET::ERR_CERT_AUTHORITY_INVALID — Chrome не может проверить, кто выпустил сертификат сайта, и поэтому ему не доверяет. Например, сертификат самоподписанный: владелец сайта выпустил его сам, без центра сертификации.

Обновлено 08.10.2026≈ 9 мин чтения
Содержание 10

Что сделать прямо сейчас

Если вы просто открываете сайт:

  1. Не вводите на этом сайте пароли, сообщения и данные банковских карт, пока предупреждение не исчезнет: нельзя быть уверенным, что вы попали на настоящий сайт.
  2. Если предупреждение появляется только на этом сайте, сообщите его владельцу код ошибки: NET::ERR_CERT_AUTHORITY_INVALID. Исправить её может только он.
  3. Если похожие предупреждения появляются на многих сайтах сразу, проверьте дату и время на устройстве — как это сделать, рассказано на странице NET::ERR_CERT_DATE_INVALID. Если дата и время верные, сообщите о проблеме тому, кто обслуживает ваш компьютер или сеть, — например, системному администратору на работе.

Если сайт ваш, переходите к разделам «Как проверить» и «Как исправить» ниже: там все команды по шагам.

Что значит ошибка

SSL-сертификат — электронный документ, которым сайт подтверждает браузеру, что он настоящий. Выпускает его центр сертификации — организация, которой доверяют браузеры и операционные системы, например Let's Encrypt. Если Chrome не может связать сертификат сайта с центром сертификации, которому доверяет, он показывает NET::ERR_CERT_AUTHORITY_INVALID — в исходном коде Chrome это ошибка -202.

В исходном коде названы три возможные причины: сертификат самоподписанный, его выпустил центр сертификации, о котором Chrome не знает, или злоумышленник подменил настоящий сертификат своим.

Если сертификат, например, самоподписанный и к тому же выпущен для другого имени, Chrome покажет именно эту ошибку: когда проблем несколько, он сообщает о самой серьёзной. Так было и на нашем тестовом сервере.

Как выглядит в Chrome

Вкладка называется «Ошибка нарушения конфиденциальности», заголовок страницы — «Подключение не защищено». Под ним Chrome предупреждает, что злоумышленники, возможно, пытаются похитить данные с сайта: пароли, сообщения, данные банковских карт. Дальше — ссылка «Подробнее об этом предупреждении…», код NET::ERR_CERT_AUTHORITY_INVALID и предложение включить режим «Улучшенная защита». Внизу — кнопки «Вернуться к безопасной странице» и «Дополнительные настройки».

«Дополнительные настройки» раскрывают пояснение: сертификату сайта нет доверия, поэтому Chrome не может подтвердить, что это настоящий сервер.

Причины

  • Сертификат самоподписанный. Владелец сайта выпустил его сам — например, чтобы проверить HTTPS на тестовом сервере.
  • Сертификат выпустил центр сертификации, о котором Chrome не знает, — например, внутренний центр сертификации компании.
  • Сертификат тестовый. Certbot выпускает такие с ключом --test-cert или --staging либо с адресом тестового сервера после --server. Они нужны только для проверки настроек.
  • Не хватает промежуточного сертификата. Центр сертификации подписывает сертификаты сайтов через промежуточный сертификат, и сервер должен отдавать его вместе с сертификатом сайта. Если в настройках nginx указан файл cert.pem — в нём только сертификат сайта, — а не fullchain.pem, цепочка неполная. По документации nginx, одни браузеры в таком случае предупреждают об ошибке, а другие принимают сертификат без вопросов. Поэтому проверяйте цепочку командами из раздела «Как проверить», а не только в своём браузере.
  • Сертификат подменили. Кто-то между посетителем и сайтом перехватывает соединение и отдаёт свой сертификат.

Как проверить

Команды из этого раздела вводятся в терминале сервера. Если вы ещё не подключались к нему, начните с инструкции Как подключиться к VPS по SSH. Скопируйте команду целиком, замените example.com на адрес своего сайта и нажмите Enter.

Шаг 1. Посмотрите, кто выпустил сертификат

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

Ответ — две строки: subject — для кого выпущен сертификат, issuer — кто его выпустил. Если в обеих строках одно и то же, сертификат самоподписанный. У сертификата от центра сертификации в строке issuer будет название этого центра, например Let's Encrypt.

Шаг 2. Проверьте всю цепочку

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep "Verify return code"

Если в ответе Verify return code: 0 (ok), цепочка в порядке. Код 18 значит, что сертификат самоподписанный. Любой другой код, кроме 0, — проверка не прошла, причина написана в скобках после кода.

Шаг 3. Откройте сайт программой curl

curl -I https://example.com/

Если сертификат в порядке, curl покажет заголовки ответа сервера: первая строка начинается с HTTP и кода ответа, например 200. Если curl сообщает об ошибке с номером 60, сертификат не прошёл проверку: причину покажет код из шага 2.

Шаг 4. Посмотрите, какие файлы указаны в nginx

sudo nginx -T | grep ssl_certificate

Для сертификата Let's Encrypt в строке ssl_certificate должен быть путь к fullchain.pem, а в строке ssl_certificate_key — к privkey.pem, например /etc/letsencrypt/live/example.com/fullchain.pem. Если вместо fullchain.pem указан cert.pem, промежуточного сертификата в настройках нет.

Шаг 5. Проверьте, не тестовый ли сертификат

sudo certbot certificates

Если в строке Expiry Date в скобках стоит INVALID: TEST_CERT, сертификат тестовый.

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

Замените самоподписанный сертификат настоящим

Бесплатный сертификат Let's Encrypt выпускает программа Certbot. Как установить её и получить сертификат, по шагам рассказано в инструкции Бесплатный SSL-сертификат. Не добавляйте в команду ключи --test-cert, --staging и --server: без них Certbot обращается к основному серверу Let's Encrypt и выпускает настоящий сертификат.

Когда Certbot сообщит Successfully received certificate, выполните шаг 4 из раздела «Как проверить»: в строках ssl_certificate должны быть пути к папке /etc/letsencrypt/live/. Если там остались старые пути, укажите новые, как написано ниже, в разделе «Укажите в nginx полную цепочку». Затем повторите шаги 1 и 2: в строке issuer должно быть Let's Encrypt, а код проверки — 0 (ok).

Замените тестовый сертификат

Перевыпустите сертификат на основном сервере Let's Encrypt:

sudo certbot certonly --nginx --cert-name example.com -d example.com -d www.example.com --server https://acme-v02.api.letsencrypt.org/directory --force-renewal

После --cert-name укажите название сертификата из строки Certificate Name (шаг 5), после каждого -d — одно имя сайта. Адрес после --server — основной сервер Let's Encrypt, так он указан в документации Certbot. Ключ --force-renewal выпускает сертификат заново, не дожидаясь окончания срока. Если всё прошло успешно, Certbot напишет Successfully received certificate.

Затем выполните по очереди две команды: первая проверяет настройки nginx, вторая применяет новый сертификат.

sudo nginx -t
sudo systemctl reload nginx

В ответе на первую команду должны быть слова syntax is ok и test is successful. После этого повторите шаг 5: пометки TEST_CERT быть не должно, а в строке Expiry Date — VALID и число дней.

Укажите в nginx полную цепочку

Откройте файл настроек сайта командой sudo nano /etc/nginx/sites-available/example.com, найдите строки ssl_certificate и ssl_certificate_key и укажите в них такие пути:

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

Сохраните файл — Ctrl+O, Enter, затем Ctrl+X — и проверьте настройки:

sudo nginx -t

В ответе должны быть слова syntax is ok и test is successful. Если вместо них сообщение об ошибке, в нём указаны файл и номер строки: исправьте строку и проверьте снова. Когда проверка прошла, примените настройки:

sudo systemctl reload nginx

Если команда ничего не ответила, настройки применены.

Указывайте пути к файлам в папке /etc/letsencrypt/live/ и не копируйте сертификаты в другое место: при продлении Certbot обновляет файлы в этой папке, а копия останется старой.

Платный сертификат: соберите цепочку в один файл

Вместе с купленным сертификатом центр сертификации выдаёт файл с промежуточными сертификатами. nginx нужен один файл, в котором сначала идёт сертификат сайта, а за ним — промежуточные. Перейдите командой cd в папку, где лежат оба файла, и объедините их — имена файлов замените на свои:

sudo sh -c 'cat www.example.com.crt bundle.crt > www.example.com.chained.crt'

Если поставить файлы в обратном порядке, nginx не примет сертификат: команда sudo nginx -t сообщит об ошибке со словами key values mismatch. Укажите новый файл в настройках сайта — путь к папке тоже замените на свой:

ssl_certificate     /etc/nginx/ssl/www.example.com.chained.crt;
ssl_certificate_key /etc/nginx/ssl/www.example.com.key;

После правок сохраните файл — Ctrl+O, Enter, затем Ctrl+X — и проверьте настройки:

sudo nginx -t

Если в ответе есть слова syntax is ok и test is successful, примените настройки:

sudo systemctl reload nginx

На обычном хостинге

Если хостинг выпускает бесплатные сертификаты, включите сертификат в панели управления, в разделе об SSL, — где это у разных хостеров, есть в таблице статьи Бесплатный SSL-сертификат. Купленный сертификат загружайте в панель вместе с промежуточными сертификатами. Если ошибка остаётся, напишите в поддержку адрес сайта и код ошибки.

Соседние ошибки

ОшибкаЧем отличается
NET::ERR_CERT_COMMON_NAME_INVALIDСертификату доверяют, но он выдан для другого имени сайта
NET::ERR_CERT_DATE_INVALIDСрок сертификата истёк или на устройстве неверные дата и время
NET::ERR_CERT_REVOKEDЦентр сертификации отозвал сертификат
ERR_SSL_PROTOCOL_ERRORСервер ответил не так, как требует протокол TLS

Источники

Проверено в Chrome 155 на локальном тестовом сервере 7 октября 2026 года.

Сверено 8 октября 2026 года.

Что почитать дальше

Проверено и обновлено: 08.10.2026