Браузер пишет: подключение не защищено. Что это значит владельцу сайта
Откуда берётся предупреждение о незащищённом подключении, чем оно отличается от заражения, как проверить сертификат и убрать ошибку за час.
Содержание
Предупреждение про незащищённое подключение в девяти случаях из десяти означает проблему с сертификатом, а не взлом. Истёк, выпущен не на то имя, не отдаётся промежуточный или сломалось автопродление. Чинится за 10-30 минут, платить чаще всего не надо.
Владелец заходит на свой сайт, а вместо главной видит серую страницу и текст о том, что подключение к сайту не защищено. Дальше обычно два вопроса подряд: меня взломали и сколько заявок я уже потерял. Отвечаю сразу: в девяти случаях из десяти это сертификат, а не взлом, и чинится оно за полчаса вместе с чаем. Разберу, что именно говорит браузер разными формулировками, чем это предупреждение отличается от блокировки за вирусы, как найти причину пятью строчками в терминале и что обязательно проверить после того, как замок вернулся на место.
Я веду абонентское обслуживание сайтов шесть лет, и просроченный сертификат стабильно держится в тройке самых частых аварийных звонков. Хорошая новость: причин у этой ошибки всего четыре с половиной, и они различаются одной командой.
Что именно говорит браузер
Формулировка «подключение не защищено» это обёртка над техническим кодом ошибки. Сам код гораздо полезнее, потому что он сразу называет причину. В Chrome и Яндекс Браузере его видно после нажатия на «Дополнительные», в Firefox после «Подробнее», в Safari текст сразу более многословный.
| Код ошибки | Что произошло | Кто виноват |
|---|---|---|
| NET::ERR_CERT_DATE_INVALID | Срок действия сертификата закончился (или ещё не начался) | Сломалось автопродление |
| NET::ERR_CERT_COMMON_NAME_INVALID | Сертификат выписан на другое имя | Сертификат на www без основного домена или наоборот |
| NET::ERR_CERT_AUTHORITY_INVALID | Браузер не доверяет издателю | Самоподписанный сертификат или не отдаётся промежуточный |
| SEC_ERROR_UNKNOWN_ISSUER | То же самое в Firefox | Чаще всего порванная цепочка |
| ERR_SSL_PROTOCOL_ERROR | Сервер вообще не смог договориться по TLS | Порт 443 не настроен, сайт живёт только по http |
| ERR_CERT_REVOKED | Сертификат отозван | Редкость, обычно после утечки ключа или смены владельца |
Отдельная строчка про даты: браузер сравнивает срок действия с системными часами компьютера. Если у клиента на ноутбуке сбилась дата на два года вперёд, он увидит ERR_CERT_DATE_INVALID на половине интернета, включая ваш сайт. Прежде чем поднимать панику, спросите, открывается ли у него Госуслуги и Яндекс. Если тоже нет, чинить надо часы, а не сайт.
Чем это отличается от «опасного сайта»
Их путают постоянно, и путаница дорого стоит: владелец начинает искать вирусы там, где надо просто перевыпустить сертификат, и наоборот.
Предупреждение о незащищённом подключении выдаёт сам браузер, локально, на основании того, что он увидел при установке соединения. Никакая внешняя база при этом не участвует. Страница обычно серая или белая, замок перечёркнут, есть кнопка «Дополнительные» и возможность перейти на свой страх и риск.
Предупреждение о заражении выдаёт база Safe Browsing у Google или антивирус Яндекса. Страница красная во весь экран, текст про обманный сайт или про угрозу вашему компьютеру, перейти обычно можно только через несколько кликов в глубине настроек. Это уже репутационная история: сайт попал в чужой список, и убрать оттуда его можно только через Search Console или Вебмастер, после реальной чистки. Про эту ситуацию у меня есть отдельный разбор в статье про то, что делать, когда браузер пишет «опасный сайт».
Простое правило для владельца: серое окно с замком это техника, красный экран во весь монитор это безопасность. Если после починки сертификата предупреждение не ушло, а поменяло цвет, значит проблем было две, и вторая серьёзнее. Тогда идите по признакам взлома и смотрите логи.
Пять минут диагностики
Все онлайн-чекеры сертификатов делают ровно то, что делает одна команда. Разница в том, что команду можно запустить с любого компьютера, где есть терминал, и она не соврёт про кэш.
openssl s_client -connect example.ru:443 -servername example.ru </dev/null 2>/dev/null
| openssl x509 -noout -subject -issuer -datesОтвет выглядит так:
subject=CN = example.ru
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=May 18 09:12:44 2026 GMT
notAfter=Aug 16 09:12:43 2026 GMTТри строчки закрывают три причины из четырёх. subject показывает, на какое имя выписан сертификат. issuer показывает издателя: если там ваш собственный домен или слово Self-signed, сертификат никем не подтверждён. notAfter показывает дату окончания, сравните её с сегодняшней.
Ключ -servername обязателен. Без него вы обращаетесь к серверу без указания домена, и на shared-хостинге получите сертификат-заглушку самого хостера, после чего полчаса будете чинить несуществующую проблему.
Второй командой проверяется цепочка:
openssl s_client -connect example.ru:443 -servername example.ru </dev/null 2>&1
| grep -E "Verify return code"Verify return code: 0 (ok) означает, что всё в порядке. Код 21 (unable to verify the first certificate) означает, что сервер не отдаёт промежуточный сертификат. Коварство в том, что на вашем компьютере сайт при этом может открываться нормально: браузер уже подтянул нужный промежуточный ранее и держит его в кэше. А у клиента с чистой системы будет ошибка. Именно поэтому нельзя проверять фразой «у меня открывается».
Третья проверка нужна, когда домен есть в двух написаниях:
for h in example.ru www.example.ru; do
echo "== $h"
openssl s_client -connect $h:443 -servername $h </dev/null 2>/dev/null
| openssl x509 -noout -subject -dates
doneКлассика жанра: сертификат выпущен на example.ru, а реклама и визитки ведут на www.example.ru. Половина посетителей видит предупреждение, владелец не видит никогда, потому что у него в закладке правильный вариант.
Если под рукой нет терминала, тот же результат даёт curl -svo /dev/null https://example.ru (сертификат и цепочка будут в выводе) или онлайн-сервис вроде SSL Labs. Онлайн-сервисы медленнее и кэшируют результат, но для владельца без консоли сойдут.
Четыре типовые причины и что делать с каждой
Сертификат просто истёк
Самый частый случай, процентов шестьдесят от всех обращений. Let’s Encrypt живёт 90 дней, автопродление настраивается один раз и потом молча ломается через полгода. Поводы для поломки всегда одни и те же:
- редирект на https повесили на весь сайт целиком, и проверочный запрос по
/.well-known/acme-challenge/уходит в 301 вместо файла, - плагин безопасности или правило в
.htaccessотдают 403 всем клиентам без нормального user-agent, включая бота удостоверяющего центра, - сменили IP или переехали на другой хостинг, а DNS ещё указывает на старый сервер,
- крон-задание certbot отключилось вместе с обновлением панели хостинга.
Проверить путь проверки можно за секунду, до всякого перевыпуска:
curl -I http://example.ru/.well-known/acme-challenge/testПравильный ответ здесь 404 Not Found. Ответ 301 или 403 означает, что бот не сможет положить туда файл, и никакой перевыпуск не пройдёт, пока это не поправлено. Лечится исключением в самом верху .htaccess, до всех остальных правил:
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/.well-known/acme-challenge/ [NC]
RewriteRule ^ - [L]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]После этого сертификат выпускается из панели хостинга в два клика или командой certbot renew --force-renewal на своём сервере. У большинства российских хостингов бесплатный Let’s Encrypt встроен в панель, включается тумблером и продлевается сам. Подробный разбор вариантов выпуска я собрал в статье про бесплатный SSL-сертификат.
Сертификат выписан на другое имя
Тут два подслучая. Первый: сертификат только на голый домен, а сайт открывается с www (или зеркально). Лечится перевыпуском сразу на оба имени, в Let’s Encrypt это два ключа -d:
certbot certonly --webroot -w /var/www/example.ru
-d example.ru -d www.example.ruВторой подслучай: домен переехал, а сертификат остался от старого. Видно по полю subject, там будет чужое имя. Просто перевыпустить на актуальный домен.
Отдельно про поддомены. Сертификат на example.ru не покрывает shop.example.ru. Нужен либо отдельный сертификат на каждый поддомен, либо wildcard на *.example.ru. Wildcard от Let’s Encrypt бесплатный, но требует подтверждения через DNS-запись, а не через файл, и потому автопродление у него настраивается сложнее. Платный wildcard в 2026 году стоит порядка 4 000-7 000 рублей в год, и его единственное преимущество это отсутствие возни с DNS-хуками.
Порванная цепочка
Сервер обязан отдавать не только сертификат домена, но и промежуточный сертификат издателя. Если в конфиге nginx указан cert.pem вместо fullchain.pem, цепочка рвётся. У Apache та же беда, когда SSLCertificateChainFile не заполнен.
ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;Диагностируется тем самым Verify return code: 21. Правится одной буквой в пути и перезапуском веб-сервера. У клиентов на shared-хостинге эта причина встречается редко, потому что панель сама подставляет полную цепочку.
Сертификата нет вообще
Самоподписанный сертификат, заглушка хостера или голый http, на который браузер сам дописал https. Владелец при этом обычно уверен, что сертификат есть, потому что когда-то давно кто-то его ставил. Смотрим issuer: если в нём ваш собственный домен, имя сервера или что-то вроде «Internal CA», доверия к такому сертификату нет ни у одного браузера, и добавление исключения на своём компьютере проблему для клиентов не решает.
Сводка по всем четырём в одну таблицу:
| Что видно в проверке | Причина | Действие | Время |
|---|---|---|---|
| notAfter в прошлом | Истёк, автопродление сломано | Починить путь acme, перевыпустить | 15-30 минут |
| subject не совпадает с доменом | Выпущен на www или на старое имя | Перевыпуск с обоими именами | 10-20 минут |
| Verify return code: 21 | Не отдаётся промежуточный | fullchain вместо cert, рестарт | 10 минут |
| issuer это ваш домен | Самоподписанный или заглушка | Выпустить нормальный из панели | 15 минут |
| Соединение вообще не встаёт | 443 не слушается, нет конфига | Настроить https на сервере | от часа |
Редирект на https без петли
После починки сертификата остаётся закрепить результат: заставить сайт всегда работать по https. Здесь чаще всего и ловят вторую аварию за день, петлю редиректов с ошибкой ERR_TOO_MANY_REDIRECTS.
Механика петли простая. Многие хостинги терминируют TLS на своём балансировщике, а до вашего Apache трафик доходит уже обычным http. Условие %{HTTPS} !=on в этом случае истинно всегда, и сайт бесконечно редиректит сам на себя. Лечится проверкой заголовка от прокси:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Второй источник петли живёт в самой CMS. У WordPress в базе есть siteurl и home. Если там прописан http, а сервер редиректит на https, WordPress честно возвращает пользователя обратно на http, и круг замыкается. Проверяется и правится так:
wp option get siteurl
wp option get home
wp option update siteurl 'https://example.ru'
wp option update home 'https://example.ru'Когда админка уже недоступна из-за петли, те же значения правятся напрямую в wp-config.php строками define('WP_HOME', 'https://example.ru'); и define('WP_SITEURL', 'https://example.ru');. Это переопределит базу и вернёт вход.
Проверить цепочку редиректов после правок:
curl -sIL http://example.ru | grep -E "^HTTP|^[Ll]ocation"Здоровый результат: один 301 с http на https и следом 200. Если видите два и больше переходов подряд или чередование www и не-www, правила стоят в неправильном порядке.
Про HSTS отдельно
HSTS это заголовок, который говорит браузеру: следующий год ходи на этот домен только по https, даже не пробуй http. Штука полезная, но с острыми краями: пока max-age не истечёт, откатиться обратно на http нельзя никак, браузер посетителя вам просто не поверит.
Header always set Strict-Transport-Security "max-age=300"Начинайте с пяти минут, поживите неделю, убедитесь, что все поддомены и все страницы работают по https, и только потом поднимайте до года:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"Директиву preload не добавляйте без крайней нужды. Она зашивает ваш домен в списки, встроенные прямо в браузеры, и удаление оттуда занимает месяцы. Я видел сайт, который после смены хостинга неделю лежал у части посетителей именно из-за preload и незакрытого поддомена.
Что проверить после того, как замок вернулся
Ошибка ушла, замок на месте, и здесь большинство останавливается. А зря: половина неприятностей вылезает через неделю.
- Смешанный контент. Замок может стать серым вместо зелёного, если часть картинок и скриптов грузится по http. Ищите в консоли браузера строки Mixed Content, а в базе прогоняйте
wp search-replace 'http://example.ru' 'https://example.ru' --precise --report-changed-onlyсначала с ключом--dry-run. - Карта сайта. В
sitemap.xmlадреса должны быть с https, иначе поисковик получает набор редиректов вместо страниц. Как её проверить и чем генерировать, я разбирал в материале про карту сайта sitemap.xml. - Главное зеркало в Яндекс Вебмастере и основной адрес в Search Console. Если там остался http, отчёты продолжают жить отдельной жизнью.
- Формы заявок. Проверить руками отправку с телефона: обработчик формы иногда прибит гвоздями к http-адресу, и после переезда молча перестаёт доставлять письма.
- Счётчик Метрики. Проверить, что цели по-прежнему срабатывают, а не считают ноль с момента переключения.
- Кэш. И серверный, и в плагине, и на CDN. Старые страницы с http-ссылками внутри живут в кэше сутками, а вы будете думать, что ничего не помогло.
- Внешние интеграции. Вебхуки, обмен с 1С, эквайринг, платёжные уведомления. У всего этого адрес прописан в чужой панели, и никто его за вас не поменяет.
Как больше не узнавать об этом от клиента
Сертификат истекает по расписанию, а значит про это можно узнать заранее. Самый дешёвый вариант это одна строчка в кроне, которая раз в сутки проверяет остаток срока и молчит, пока всё нормально:
echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null
| openssl x509 -noout -checkend 1209600
|| echo "Сертификат example.ru истекает меньше чем через 14 дней"checkend 1209600 это две недели в секундах. Команда возвращает ошибку, когда срока осталось меньше, крон отправляет вывод на почту или в Telegram-бота. Из готовых сервисов срок сертификата умеет отслеживать UptimeRobot (бесплатно до 50 адресов) и Pinger PRO (в районе 350 рублей в месяц), но своя строчка в кроне надёжнее, потому что не зависит от чужого тарифа.
Две недели это не запас ради красоты. Ровно столько нужно, если автопродление сломалось из-за смены IP или заблокированного пути проверки: успеваете разобраться спокойно, а не в субботу вечером под звонки.
Сколько это стоит
Сам сертификат для типового сайта услуг стоит ноль рублей: Let’s Encrypt бесплатен, в панели любого нормального хостинга включается тумблером, продлевается сам. Платный DV-сертификат в 2026 году обойдётся в 900-2 000 рублей в год и не даёт ничего, кроме строчки в договоре, если вам её кто-то требует. Смысл платить есть только за wildcard без возни с DNS-хуками или за сертификат с проверкой организации, где название юрлица видно в свойствах сертификата.
Разовая починка у подрядчика это работа на час-полтора: диагностика, перевыпуск, редирект, проверка смешанного контента. Дальше вопрос в том, кто следит за сроком в следующий раз. В абонентском обслуживании мониторинг сертификата входит в базу и отдельно не считается, тарифы начинаются от 15 000 рублей в месяц при помесячной оплате и 35 000 рублей за год.
И трезвая оценка убытка, раз уж про деньги. Пока висит предупреждение, отказы на входе стремятся к сотне процентов: обычный человек не жмёт «Перейти на свой страх и риск», он закрывает вкладку. Реклама в Директе при этом продолжает откручиваться, потому что для системы сайт формально доступен. Сутки такой ситуации у сайта услуг со средним чеком 20 000 рублей стоят дороже, чем год обслуживания.
Если сертификат уже отвалился и разбираться некогда, напишите через форму на главной: по опыту, диагностика занимает пять минут, а починка редко выходит за час.
Частые вопросы
Что значит подключение к сайту не защищено
Браузер не смог проверить сертификат: он истёк, выпущен на другое имя или цепочка неполная. Содержимое сайта при этом не тронуто, и это не то же самое, что предупреждение об опасном сайте.
Почему сертификат истёк, если стоит автопродление
Бесплатный сертификат живёт 90 дней, и продление ломается чаще, чем кажется: сменился путь для проверки, добавился редирект, поменялись права на папку. Проверять надо сам механизм продления, а не выпускать вручную.
Надо ли покупать платный сертификат
Обычно нет. Бесплатный закрывает и сайт услуг, и магазин. Платный вариант на все поддомены стоит порядка 4-7 тысяч рублей в год и нужен, когда поддоменов много.
Что проверить после того, как замок вернулся
Что сайт открывается и с www, и без, что все внутренние ссылки идут по защищённому протоколу, что нет петли редиректов и что автопродление действительно отработает через три месяца.
