У нового сертификата может быть правильный срок действия и неподходящее имя домена. Бывает и другая ситуация: сертификат установлен на одном сервере, а часть посетителей попадает на другой. Разберем, как по тексту ошибки и проверке адресов найти причину сбоя HTTPS, не предлагая посетителю отключать защиту браузера.
Не работает сайт по HTTPS: сначала сохраните ошибку
Запишите полный адрес, код предупреждения, время проверки и название браузера. Отдельно укажите, что менялось перед сбоем: продление сертификата, переезд, подключение прокси или домена. Снимок экрана полезен, если на нем читается код, а не только фраза «Подключение не защищено».
Не переходите на сайт через исключение безопасности. Сравните результат на другом устройстве и в другой сети: если сбой затрагивает многие HTTPS-сайты только на одном компьютере, проверять нужно и его окружение. Для разграничения таких ситуаций пригодится разбор ошибок браузера и сайта.
Дата, имя и цепочка: три проверки сертификата
Смотрите сертификат, который действительно получает браузер. Свежий файл у владельца еще не доказывает, что сервер начал отдавать его посетителям. Сверьте начало и конец срока действия, а на устройстве — дату и время: неверные часы тоже могут вызвать предупреждение, как поясняет справка Firefox.
Затем проверьте имена в сертификате: адрес с www и адрес без него должны быть покрыты сертификатом каждый. Маска *.example.com подходит для www.example.com, но сама по себе не покрывает example.com. Наличие нужного имени нельзя заменить совпадением владельца или регистратора домена.
Наконец, проверьте промежуточные сертификаты, связывающие сертификат сайта с доверенным центром. Неполная цепочка может проходить проверку в браузере, где промежуточный сертификат уже сохранен, и давать ошибку в другом. Имена и сборка цепочки описаны в документации nginx. Очистка кеша не исправляет состав цепочки на сервере.
Один домен, несколько сетевых адресов
Составьте список: домен без www, домен с www и другие адреса, которыми пользуются посетители. Для каждого нужны актуальные DNS-ответы и сведения о сервере, куда ведет запрос. После переноса проверяйте не только новый узел, но и оставшиеся адреса старого.
Запись A указывает IPv4-адрес, AAAA — IPv6, а CNAME связывает имя с другим именем; определения есть в справочнике DNS Cloudflare. Поэтому проверка только A недостаточна, если опубликована AAAA. Возможная причина разницы между сетями — разные узлы с разными сертификатами; подтвердить ее нужно сравнением ответов.
На каждом найденном узле администратор проверяет HTTPS именно для нужного доменного имени. Открытие голого IP в браузере не равно проверке сайта: при установлении соединения имя помогает серверу выбрать сертификат через SNI, что объясняет документация nginx.
Где проверять TLS: сервер и прокси
Если сайт сообщает о неподдерживаемом протоколе, проверьте узел, принимающий защищенное соединение. Например, Firefox связывает код SSL_ERROR_UNSUPPORTED_VERSION с устаревшей версией TLS; это описано в справке о сбоях соединения. Повторный выпуск сертификата сам по себе настройки TLS не меняет.
Администратору стоит проверить, доступен ли HTTPS на нужном порту, какой виртуальный хост обслуживает домен и какой сертификат он отдает. При наличии прокси отдельно разбирают соединение посетителя с прокси и соединение прокси с исходным сервером. Исправный сертификат на одном участке не подтверждает исправность другого.
Результатом диагностики должен стать конкретный пункт: какой узел отвечает неверно, что требуется изменить и чем проверить результат. Формулировки «настроить SSL» недостаточно для согласования работ: под ней могут скрываться разные причины и разные исполнители.
Сертификат принят, но страница все равно ломается
Цикл переадресаций проверяют отдельно от ошибки сертификата: фиксируют адреса, между которыми браузер ходит по кругу. Правила прокси и сервера могут противоречить друг другу — например, один участок требует HTTPS, а другой возвращает HTTP. Такой механизм описан в документации Cloudflare о редиректах. Нужно согласовать правила, а не добавлять еще один переход наугад.
Если страница открылась, но не работают стили или сценарии, проверьте ссылки на ее ресурсы. Запросы по HTTP из HTTPS-страницы создают смешанное содержимое: часть браузер переводит на HTTPS, часть блокирует. По документации MDN, такие события видны в консоли браузера. Исправляют адреса ресурсов и проверяют их доступность по HTTPS, а не разрешают небезопасную загрузку посетителям.
Приемка на всех вариантах адреса
После исправления повторите исходные проверки и сохраните результат для каждого варианта. Удобно согласовать короткий список до начала работ:
- HTTP и HTTPS, с www и без него, приводят к выбранному HTTPS-адресу без цикла.
- Все задействованные узлы отдают действующий сертификат для нужного имени с корректной цепочкой.
- Главная и внутренняя страница открываются в разных браузерах и сетях.
- На страницах нет ошибок смешанного содержимого, нужные стили и сценарии загружаются.
Не принимайте работу только по исчезнувшему предупреждению на компьютере исполнителя. Попросите зафиксировать причину, сделанные изменения и порядок дальнейшего продления сертификата; это можно включить в задачи поддержки сайта.
Пришлите адрес, текст предупреждения и дату последних изменений — проверим, где нарушается соединение по HTTPS.