Как работает HTTPS. Разбираемся в SSL, TLS и сертификатах

HTTPS — это тот же HTTP, но поверх зашифрованного канала. За шифрование отвечает протокол TLS (исторически его называют SSL), а за доверие к серверу — инфраструктура цифровых сертификатов.

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

Чем HTTPS отличается от HTTP

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

• Конфиденциальность — трафик зашифрован, посторонний видит только адрес сервера и объём данных.
• Аутентичность — вы говорите именно с тем доменом, который в адресной строке, а не с подставным сервером.
• Целостность — изменить данные в пути незаметно нельзя, подмена ломает проверку.

Сегодня HTTPS — не опция, а требование: браузеры помечают HTTP-страницы как небезопасные, HTTP/2 и HTTP/3 на практике работают только поверх TLS, а поисковики учитывают наличие сертификата при ранжировании.

SSL и TLS: почему два названия

• SSL (Secure Sockets Layer) — исходный протокол 1990-х. Все его версии давно признаны небезопасными.
• TLS (Transport Layer Security) — его преемник, который и используется во всём современном вебе.

Когда говорят «SSL-сертификат», технически имеют в виду сертификат для TLS: название закрепилось исторически. Сам сертификат от версии протокола не зависит — это просто файл с публичным ключом и подписью.

Как проходит TLS-рукопожатие

Прежде чем передать первый байт HTTP-запроса, клиент и сервер устанавливают защищённый канал:

1) Client Hello. Браузер сообщает поддерживаемые версии TLS, наборы шифров и имя домена в расширении SNI — благодаря ему один IP-адрес обслуживает много сайтов с разными сертификатами.

2) Server Hello и сертификат. Сервер выбирает версию и шифр, отправляет свой сертификат вместе с промежуточными сертификатами цепочки.

3) Проверка сертификата. Клиент убеждается, что срок действия не истёк, домен совпадает, цепочка ведёт к корневому центру сертификации из доверенного хранилища и сертификат не отозван.

4) Согласование ключей. Стороны вычисляют общий сеансовый ключ, обычно алгоритмом ECDHE. Он даёт forward secrecy: даже если приватный ключ сервера утечёт позже, записанный ранее трафик расшифровать не выйдет.

5) Обмен данными. Дальше работает быстрое симметричное шифрование сеансовым ключом.

В TLS 1.3 рукопожатие занимает один круговой обмен вместо двух, а при повторном подключении может обойтись вовсе без него. Подробный разбор с реальным дампом трафика — в статье про TLS handshake по шагам, а про ускорение повторных соединений — в материале о TLS session resumption.

Сертификаты и цепочка доверия

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

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

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

По уровню проверки сертификаты делятся на три вида: DV подтверждает только владение доменом (выдаётся за минуты, подходит большинству), OV дополнительно проверяет организацию, EV — строгая проверка юрлица. Визуальных преимуществ у EV в браузерах давно нет, так что переплата оправдана редко.

Как включить HTTPS на своём сайте

Практический минимум выглядит так:

1) Получите сертификат. Для большинства задач достаточно бесплатного Let's Encrypt: certbot --nginx -d example.com -d www.example.com сам выпустит сертификат и пропишет его в конфиг. Сертификаты Let's Encrypt живут 90 дней, поэтому обновление сразу настраивают автоматически — как это сделать, разбирали в статье про автообновление сертификатов с certbot. Пошаговая настройка веб-сервера — в материале HTTPS и бесплатный SSL в Nginx.

2) Включите редирект с HTTP. Иначе старые ссылки продолжат вести на незашифрованную версию, а поисковики увидят два одинаковых сайта.

3) Оставьте только TLS 1.2 и 1.3. Более старые версии небезопасны и отключены в браузерах.

4) Добавьте HSTS, когда убедились, что всё работает. Заголовок Strict-Transport-Security запрещает браузеру обращаться к сайту по HTTP вообще. Действует он долго, поэтому включать его до того, как HTTPS заработал стабильно, опасно — откатиться быстро не получится.

5) Проверьте результат. Локально — openssl s_client -connect example.com:443 -servername example.com, снаружи — SSL Labs SSL Test или наша проверка SSL-сертификата, которая покажет срок действия, издателя и целостность цепочки.

Типичные ошибки HTTPS и что с ними делать

Истёк сертификат. Самая частая и самая обидная авария: сайт работал годами и однажды утром встречает посетителей красным предупреждением. Причина обычно не в том, что забыли продлить, а в том, что сломалось автообновление — например, certbot не смог пройти проверку из-за редиректа. Поэтому срок действия сертификата стоит мониторить отдельно, а не полагаться на то, что автоматика не подведёт.

Неполная цепочка сертификатов. Симптом характерный: в браузере всё хорошо, но мобильное приложение, curl или платёжный шлюз получают ошибку проверки. Лечится добавлением промежуточного сертификата в конфигурацию (в Nginx — склеенный файл fullchain.pem).

Несовпадение имени. Сертификат выпущен на example.com, а сайт открывают по www.example.com или по IP. В сертификате должны быть перечислены все используемые имена.

Смешанное содержимое (mixed content). Страница отдаётся по HTTPS, но подтягивает картинки, стили или скрипты по HTTP — браузер их блокирует, вёрстка ломается. Ищется в консоли разработчика, лечится заменой ссылок на протокол-независимые или https-адреса.

ERR_SSL_PROTOCOL_ERROR. Обычно означает, что клиент и сервер не смогли договориться о версии протокола или наборе шифров: сервер слишком старый, а клиент отключил legacy-версии, либо наоборот.

Ошибка после смены сервера. Перенесли сайт и забыли скопировать приватный ключ или конфиг TLS — сервер отдаёт самоподписанный сертификат по умолчанию.

Что стоит проверять регулярно

HTTPS — не настройка «сделал и забыл». Минимальный набор наблюдения:

• Срок действия сертификата с запасом в 2–4 недели, чтобы успеть починить автообновление.
• Целостность цепочки — после каждого обновления сертификата или переезда.
• Версии протокола и шифры — раз в несколько месяцев: то, что было надёжным вчера, устаревает.
• Доступность по HTTPS снаружи — сертификат может быть в порядке, а порт 443 закрыт файрволом после правки правил.

Последние два пункта надёжнее автоматизировать: мониторинг доступности проверяет сайт так же, как это делает посетитель, и присылает уведомление, когда сертификат скоро истечёт или соединение перестало устанавливаться.

FAQ

Влияет ли HTTPS на скорость сайта? Рукопожатие добавляет несколько десятков миллисекунд при первом соединении, но HTTP/2 и HTTP/3 доступны только поверх TLS и в сумме дают выигрыш. На повторных подключениях работает session resumption, и накладные расходы почти исчезают.

Нужен ли платный сертификат, если есть Let's Encrypt? Для большинства сайтов нет: с точки зрения шифрования DV-сертификат Let's Encrypt ничем не отличается от платного. Платные берут ради страховки, поддержки, wildcard-сертификатов в удобном виде или требований конкретного заказчика.

Что такое wildcard-сертификат? Сертификат на *.example.com, покрывающий все поддомены первого уровня. Удобно, когда поддомены появляются часто; при этом один приватный ключ становится общим для всех — учитывайте это в модели угроз.

Защищает ли HTTPS сам сайт от взлома? Нет. Он защищает канал передачи данных, но никак не влияет на уязвимости приложения, слабые пароли или дыры в CMS.