«Ваше подключение не защищено»: что значат коды NET::ERR_CERT и как исправить ошибку

Коротко: «Подключение не защищено» (в старых версиях Chrome — «Ваше подключение не защищено», в английском интерфейсе — Your connection is not private) означает, что сертификат сайта не прошёл одну из проверок Chrome: истёк срок действия (или у вас неверно идут часы), его выпустил центр сертификации, которому Chrome не доверяет, или он выпущен для другого имени. Какая проверка не прошла, говорит код NET::ERR_CERT_… под сообщением. Если вы посетитель, не обходите предупреждение на сайте, где входите в аккаунт или платите. Если вы владелец сайта, почти всегда помогает сертификат Let’s Encrypt, который покрывает все имена сайта, отдаётся вместе с цепочкой и продлевается автоматически.

Само соединение установилось; браузер остановился, потому что не смог подтвердить, кто на другом конце. Сертификат, не прошедший проверку, выглядит для браузера точно так же, как злоумышленник между вами и сайтом, поэтому Chrome начинает со слов «Возможно, злоумышленники пытаются похитить вашу информацию с сайта example.com, например пароли, сообщения и данные кредитных карт», а вкладка называется «Ошибка нарушения конфиденциальности». Firefox пишет «Предупреждение: Вероятная угроза безопасности». Яндекс Браузер вместо страницы показывает предупреждение о том, что невозможно установить безопасное соединение, а в Умной строке — значок «Незащищенное соединение». Edge и Safari выводят похожие страницы (в английском интерфейсе — «Your connection isn’t private» и «This Connection Is Not Private»).

Какой код вы видите?

Chrome выводит код под первым абзацем. Ниже — коды ошибок сертификатов из net_error_list.h Chromium, которые встречаются на практике, и то, что русский Chrome пишет о них после нажатия «Дополнительные настройки». Формулировки взяты из русского перевода Chromium, здесь в сокращении:

Три близкие страницы вызваны тем же, но идут под собственным заголовком:

• Часы отстают или Часы спешат (Your clock is behind, Your clock is ahead): это NET::ERR_CERT_DATE_INVALID, который Chrome связал с часами вашего устройства.
• Подключение к Wi-Fi (Connect to Wi-Fi): сеть гостиницы или аэропорта перехватила соединение, чтобы показать свою страницу входа.
• Приложение не позволяет Chrome безопасно подключиться к этому сайту (An application is stopping Chrome from safely connecting to this site): антивирус, файрвол или программа фильтрации проверяет HTTPS, но её корневой сертификат не установлен. Chrome называет программу.

У Firefox свои коды для тех же сбоев: SEC_ERROR_UNKNOWN_ISSUER, MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, SSL_ERROR_BAD_CERT_DOMAIN и SEC_ERROR_EXPIRED_CERTIFICATE. Яндекс Браузер построен на Chromium, и коды у него те же: его справка пишет их без префикса NET::, например ERR_CERT_AUTHORITY_INVALID, а на странице с предупреждением код стоит слева внизу. Две похожие на вид ситуации — на самом деле другие ошибки. Если страница открывается, но в адресной строке написано «Не защищено», это обычный HTTP или смешанное содержимое, а не сбой сертификата. А Этот сайт не может обеспечить безопасное подключение (This site can’t provide a secure connection) означает, что сломалось само рукопожатие, — об этом наша статья ERR_SSL_PROTOCOL_ERROR.

Стоит ли нажимать «Перейти на сайт (небезопасно)»?

Не на сайте, где вы входите в аккаунт, платите или вводите что-то личное, и никогда в публичном Wi-Fi. Предупреждение не отличает неправильно настроенный сервер от атаки, и вы по странице тоже не отличите. Если у сайта банка недействительный сертификат, закройте вкладку и попробуйте позже из другой сети. Особый случай российских сайтов с сертификатами Минцифры разобран ниже.

На многих крупных сайтах ссылки для перехода нет вовсе. Сайт с HSTS сообщил браузеру, что принимает только действительный сертификат, поэтому Chrome пишет Веб-сайт example.com использует механизм HSTS. Открыть сайт в настоящее время нельзя. (в английском интерфейсе — You cannot visit example.com right now because the website uses HSTS) и пройти дальше не даёт. С отозванным сертификатом то же самое. Это сделано намеренно, это не баг.

В Яндекс Браузере исключение (с теми же оговорками) делается через «Подробнее» → «Сделать исключение для этого сайта». По справке Браузера оно действует 30 дней, а для ERR_CERT_REVOKED его сделать нельзя.

Если ошибку видите только вы

Если сайт открывается на телефоне через мобильный интернет, с сайтом всё в порядке. На устройстве с ошибкой проверьте:

