TLS-рукопожатие и сертификаты

Что добавляет буква S в HTTPS

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

Поднимается это до первого HTTP-запроса, сразу после установки TCP. Процесс называется TLS-handshake.

Порядок: TCP, потом TLS, потом HTTP

1. TCP: SYN → SYN-ACK → ACK            (соединение установлено)
2. TLS handshake: договориться о шифре и проверить сертификат
3. HTTP: GET / поверх уже зашифрованного канала

Это важная деталь. Шифрования на этапе TCP ещё нет, оно появляется только после TLS-handshake. Поэтому первый запрос уходит чуть позже, чем по обычному HTTP. За это платят дополнительным round-trip (в TLS 1.3 он короче, чем в 1.2).

Живые версии: 1.2 и 1.3

Версий TLS накопилось несколько, но выбирать не из чего. TLS 1.0 и 1.1 официально запрещены RFC 8996: браузеры их не поддерживают, а сканеры безопасности сразу помечают такой сервер красным. Рабочих версий осталось две — TLS 1.2 и TLS 1.3.

Поэтому в конфиге веб-сервера старые версии просто не перечисляют:

ssl_protocols TLSv1.2 TLSv1.3;

Что реально согласовалось на конкретном соединении, видно в выводе curl -v: строка вида SSL connection using TLSv1.3.

Что происходит в handshake

Упрощённо, для TLS 1.3:

• Client hello. Клиент шлёт список поддерживаемых шифров и случайное число. Сюда же попадает SNI — имя домена в открытом виде, чтобы сервер с несколькими сайтами понял, какой сертификат отдавать.
• Server hello. Сервер выбирает шифр, шлёт своё случайное число и сертификат.
• Проверка и ключи. Клиент проверяет сертификат, обе стороны вычисляют общий сеансовый ключ. Дальше весь трафик шифруется им.

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

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

Сертификат — это публичный ключ сервера плюс подпись удостоверяющего центра (CA, Certificate Authority). Браузер доверяет серверу, потому что сертификат подписан CA, которому браузер уже доверяет.

Доверие выстроено в цепочку:

Root CA (в хранилище ОС/браузера)
  └─ Intermediate CA (подписан Root)
       └─ Сертификат сервера (подписан Intermediate)

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

Что именно проверяется:

• подпись по цепочке доходит до доверенного корня,
• срок действия не истёк,
• имя в сертификате совпадает с доменом (поле SAN),
• сертификат не отозван.

С отзывом ситуация поменялась. Долгие годы его проверяли по OCSP — запросом к серверу CA прямо во время handshake. Let's Encrypt погасил свои OCSP-ответчики 6 августа 2025 и перешёл на CRL, списки отозванных сертификатов, которые браузеры выкачивают заранее и держат у себя. Для владельца сервера практическое следствие одно: настройка ssl_stapling из старых гайдов для сертификатов Let's Encrypt больше не имеет смысла.

Посмотреть глазами

$ openssl s_client -connect example.com:443 -servername example.com
...
subject=CN=example.com
issuer=C=US, O=Let's Encrypt, CN=E5
Verify return code: 0 (ok)

Verify return code: 0 (ok) значит, что цепочка собралась и сертификат валиден. curl -v https://example.com показывает то же самое в строках с *: версию TLS, выбранный шифр и сертификат.

Что важно запомнить

HTTPS — это HTTP поверх TLS. Handshake идёт после TCP и до первого HTTP-запроса, и только после него трафик зашифрован.

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

Браузер проверяет подпись, срок, совпадение домена и отзыв. curl -v и openssl s_client показывают всё это.

В следующем уроке разберём как получать и автообновлять сертификаты через Let's Encrypt, чтобы они не протухали в проде.