Почему браузер пишет «соединение не защищено» на WordPress и как это исправить

|

Если браузер показывает предупреждение «соединение не защищено», это не всегда значит, что SSL-сертификата нет. На WordPress-сайте проблема часто оказывается в другом: сертификат выпущен не на тот домен, истёк, не хватает промежуточного сертификата, часть страниц грузится по HTTP или хостинг отдает неправильную конфигурацию HTTPS. Внешне это выглядит одинаково, но исправляется по-разному.

Для владельца WordPress важно сначала понять, где именно ломается цепочка: на уровне сертификата, настроек сайта, темы, плагинов, CDN или сервера. Если действовать вслепую, можно только усугубить ситуацию — например, включить принудительный редирект на HTTPS до того, как сайт реально начнет открываться по защищенному протоколу.

Что означает предупреждение браузера

Сообщение о небезопасном соединении появляется, когда браузер не может подтвердить, что вы действительно подключились к нужному сайту по защищенному каналу. Для WordPress это обычно означает одну из двух вещей: либо сам TLS-сертификат недействителен, либо страница, открытая по HTTPS, тянет часть ресурсов по HTTP и браузер считает соединение небезопасным.

Если сертификат установлен, но предупреждение все равно есть, не стоит сразу переустанавливать WordPress или менять тему. Сначала проверьте, что именно не нравится браузеру: домен сертификата, срок действия, цепочку доверия или содержимое страницы.

Сначала проверьте сам сертификат

Это самый быстрый способ отделить проблему сертификата от проблемы WordPress. Откройте сайт в браузере, нажмите на значок замка или предупреждения и посмотрите детали сертификата. Важно проверить три вещи:

  • на какой домен выдан сертификат — совпадает ли он с адресом сайта;
  • не истёк ли срок действия;
  • кому и каким центром сертификации он выдан.

Если сертификат выдан, например, только на www.example.ru, а сайт открывается как example.ru, браузер будет ругаться. То же самое бывает при смене домена, переносе сайта на новый адрес или при неправильной настройке поддомена.

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

openssl s_client -connect example.ru:443 -servername example.ru

В выводе смотрят не только сам сертификат, но и цепочку. Если сервер не отдает промежуточные сертификаты, часть браузеров и устройств может считать соединение недоверенным, даже если корневой сертификат нормальный.

Неверный домен — частая причина на WordPress

На WordPress это встречается особенно часто после переезда сайта, смены домена или настройки редиректов. Сертификат может быть выпущен на один вариант адреса, а сайт открывается по другому:

  • сайт работает на site.ru, а сертификат только на www.site.ru;
  • сертификат выпущен на старый домен после переноса;
  • в WordPress в Настройки → Общие указан адрес, который не совпадает с реальным HTTPS-адресом;
  • CDN или прокси отдает другой домен, чем тот, на который выписан сертификат.

Проверьте значения Адрес WordPress (URL) и Адрес сайта (URL). Они должны быть согласованы с тем адресом, по которому сайт реально открывается. Если сайт должен работать и с www, и без него, настройте один основной вариант и сделайте редирект со второго на основной. Иначе браузер будет видеть разные хосты и сертификат может не совпасть.

Просроченный или не продленный сертификат

Если сертификат истёк, браузер покажет предупреждение независимо от того, насколько правильно настроен WordPress. Это типичная ситуация для бесплатных сертификатов, если автообновление не сработало, или для платных сертификатов, если их забыли продлить вручную.

Что делать:

  1. Проверить дату окончания сертификата в браузере или через SSL-проверку.
  2. Посмотреть в панели хостинга, есть ли автообновление.
  3. Если используется Let's Encrypt, убедиться, что задача продления не падает из-за прав доступа, DNS или ограничений панели.
  4. После обновления очистить кэш сайта, CDN и браузера.

На практике проблема часто не в самом сертификате, а в том, что сервер продолжает отдавать старую версию после продления. Тогда WordPress тут ни при чем — нужно обновить конфигурацию на хостинге или в панели управления.

Цепочка доверия и промежуточные сертификаты

Иногда сертификат выпущен корректно, но сервер не отдает промежуточные сертификаты. Браузер не может построить полную цепочку доверия до корневого центра сертификации и показывает ошибку. Это особенно заметно на некоторых конфигурациях хостинга и при ручной установке сертификата.

Если вы ставили сертификат сами, проверьте, что в настройках веб-сервера указан полный chain bundle или fullchain, а не только файл сертификата. Для Let's Encrypt на большинстве серверов нужен именно полный сертификат, а не только cert.pem. В панелях управления хостингом это обычно решается выбором правильного файла или повторной установкой сертификата через мастер.

Если сайт работает у вас, но ошибка появляется у части посетителей, это тоже похоже на проблему цепочки доверия или кэша на стороне CDN/прокси.