• Дату и время. Сертификаты проверяются по вашим часам. Часы, которые ошибаются на дни, — часто после севшей батарейки CMOS или из-за двух систем на одном компьютере — ломают HTTPS везде. Включите автоматическую установку времени в настройках системы; в Linux timedatectl status должен показывать System clock synchronized: yes, а включает синхронизацию sudo timedatectl set-ntp true.
• Страницу входа в Wi-Fi. В гостиницах, поездах и аэропортах первый запрос перехватывают, чтобы показать условия. Откройте сайт по обычному HTTP, например http://neverssl.com, примите условия на странице входа и повторите.
• Проверку HTTPS в антивирусе, корпоративные прокси, родительский контроль, некоторые VPN. Они подменяют сертификат каждого сайта своим. На сайте, который открывается, нажмите значок слева от адреса, затем Подключение защищено и Действительный сертификат. Если издатель — ваш антивирус, работодатель или учебное заведение, а не публичный УЦ, весь HTTPS-трафик проверяется; для теста отключите проверку защищённых соединений в программе или обратитесь в свой ИТ-отдел. Справка Яндекс Браузера, например, приводит инструкции для Антивируса Касперского, ESET NOD32, Dr.Web и AdGuard.
• Старое устройство. Системы без обновлений не получают новые корневые сертификаты и спотыкаются на сайтах, чей УЦ им неизвестен. Обновите ОС и браузер; на неподдерживаемой системе выручит Firefox, у которого своё хранилище корневых сертификатов.

Очистка кеша и сброс SSL-состояния в свойствах браузера Windows редко что-то меняют: сертификат проверяется заново при каждом подключении. Если ошибка сразу на многих сайтах, виноваты часы или программа-перехватчик; если один сайт не открывается нигде, дело в сайте.

Российские сайты с сертификатами Минцифры

Часть российских сайтов, в том числе банков и государственных сервисов, работает на TLS-сертификатах Национального удостоверяющего центра Минцифры с корнем Russian Trusted Root CA. Яндекс Браузер этому корню доверяет, а Chrome, Edge, Firefox и Safari по умолчанию нет, поэтому Chrome показывает на таких сайтах NET::ERR_CERT_AUTHORITY_INVALID. Сайт при этом настроен так, как задумал владелец; браузер просто не знает этот УЦ.

Варианты: открыть такой сайт в Яндекс Браузере или в официальном приложении сервиса либо установить в систему сертификаты Russian Trusted Root CA и Russian Trusted Sub CA. Скачивайте их только с официальной страницы на Госуслугах, там же инструкции по установке. Учтите, что корневой сертификат в системном хранилище действует для всех сайтов: браузер будет принимать любой сертификат, выпущенный этим УЦ, для любого домена. Это решение о доверии, а не просто исправление ошибки.

Владельцу сайта: посмотрите, какой сертификат отдаёт сервер

Смотрите на то, что сервер действительно отдаёт, причём снаружи, а не на файлы на диске. Первая команда выполняет те же проверки, что и браузер, включая имя хоста; вторая выводит имена, издателя и даты:

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -brief </dev/null 2>&1 | grep -E 'Verification|verify error'

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

Замените каждое example.com на имя, которое не открывается, включая www, если проблема с ним. В macOS сначала установите OpenSSL 3 через Homebrew: встроенный LibreSSL не знает -brief и -verify_hostname. Исправный сайт выводит Verification: OK. Ниже реальные результаты для тестовых хостов badssl.com с OpenSSL 3.0 и код, который Chrome показывает для того же хоста; OpenSSL и curl свои сообщения не переводят:

Наш SSL checker (англ.) выполняет то же рукопожатие из Амстердама и показывает срок действия, совпадение имени, доверена ли цепочка, а также сами сертификаты в том виде, в каком их отдал сервер. За Cloudflare он видит сертификат Cloudflare, а не ваш.

Причина 1: самоподписанный сертификат или заглушка

Свежий сервер часто отвечает по HTTPS сертификатом, которому никто не доверяет: snakeoil-сертификатом из пакета Debian ssl-cert, который использует сайт Apache default-ssl, сертификатом, сгенерированным панелью управления, или сделанным вручную через openssl req -x509. Браузеры отвечают на это NET::ERR_CERT_AUTHORITY_INVALID. Получите настоящий; с nginx и certbot это одна команда, как только DNS-записи указывают на сервер и открыт порт 80:

sudo apt update && sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot получает сертификат, прописывает строки ssl_certificate в подходящий блок server и перезагружает nginx. Перечислите все имена, по которым заходят посетители, каждое со своим -d.

Причина 2: сертификат выпущен для другого имени

NET::ERR_CERT_COMMON_NAME_INVALID означает, что имени из адресной строки нет в списке Subject Alternative Name сертификата. Старое поле Common Name браузеры игнорируют. Вся правда — в строке SAN из команды выше. Для wrong.host.badssl.com она такая:

