Что защищают HTTPS и SSL-сертификат

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

В быту сертификат продолжают называть SSL-сертификатом. Название закрепилось на рынке, хотя современные соединения используют TLS, а старые версии SSL давно не являются приемлемой основой защиты.

Наличие HTTPS важно для формы, кабинета, оплаты, административной панели и API. Браузерная проверка соединения остаётся частью frontend, а правила обмена внешних систем фиксируются в API-контракте. Но HTTPS не означает, что компания добросовестна, код не содержит уязвимостей, пароль надёжен, а база данных защищена.

Сертификат подтверждает имя сервера и защищает канал. Он не сертифицирует бизнес и не исправляет приложение.

У защищённого соединения три основных свойства.

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

Целостность: данные нельзя незаметно изменить по дороге. Подмена реквизитов формы или кода страницы должна обнаруживаться.

Аутентификация сервера: браузер проверяет, что сертификат выдан для запрошенного имени и связан с доверенной цепочкой.

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

HTTPS также не скрывает всё окружение соединения. Сетевые участники могут видеть IP и часть метаданных. Для владельца обычного сайта главное не обещать «полную анонимность», а корректно описывать защиту передачи.

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

Упрощённо браузер и сервер выполняют TLS handshake:

Публичный ключ можно сообщить клиенту. Закрытый ключ остаётся на сервере или в защищённом сервисе. Если закрытый ключ украден, одного перевыпуска сертификата на том же ключе недостаточно: нужна новая ключевая пара, замена сертификата на всех узлах, запрос на отзыв скомпрометированного сертификата и расследование источника утечки. Отзыв не следует считать мгновенной блокировкой для каждого клиента: способы и момент проверки статуса различаются.

Современный handshake не означает, что все данные шифруются одним постоянным ключом. TLS 1.3 согласует сеансовые ключи; обмен с (EC)DHE даёт forward secrecy для завершённых сеансов при соблюдении предпосылок протокола. Это свойство нельзя без оговорок переносить на PSK-only режимы, скомпрометированное текущее соединение или уже взломанный endpoint.

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

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

Типичные причины предупреждения:

Сертификат для example.ru не обязательно покрывает www.example.ru, api.example.ru и другие поддомены. Wildcard вида *.example.ru не покрывает само имя example.ru и имена более глубокого уровня, например a.b.example.ru. Состав имён проверяют по реальной архитектуре.

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

На одном IP-адресе могут жить разные имена: расширение SNI в TLS помогает серверу выбрать нужный сертификат по имени, которое запросил клиент. Обычный SNI сам по себе не скрывает это имя от наблюдателя; ECH решает отдельную задачу и не должен считаться универсально развёрнутым свойством TLS 1.3. Проверка только IP или главного домена не подтверждает, что CDN, www, API и служебные поддомены отдают правильную цепочку.

Публичные сертификаты различаются способом проверки заявителя.

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

Современные браузеры не показывают владельцу EV прежнюю заметную зелёную строку как универсальный знак доверия. Значок защищённого соединения и действующий DV, OV или EV не доказывают добросовестность бизнеса: пользователь всё равно должен проверять имя сайта и контекст.

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

Установка сертификата не отключает старый HTTP-адрес. Если пользователь открывает http://example.ru, сервер должен перевести его на канонический HTTPS URL постоянным перенаправлением. До получения редиректа первый HTTP-запрос остаётся незащищённым, если браузер ещё не знает HSTS-политику домена и домен не загружен в preload-список.

Проверяют все варианты:

Цепочка из нескольких редиректов добавляет задержку и создаёт точки ошибки. Цикл между CDN и сервером может полностью заблокировать страницу. Например, один слой считает соединение уже HTTPS, а другой снова пытается перенаправить его.

В хостинговой инфраструктуре TLS может завершаться на CDN, балансировщике или непосредственно сервере приложения. Браузер при этом проверяет крайний узел. Его сертификат не защищает участок CDN или прокси → origin: для этого участка отдельно настраивают шифрование и проверку подлинности origin, не отключая проверку сертификата ради совместимости. Конкретная схема зависит от провайдера и архитектуры.

HTTPS на главной странице не доказывает, что защищены все поддомены, API и старые адреса.

HTTPS-страница может ссылаться на ресурс по HTTP: изображение, шрифт, скрипт, iframe или API. Это mixed content.

