Домен, порт и точка отсчёта
HTTPS не начинается с сертификата. Он начинается с того, что домен должен указывать на сервер, а не на заглушку хостинга или страницу регистратора. Если домен не привязан к серверу, выпуск сертификата через проверку по HTTP-01 не состоится: запросы к .well-known/acme-challenge будут уходить в пустоту, и центр сертификации не сможет подтвердить контроль над доменом.
Открытый порт 80 нужен только для проверки домена. Сам сервер приложения может слушать любой порт — проверка идёт по внешнему адресу. Если сервер за обратным прокси, порт 80 должен быть открыт на прокси, а не на сервере приложения. Прокси должен передавать запросы к .well-known/acme-challenge на сервер, иначе выпуск сертификата не состоится. Если прокси не настроен на пропуск таких запросов, единственный выход — выпуск сертификата через DNS-запись, если провайдер поддерживает API для этого.
Сертификат: выпуск, проверка и обновление
Выпуск сертификата через сайт — самый распространённый способ, но не единственный. Для него нужен открытый порт 80, потому что проверка домена через HTTP-01 требует, чтобы сервер ответил на запрос к .well-known/acme-challenge с определённым содержимым. Если порт закрыт или прокси не пропускает такие запросы, выпуск не состоится.
После выпуска сертификата его нужно проверить не по дате в календаре, а по факту. Для этого можно запросить его через openssl s_client -connect example.com:443 -showcerts и убедиться, что в ответе присутствуют все сертификаты цепочки: корневой, промежуточный и конечный. Если промежуточный сертификат отсутствует, браузеры не доверят соединению, даже если конечный сертификат выпущен корректно. Это связано с тем, что браузеры проверяют цепочку доверия: они должны убедиться, что конечный сертификат подписан доверенным центром, а для этого им нужен промежуточный сертификат.
Обновление сертификата должно происходить автоматически. Если этого не сделать, через три месяца (или год, в зависимости от провайдера) соединение перестанет работать. Проверить, что обновление действительно происходит, можно через логи сервера или journalctl: там должны быть записи о успешном обновлении. Если таких записей нет, сертификат истечёт, и сайт станет недоступным по HTTPS.
Перенаправление: одно правило вместо четырёх
Перенаправление с HTTP на HTTPS должно быть постоянным (301), а не временным (302). Это важно для поисковых систем: постоянное перенаправление сохраняет рейтинг страницы, а временное — нет. Если использовать временное перенаправление, поисковые системы будут считать, что HTTPS — это временное решение, и не будут индексировать страницы по защищённому протоколу.
Перенаправление должно работать для всех вариантов адреса:
http://example.com→https://example.comhttp://www.example.com→https://example.comhttps://www.example.com→https://example.com
Но это одно правило, а не четыре. Достаточно перенаправить все запросы на https://example.com, и браузер сам разберётся с остальными вариантами. Если перенаправление не настроено, пользователи будут видеть предупреждения о незащищённом соединении, даже если сертификат выпущен. Это связано с тем, что браузеры по умолчанию пытаются открыть сайт по HTTP, если не указано иное.
Перенаправление должно быть постоянным, потому что временное перенаправление не сохраняет рейтинг страницы в поисковых системах. Кроме того, временное перенаправление может вызвать проблемы с кэшированием: браузеры и прокси-серверы могут не кэшировать временные перенаправления, что приведёт к дополнительным запросам и замедлению работы сайта.
Обратный прокси и заголовки безопасности
За обратным прокси приложение не знает, что соединение защищено. Оно видит только внутренний адрес прокси, а не внешний HTTPS. Из-за этого в письмах и перенаправлениях могут появляться ссылки на http://, а не https://. Это происходит потому, что приложение формирует ссылки на основе информации, которую получает от прокси, а прокси передаёт внутренний адрес и протокол.
Чтобы исправить это, прокси должен передавать заголовок X-Forwarded-Proto: https. Приложение должно проверять этот заголовок и формировать ссылки с учётом протокола. Если заголовок не передаётся, приложение будет считать, что соединение незащищённое, и генерировать ссылки на http://. Это может привести к тому, что пользователи будут получать письма со ссылками на незащищённый протокол, или приложение будет перенаправлять их на http:// вместо https://.
Кроме того, прокси должен передавать заголовок X-Forwarded-For, чтобы приложение знало реальный IP-адрес клиента. Без этого заголовка приложение будет видеть только IP-адрес прокси, что может вызвать проблемы с логированием и безопасностью.
Строгий транспорт: почему включают последним
Строгий транспорт (HSTS) — это заголовок, который говорит браузеру: «Этот сайт всегда должен открываться по HTTPS». Но включать его нужно последним, после того как всё остальное работает. Если включить HSTS рано, а сертификат не обновлён или перенаправление не настроено, пользователи не смогут зайти на сайт даже по HTTP.
HSTS действует долго: браузер запоминает его на срок, указанный в заголовке. Если что-то пойдёт не так, исправить это будет сложно. Например, если сертификат истечёт, а HSTS включён, браузеры не позволят пользователям зайти на сайт даже по HTTP, пока не истечёт срок действия HSTS. Поэтому перед включением HSTS нужно убедиться, что:
- сертификат выпущен и обновляется автоматически;
- перенаправление с HTTP на HTTPS работает;
- все внутренние ссылки используют HTTPS.
Кроме того, HSTS должен включаться с параметром includeSubDomains, чтобы защитить все поддомены. Если этого не сделать, злоумышленники могут атаковать поддомены, которые не защищены HSTS.
Как убедиться, что всё сделано
Проверить настройку HTTPS можно по цепочке шагов:
-
Цепочка сертификатов: запросить сертификат через
openssl s_client -connect example.com:443 -showcertsи убедиться, что в ответе есть все сертификаты цепочки: корневой, промежуточный и конечный. Если промежуточный сертификат отсутствует, браузеры не доверят соединению. -
Перенаправления: открыть
http://example.comиhttp://www.example.comв браузере и убедиться, что они перенаправляются наhttps://example.com. Проверить, что перенаправление постоянное (301), а не временное (302). Для этого можно использовать инструменты разработчика в браузере илиcurl -v http://example.com. -
Смешанное содержимое: открыть страницу в браузере и проверить консоль на предупреждения о незащищённом контенте. Если на странице есть ссылки на
http://, их нужно исправить. Это может быть связано с тем, что приложение формирует ссылки без учёта протокола, или прокси не передаёт заголовокX-Forwarded-Proto. -
HSTS: проверить, что заголовок
Strict-Transport-Securityприсутствует в ответе и содержитmax-ageне менее года. Для этого можно использоватьcurl -I https://example.comили инструменты разработчика в браузере. Убедиться, что заголовок включаетincludeSubDomains, если это необходимо. -
Обновление сертификата: проверить логи сервера или
journalctlна наличие записей о успешном обновлении сертификата. Если таких записей нет, сертификат истечёт, и сайт станет недоступным по HTTPS.
Тупик: сертификат выпущен — значит, всё работает?
Самая распространённая ошибка — считать, что выпуск сертификата означает готовность HTTPS. На самом деле это только начало. Без перенаправления пользователи будут видеть предупреждения о незащищённом соединении. Без обновления сертификат истечёт через три месяца. Без проверки цепочки браузеры могут не доверять соединению. Без настройки обратного прокси приложение будет генерировать ссылки на http://.
HTTPS — это не один шаг, а последовательность. Пропуск любого из них оставляет сайт уязвимым или недоступным. Например, если выпустить сертификат, но не настроить перенаправление, пользователи будут видеть предупреждения о незащищённом соединении. Если выпустить сертификат, но не настроить обновление, через три месяца сайт станет недоступным. Если выпустить сертификат, но не проверить цепочку, браузеры могут не доверять соединению.
Позиция редакции
HTTPS — обязательное условие для любого современного сайта. Его настройка требует внимания к деталям: порядок шагов, проверка цепочки сертификатов, настройка перенаправлений и заголовков. Если что-то упустить, сайт может стать недоступным или уязвимым.
Однако есть условие, при котором HTTPS не нужен: если сайт работает только в локальной сети и не содержит конфиденциальной информации. В этом случае шифрование не требуется, но и пользы от него не будет. Во всех остальных случаях HTTPS — необходимость, потому что он защищает данные пользователей и обеспечивает доверие к сайту.
Если сайт работает за обратным прокси, нужно убедиться, что прокси передаёт заголовки X-Forwarded-Proto и X-Forwarded-For. Без этого приложение не будет знать, что соединение защищено, и может генерировать ссылки на http://. Кроме того, без заголовка X-Forwarded-For приложение не будет знать реальный IP-адрес клиента, что может вызвать проблемы с логированием и безопасностью.
HSTS должен включаться последним, после того как всё остальное работает. Если включить HSTS рано, а сертификат не обновлён или перенаправление не настроено, пользователи не смогут зайти на сайт даже по HTTP. Поэтому перед включением HSTS нужно убедиться, что всё настроено корректно.