Инвентаризация имён хостов, зависимостей и ответственности
Перечислите каждое имя хоста, которым пользуются посетители или интеграции: apex, www, поддомены, API, хосты для ресурсов, порталы и региональные имена. Для каждого зафиксируйте, где завершается TLS, кто может это изменить, покрытие и срок действия сертификата, метод продления и зависимости, которые формируют URL. Сертификат должен покрывать требуемое имя хоста в списке Subject Alternative Name. Включите CMS, CDN, менеджер тегов, объектное хранилище, платежного провайдера, шаблоны писем и сторонние встраиваемые элементы; они часто вводят HTTP‑URL после первого выпуска по HTTPS.
Выберите каноническое имя хоста — либо www, либо apex — и перенаправляйте альтернативное имя напрямую на него по HTTPS.
Разверните сертификат и текущие версии TLS
Настройте веб‑сервер, обратный прокси, CDN или балансировщик нагрузки, который отвечает на публичные запросы. Установите сертификат и требуемую цепочку, привяжите их к целевым именам и проверьте извне хостинговой сети. Браузер проверяет цепочку, имя хоста и даты; публичное предупреждение блокирует выпуск. По умолчанию используйте TLS 1.3 и сохраняйте TLS 1.2 только там, где требуется совместимость. Отключите SSL и TLS 1.0 и 1.1. Следуйте актуальным рекомендациям платформы, а не скопированному наследуемому списку шифров, и держите сервер и TLS‑библиотеки в патчах.
Ограничьте доступ к приватным ключам и задокументируйте все системы, которые используют один и тот же ключ, чтобы замена была применена ко всем ним.
Перенаправьте HTTP однократно и сделайте HTTPS каноническим
Возвращайте серверный постоянный редирект, обычно 301 или 308, с каждого HTTP‑URL на эквивалентный HTTPS‑URL. Избегайте цепочек: они добавляют задержку и дополнительные точки отказа. Публикуйте канонические HTTPS‑URL во внутренних ссылках, тегах canonical, sitemap, структурированных данных, социальных тегах, письмах и в абсолютных ссылках, генерируемых приложением. Протестируйте главную страницу, глубокую страницу, URL с параметрами, маршруты ошибок и варианты имён хостов. Когда TLS завершается на прокси, настройте доверенную обработку заголовков, указывающих исходный протокол, чтобы приложение не зацикливалось между HTTP и HTTPS.
HTTP может оставаться доступным только для перенаправления или завершения проверки сертификата, но не для обслуживания отдельной публичной версии сайта.
Найдите и исправьте смешанный контент у источника
Смешанный контент — это страница по HTTPS, запрашивающая ресурс по HTTP или другому небезопасному протоколу. Браузеры могут повышать протокол для некоторых медиа, но они блокируют многие рискованные запросы, включая скрипты, таблицы стилей, фреймы, fetch‑вызовы и шрифты. Замените каждую ссылку на проверенный HTTPS‑URL, относительный URL для собственного контента или одобренную альтернативу. Просканируйте репрезентативные шаблоны и исследуйте инструменты разработчика при прохождении ключевых сценариев. Проверьте CSS, JavaScript, блоки CMS, манифесты активов, записи менеджера тегов, загрузки и сторонние встраивания. Безопасная страница не должна предлагать загрузку по HTTP.
Автоматическое повышение протокола в браузере всё ещё может сделать недоступной или неподдерживаемой стороннюю зависимость; исправьте сохранённый URL.
Автоматизируйте продление и отработайте восстановление сертификата
Относитесь к продлению как к автоматизированному развёртыванию, а не к напоминанию в календаре. Оно должно продлевать сертификат, развёртывать его на каждом уровне обслуживания и безопасно перезагружать сервис. Проверяйте тот же маршрут валидации до истечения срока действия сертификата в продакшне. Например, Let’s Encrypt рекомендует продлевать свои 90-дневные сертификаты каждые 60 дней; следуйте жизненному циклу вашего удостоверяющего центра и платформы. Ведите инвентаризацию имён сертификатов, учётной записи у удостоверяющего центра, метода проверки, автоматизации, расположения ключей, целевых систем и экстренных контактов. После развёртывания проверяйте даты на публичной конечной точке.
При сбое продления проверьте DNS, маршрутизацию проверки, права доступа, доступ к учётной записи у удостоверяющего центра, ограничения частоты запросов и развёртывание от CDN до сервера-источника.
Используйте HSTS только после подготовки HTTPS‑инфраструктуры
HTTP Strict Transport Security, или HSTS, — это HTTPS‑заголовок ответа, который сообщает браузерам использовать HTTPS при последующих визитах на хост. После этого браузеры не предлагают посетителям обход для ошибок сертификата. Отправляйте заголовок только по HTTPS и сохраняйте HTTP‑перенаправление, потому что HSTS усваивается после безопасного ответа, если только не применяется список предзагрузки (preload list). Начинайте с ограниченного max‑age и увеличивайте его после подтверждения процессов продления и необходимых маршрутов. Не добавляйте includeSubDomains, пока каждый текущий и будущий поддомен не сможет обслуживать корректный HTTPS. Preload не входит в спецификацию HSTS и требует отдельного долгосрочного обзора обязательств.
max-age=0 работает только после того, как браузер получит действительный HTTPS‑ответ; он не может восстановить недоступный защищённый хост.
Выпускайте, тестируйте и откатывайте без ослабления транспортного уровня
Зафиксируйте проверенную конфигурацию сертификата, edge и перенаправлений до внесения изменений. Определите, кто одобряет откат, используйте стадии там, где возможно, и изменяйте по одному классу управления за раз. Немедленно проверяйте публичные конечные точки из нескольких сетей, следуйте редиректам, проверяйте сертификат и выполняйте важные действия посетителей. Тестируйте браузеры и группы клиентов, важные для вашей аудитории. Для платёжных или регулируемых потоков запросите у платёжного провайдера и у квалифицированного специалиста по безопасности обзор применимых требований. Если изменение нарушает HTTPS, восстановите проверенную безопасную конфигурацию; не переводите страницы клиентов на HTTP как обходной путь.
Фиксируйте имя хоста, время, клиент, ошибку, изменение и результат, чтобы следующее продление или миграция было проще диагностировать.