Активный ресурс вроде JavaScript особенно опасен: его подмена меняет поведение страницы. Современные браузеры блокируют не допускающий обновления mixed content, а некоторые изображения, аудио и видео пытаются автоматически запросить по HTTPS. На автоматическое обновление нельзя полагаться: ресурс может не открыться или попасть в блокируемую категорию.

При миграции ищут:

Webhook и server-to-server callback не являются mixed content браузерной страницы, но их HTTP-адреса проверяют отдельно: такой транспорт тоже не получает защиту HTTPS.

Открытая страница без предупреждения не завершает проверку. Ошибка может появляться только в редкой карточке, старой статье или после действия. Полезны автоматический обход и ручная проверка критичных сценариев в DevTools.

Обычный редирект работает после первого обращения по HTTP. Злоумышленник в сети может попытаться вмешаться до перехода на защищённую версию.

HSTS — заголовок, которым сайт по успешно установленному HTTPS-соединению сообщает браузеру: в течение заданного срока обращайся к этому имени только по защищённому протоколу. Заголовок, полученный по HTTP, браузер не должен принимать. После сохранения политики браузер преобразует будущие HTTP-запросы и не должен разрешать обход TLS-ошибки для этого имени.

Параметр includeSubDomains распространяет политику на все уровни поддоменов. Директива preload лишь выражает намерение: для включения домен отдельно подают в браузерную программу preload и выполняют её текущие требования; это не механизм RFC 6797. Эти настройки требуют осторожности. Если забытый поддомен не поддерживает HTTPS, строгая политика сделает его недоступным.

Для отключения динамической HSTS-политики сервер может отправить max-age=0 по исправному HTTPS, но это увидят только посетившие сайт клиенты. Удаление из preload-списков распространяется с обновлениями браузеров и может занять недели или месяцы, поэтому быстрый и полный откат не гарантирован.

Правильный порядок:

Редирект приглашает перейти на HTTPS. HSTS запрещает браузеру возвращаться к HTTP.

ACME по RFC 8555 автоматизирует взаимодействие клиента с центром сертификации, включая подтверждение контроля над идентификатором и получение нового сертификата; Let’s Encrypt поддерживает этот протокол. «Продление» технически обычно означает новый заказ и выпуск, а установка на каждый рабочий endpoint остаётся задачей эксплуатации. Автоматизация уменьшает риск забыть дату, но требует проверки результата.

Процесс включает:

Задача cron может завершиться успешно, но сертификат останется старым на CDN. Или новый файл появится на диске, а сервер не перечитает конфигурацию. Поэтому мониторят именно сертификат, который получает внешний клиент.

Владелец процесса должен знать:

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

Поисковая система воспринимает HTTP и HTTPS URL как разные адреса. При миграции нужно сохранить постоянные перенаправления, канонические ссылки, sitemap и внутренние ссылки. Внешние сервисы, рекламные объявления и аналитика тоже должны использовать новую версию.

Наличие HTTPS — необходимая техническая база, но не способ автоматически поднять плохую страницу. На результат поиска влияют содержание, доступность для обхода, структура и пользовательская полезность. Связанный контекст раскрыт в статье о поисковой оптимизации.

После миграции проверяют:

HTTPS не предотвращает:

Защищённое соединение — отдельный слой от хранения cookies в браузере: HTTPS не определяет, какие данные сайт сохраняет на устройстве и как долго.

Он также не заменяет CSP, безопасные cookie, обновление CMS, контроль доступа и журналирование. Эти механизмы решают другие задачи.

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

Заполните таблицу для production.

Для приёмки выполните пять отрицательных тестов: открыть HTTP, старый поддомен, страницу с формой, API и адрес с намеренно неверным именем в тестовом контуре. Результат должен соответствовать выбранной политике, а не просто показывать «замок» на главной.

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

TLS-сертификат помогает браузеру проверить имя сервера и установить защищённый канал. HTTPS защищает передачу, но не гарантирует безопасность приложения и честность владельца.

Рабочий HTTPS-контур включает не только сертификат: все имена, полную цепочку, редиректы, mixed content, HSTS, автоматическое обновление, внешний мониторинг и сценарий инцидента.

Если на сайте «вроде стоит SSL», но неизвестно, кто обновляет сертификат и какие поддомены покрыты, Xleb может проверить весь маршрут от HTTP до production API. Результатом будет паспорт контура и список точечных исправлений, а не формальная отметка о наличии HTTPS.