Почему после установки SSL-сертификата безопасности всё ещё отображается предупреждение о небезопасном соединении?

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

При диагностике не следует ограничиваться проверкой того, «куплен ли сертификат и загружен ли он». Ориентируйтесь на сертификат, который фактически получает браузер, цепочку доступа и ресурсы страницы: сначала определите тип ошибки, затем проверьте домен, цепочку сертификатов, порт и правила перенаправления, после чего устраните смешанное содержимое. Это позволит избежать многократной замены сертификата без решения проблемы.

Сначала изучите уведомление браузера, чтобы определить уровень возникновения проблемы

Нажмите на уведомление «Небезопасно» или значок замка в адресной строке браузера, чтобы просмотреть сведения о сертификате и конкретный текст ошибки. Разные проявления требуют разных направлений проверки.

Консоль браузера также имеет большое значение. Если в консоли отображается «Mixed Content», это означает, что основная страница открыта по HTTPS, но некоторые ее ресурсы по-прежнему запрашиваются по HTTP. Если отображается ошибка имени сертификата или сбой проверки цепочки сертификатов, необходимо вернуться к проверке развертывания на сервере.

Несоответствие домена — проблема, которую легче всего упустить после установки SSL-сертификата

Сертификат действителен только для перечисленных в нем доменов и не покрывает автоматически все варианты. Например, если сертификат выпущен только для www.example.com, при прямом переходе на example.com по-прежнему может возникать ошибка. Обычный однодоменный сертификат, выпущенный для основного домена, также обычно не покрывает такие поддомены, как shop.example.com и en.example.com.

Проверьте «Subject Alternative Name (SAN)» или «Альтернативное имя субъекта» в сведениях о сертификате и сопоставьте каждый пункт с фактическими точками входа. Как минимум необходимо убедиться в следующем:

• Покрыты ли домены с www и без www, либо настроено ли единое перенаправление;
• Используют ли многоязычный сайт, под-сайт интернет-магазина, сайт загрузок, административная панель и другие разделы отдельные поддомены;
• Могут ли пользователи получать прямой доступ через старый домен, тестовый домен или IP-адрес;
• Развернут ли сертификат в привязке домена или конфигурации виртуального хоста, которые в настоящее время обслуживают внешний трафик.

Не пытайтесь скрыть несоответствие имени, «перенаправив все домены на HTTPS». Перенаправление выполняется после TLS-рукопожатия: браузер сначала должен проверить сертификат текущего домена, поэтому при несовпадении имени предупреждение все равно появится. Правильный подход — расширить покрытие сертификата для фактических точек входа либо унифицировать домены на уровне DNS, входа на сайт и рекламных ссылок.

При отсутствии цепочки сертификатов сервер может выглядеть настроенным, но клиент не сможет выполнить проверку

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

В среде Nginx распространенная проблема заключается в том, что ssl_certificate указывает на отдельный файл сертификата, а не на файл полной цепочки, включающий серверный и промежуточные сертификаты. В Apache необходимо убедиться, что соответствующая конфигурация цепочки сертификатов соответствует требованиям текущей версии. В средах с панелью управления используйте предоставленный центром сертификации файл «полной цепочки сертификатов», «fullchain» или «CA Bundle», а не вставляйте только первый блок сертификата.

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

HTTPS включен: почему страница по-прежнему отображается как небезопасная

Такая ситуация чаще всего связана со смешанным содержимым. HTML страницы передается по HTTPS, но адреса изображений, JavaScript, CSS, видео, шрифтов, кодов статистики, iframe или интерфейсов по-прежнему указаны как http://. Современные браузеры напрямую блокируют часть активного содержимого, например скрипты и XHR-запросы; при этом загрузка некоторых изображений или медиаресурсов может быть разрешена, но статус безопасности будет понижен.

Начинать следует с исходного кода страницы и консоли браузера: найдите конкретный адрес ресурса, затем проверьте источник ресурса:

1. Статические ресурсы сайта следует перевести на абсолютные HTTPS-адреса или использовать относительные пути, подходящие для текущего сайта;
2. Необходимо массово проверить жестко прописанные HTTP-ссылки в шаблонах, материалах в формате rich text, описаниях товаров и архивных статьях;
3. Следует убедиться, что сторонние скрипты, карты, окна поддержки, встраиваемые видео и компоненты форм поддерживают HTTPS;
4. Для доменов API, хранения файлов и CDN изображений также должны быть развернуты действительные сертификаты; недостаточно изменить только домен главной страницы;
5. После внесения изменений очистите кеш сайта, кеш CDN и кеш браузера, затем проведите повторное тестирование.

Не рекомендуется полагаться только на стратегию браузера «автоматически обновлять небезопасные запросы». Она может использоваться как временная мера, но не гарантирует корректную загрузку всех ресурсов; если сторонний ресурс не поддерживает HTTPS, это по-прежнему может привести к отсутствию стилей, сбоям функций или ошибкам запросов данных.

Проверьте прослушивание сервера, перенаправления и конфигурацию нескольких узлов

Корректный сертификат не означает, что порт 443 уже обслуживается нужным сайтом. Убедитесь, что брандмауэр сервера, группа безопасности и веб-сервис разрешают доступ к порту 443, а к этому порту привязан сертификат, соответствующий целевому домену. В средах с общим IP и несколькими сайтами ошибка конфигурации SNI может привести к тому, что сервер вернет сертификат другого сайта, что вызовет несоответствие домена.

Следует также проверить перенаправление с HTTP на HTTPS. В идеальном случае после доступа к версии http:// выполняется одно перенаправление 301 или 308 на канонический HTTPS-адрес. Не допускайте циклов, при которых HTTP перенаправляется на HTTPS, а HTTPS снова на HTTP, и не позволяйте разным страницам постоянно перенаправляться между вариантами с www и без www. Страницу входа, страницу отправки формы, страницу обратного вызова платежа и вход в административную панель особенно важно проверять отдельно.

Если перед сайтом используются CDN, балансировщик нагрузки или обратный прокси, необходимо отдельно проверить сертификаты пограничных узлов и исходного сервера. Если пограничный узел работает корректно, а исходный сервер неисправен, некоторые сценарии обращения к источнику могут завершаться ошибкой; если исходный сервер уже обновлен, но CDN все еще хранит старый сертификат, внешние посетители также могут увидеть не новый сертификат. При двухстековом разрешении IPv4 и IPv6 необходимо протестировать узлы, соответствующие обоим типам адресов.

Как избежать повторного возникновения ошибки «только что продлили, но снова появилась ошибка»

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

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