subject=CN = *.badssl.com
issuer=C = US, O = Let's Encrypt, CN = YR1
notBefore=Sep 29 20:02:56 2026 GMT
notAfter=Dec 28 20:02:55 2026 GMT
X509v3 Subject Alternative Name:
    DNS:*.badssl.com, DNS:badssl.com

Wildcard покрывает ровно одну метку: *.badssl.com подходит для wrong.badssl.com, но не для wrong.host.badssl.com. Типичные случаи на собственном сервере:

• Нет www или голого домена. example.com и www.example.com — два разных имени. Добавьте недостающее: sudo certbot --nginx -d example.com -d www.example.com --expand.
• Сервер открывают по IP. https://203.0.113.10/ не пройдёт проверку с сертификатом на домен. Используйте имя.
• Отвечает не тот блок server. Имя, для которого нет подходящего server_name в блоке на 443, получает сервер nginx по умолчанию и его сертификат. Проверьте, что в нужном блоке есть обе строки listen, для IPv4 и для IPv6.
• DNS указывает в другое место. Старая запись A или AAAA отправляет часть посетителей на прежний хостинг, который отдаёт свой сертификат. Сравните dig +short example.com A и AAAA с адресами своего сервера.

Причина 3: срок действия сертификата истёк

Сертификаты Let’s Encrypt живут 90 дней, и certbot продлевает их примерно за 30 дней до конца срока. Значит, истёкший сертификат говорит о том, что продление не работает уже несколько недель, или оно прошло, но nginx так и не загрузил новый файл. Проверьте и то и другое:

# что certbot хранит на диске и когда истекает срок
sudo certbot certificates

# сработает ли продление сейчас? (через тестовый УЦ, ничего не меняет)
sudo certbot renew --dry-run

# запланирован ли таймер продления? (certbot.timer или snap.certbot.renew.timer)
systemctl list-timers | grep -i certbot

Если файл на диске новее даты, которую отдаёт сервер, перезагрузите nginx: sudo nginx -t && sudo systemctl reload nginx. Сертификаты, установленные с --nginx, перезагружают его сами; с --webroot или --standalone добавьте deploy-хук. Неудачный пробный прогон обычно указывает на закрытый порт 80 или DNS-запись, которая больше не ведёт на этот сервер.

Deploy-хук и более короткие сроки сертификатов Let’s Encrypt начиная с 2027 года разобраны в статье SSL handshake failed (англ.).

Причина 4: сертификат Cloudflare Origin CA без прокси Cloudflare

Сертификату Origin CA от Cloudflare доверяет только Cloudflare. Под оранжевым облаком это нормально: посетители видят пограничный сертификат Cloudflare. Как сказано в документации Cloudflare по Origin CA, посетители получают ошибку недоверенного сертификата, как только вы приостанавливаете Cloudflare или переводите запись в режим DNS only. Это даёт NET::ERR_CERT_AUTHORITY_INVALID, а в поле издателя сертификата стоит CloudFlare Origin SSL Certificate Authority (или его ECC-двойник). Включите прокси обратно или замените сертификат на Let’s Encrypt, который работает в обоих режимах.

Причина 5: нет промежуточного сертификата

Если в nginx указан cert.pem вместо fullchain.pem, сервер отдаёт свой сертификат без промежуточного, который связывает его с доверенным корнем. Настольный Chrome обычно сам докачивает недостающее звено, а Firefox поставляется с известными промежуточными сертификатами, поэтому в вашем браузере сайт часто выглядит нормально, а curl, Python, Java, платёжные вебхуки и некоторые телефоны падают с unable to get local issuer certificate. Исправление — одно слово:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;   # не cert.pem
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Ваши собственные панели управления

Proxmox, Webmin, Cockpit, роутеры и NAS поставляются с самоподписанными сертификатами, так что NET::ERR_CERT_AUTHORITY_INVALID на их портах ожидаем. Вместо того чтобы приучать себя прокликивать предупреждение, заходите на них через SSH-туннель или поставьте их за nginx на настоящем имени с сертификатом Let’s Encrypt и доступом только с вашего IP.

Для https://localhost при разработке используйте mkcert: mkcert -install добавляет локальный УЦ в хранилища доверенных сертификатов системы и браузера, а mkcert localhost 127.0.0.1 ::1 выпускает сертификат, который может загрузить ваш dev-сервер. Флаг allow-insecure-localhost, который советуют старые инструкции, в актуальном Chrome больше не существует.

После исправления

• Команда s_client выше выводит Verification: OK для каждого имени, и голого домена, и www, — с машины вне сервера.
• certbot renew --dry-run проходит успешно, а таймер есть в списке.
• Порты 80 и 443 остаются открытыми: продлению через HTTP-проверку нужен порт 80. Как проверить оба снаружи, показано в нашей статье о портах 443 и 80 (англ.).

На Linux VPS от VMHeaven certbot и nginx вы запускаете от root, а если изменение отрежет вам доступ, VNC-консоль в браузере из личного кабинета всё равно достучится до сервера.

Частые вопросы