Mixed content: когда HTTPS есть, а часть сайта всё ещё грузится по HTTP

Это одна из самых частых причин после перехода WordPress на HTTPS. Сертификат установлен, сайт открывается по защищенному адресу, но браузер всё равно пишет, что соединение небезопасно, или показывает замок с предупреждением. Причина в том, что страница загружает изображения, стили, скрипты, шрифты или iframe по старому HTTP.

На WordPress mixed content обычно появляется из-за старых ссылок в базе данных, жестко прописанных адресов в теме или плагинах, а также из-за внешних ресурсов, которые не поддерживают HTTPS.

Где искать проблему:

  • в записях и страницах — старые ссылки на изображения и файлы;
  • в настройках темы — логотип, фон, шрифты, иконки;
  • в плагинах — скрипты аналитики, слайдеры, формы, виджеты;
  • в базе данных — абсолютные ссылки с http://;
  • в файлах темы — вручную прописанные URL.

Проверить mixed content можно в консоли браузера: откройте инструменты разработчика и посмотрите ошибки и предупреждения на вкладке Console или Network. Если там есть запросы к http://, именно они и ломают чистый HTTPS.

Исправление обычно состоит из двух шагов: заменить старые URL в базе данных и убрать жестко прописанные HTTP-ссылки в теме или плагинах. Для массовой замены лучше использовать инструмент, который умеет безопасно искать и заменять значения в базе WordPress с учетом сериализованных данных. Перед этим обязательно сделайте резервную копию базы.

Что проверить в WordPress после перехода на HTTPS

Даже если сертификат уже работает, WordPress может продолжать отдавать старые адреса или создавать конфликт редиректов. Проверьте:

  • в Настройки → Общие оба адреса сайта указаны с https://;
  • в админке нет смешанных ссылок на медиафайлы и страницы;
  • в теме не прописаны абсолютные HTTP-адреса;
  • плагины кэша не отдают старую версию страниц;
  • CDN тоже настроен на HTTPS и не подменяет сертификат.

Если вы используете плагин кэша или оптимизации, после смены протокола очистите весь кэш: WordPress, серверный кэш, CDN и браузерный. Иначе браузер может продолжать видеть старые ресурсы и старые редиректы.

Когда проблема на стороне хостинга или CDN

Если сертификат установлен в панели хостинга, но браузер все равно показывает ошибку, причина может быть в серверной конфигурации. Такое бывает, когда:

  • на 443 порту отдается не тот виртуальный хост;
  • подключен старый сертификат вместо нового;
  • сервер не использует актуальную цепочку сертификатов;
  • CDN, например Cloudflare, работает в режиме, который не совпадает с настройками origin-сервера;
  • хостинг не завершил выпуск или привязку сертификата после продления.

Если сайт стоит за CDN, проверьте режим SSL на стороне CDN и на стороне origin. Неправильная комбинация часто приводит к циклическим редиректам, ошибкам сертификата или предупреждению в браузере. Для WordPress это особенно заметно, если в админке включен HTTPS, а CDN продолжает обращаться к серверу по HTTP или с неверным SNI.

Практический порядок диагностики

Чтобы не гадать, идите по этому порядку:

  1. Откройте сайт в браузере и посмотрите, что именно пишет предупреждение.
  2. Проверьте домен, срок действия и издателя сертификата.
  3. Сравните адрес сайта в WordPress и фактический URL.
  4. Посмотрите консоль браузера на наличие mixed content.
  5. Проверьте, не мешают ли кэш, CDN или прокси.
  6. Если нужно, переустановите сертификат на хостинге с полным chain/fullchain.

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

Как проверить, что HTTPS действительно исправлен

После правок откройте сайт в режиме инкогнито и проверьте несколько страниц: главную, запись, страницу с изображением, форму обратной связи и, если это магазин, карточку товара и корзину. Замок в браузере должен быть без предупреждений, а в консоли не должно быть запросов к http://.

Дополнительно проверьте, что:

  • все версии домена ведут на один основной HTTPS-адрес;
  • старый HTTP-адрес редиректит на HTTPS без цепочек из нескольких переходов;
  • админка WordPress открывается по HTTPS;
  • в письмах, шаблонах и кнопках нет старых HTTP-ссылок.

Если сайт коммерческий, не ограничивайтесь только замком в браузере. HTTPS нужен для защищенного соединения, но он не заменяет обновления WordPress, контроль прав доступа, резервные копии и защиту от уязвимых плагинов и тем.

Когда предупреждение «соединение не защищено» появляется на WordPress, в большинстве случаев причина находится в одном из пяти мест: домен, срок действия сертификата, цепочка доверия, mixed content или конфигурация хостинга/CDN. Если проверить их по порядку, проблему обычно можно найти без лишних экспериментов и без риска сломать сайт окончательно.

⭐⭐⭐⭐⭐