Прямой ответ
HTTPS = HTTP поверх TLS, а TLS решает три задачи разом: шифрование (трафик не читается по пути), аутентификация сервера (вы говорите с тем, с кем думаете — через цепочку сертификатов), целостность (трафик не подменён). Ключевая идея рукопожатия: асимметричная криптография (дорогая) используется только чтобы договориться о симметричном ключе (дешёвом), которым шифруется весь дальнейший трафик; в TLS 1.3 рукопожатие — один round-trip (ClientHello сразу с параметрами, ServerHello + сертификат + Finished), а доказательства владения приватным ключом сервер даёт подписью рукопожатия, не «расшифровкой». Практические следствия для разработчика: сертификат проверяется клиентом всегда (и verify=False в requests отключает именно аутентификацию — трафик шифруется, но от кого угодно — httpx/requests); ошибка «certificate verify failed» — почти всегда не «сломался TLS», а просроченный сертификат, неполная цепочка (не отдан intermediate) или неверный hostname; отладка — openssl s_client -connect host:443 -servername host показывает всю правду: цепочку, сроки, протокол.
Криптография в двух абзацах: асимметрия и симметрия
Симметричное шифрование (AES-GCM) — один ключ на шифрование и расшифровку, быстрое (гигабиты на ядро) — им шифруются данные. Асимметричное (RSA/ECDSA) — пара публичный/приватный ключ: публичный шифрует/проверяет подпись, приватный расшифровывает/подписывает; медленное на порядки — используется только в рукопожатии. Связывает их схема: клиент и сервер с помощью асимметрии (через ECDHE — эфемерный Диффи-Хеллман) выводят общий сессионный ключ, которого никогда не было в сети в открытом виде; приватный ключ сервера в TLS 1.3 не передаёт ключ вовсе — он лишь подписывает параметры рукопожатия, доказывая «сертификат мой» (отсюда forward secrecy: компрометация приватного ключа позже не расшифрует записанный трафик — сессионные ключи эфемерны). Сертификат — «публичный ключ + имя владельца + подпись доверенного CA»: сам по себе публичный ключ ничего не доказывает (кто угодно сгенерирует пару) — доверие приходит из подписи цепочкой.
Цепочка доверия и роль CA
Клиент доверяет корневым сертификатам (сотни предустановленных в ОС/браузере); ваш сертификат подписан промежуточным CA (intermediate), тот — корневым: проверка идёт снизу вверх до доверенного корня. Отсюда типичные проблемы: сервер не отдаёт intermediate (браузеры иногда достраивают цепочку сами, строгие клиенты — нет: curl падает, браузер работает — «только у API-клиентов ломается»); самоподписанный сертификат — цепочки доверия нет (валидно для внутренних систем при явном добавлении корня в доверенные — локальный HTTPS через mkcert делает именно локальный CA); hostname mismatch — сертификат выдан на example.com, запрос к api.example.com без SAN — отклоняется (CN устарел, проверяются Subject Alternative Names); просрочка — инциденты с падением сервисов из-за непродлённых сертификатов (автопродление — обязательная мера). Let's Encrypt изменил экономику: бесплатные доверенные сертификаты на 90 дней с автоматизацией — «самоподпись на проде» потеряла последние оправдания.
SNI, версии протокола и отладка
SNI (Server Name Indication) — расширение ClientHello с именем хоста до начала шифрования: один IP может обслуживать сотни HTTPS-сайтов (сервер выбирает сертификат по имени — виртуальные хосты nginx); без SNI остались бы «один IP = один сертификат». Версии: TLS 1.0/1.1 — запрещены (уязвимости, браузеры отключили), 1.2 — рабочий стандарт, 1.3 — быстрее и чище (меньше раундов, убраны небезопасные режимы); на сервере — ssl_protocols TLSv1.2 TLSv1.3 и современный набор шифров (конфигураторы Mozilla генерируют проверенные наборы). Отладка одной командой: openssl s_client -connect example.com:443 -servername example.com — цепочка (проверить полноту!), сроки (notBefore/notAfter), протокол и шифр; curl -vI — глазами путь проверки; openssl x509 -in cert.pem -noout -text— содержимое сертификата (SAN, issuer). Частые диагнозы:unable to get local issuer certificate— нет intermediate в цепочке сервера или устарел CA-bundle клиента (в Docker-образах безca-certificates— классика);certificate has expired— продление;wrong version number` — клиент идёт TLS-ом на не-TLS порт (или наоборот).
Практический сценарий: «API отвалился с SSL-ошибкой»
Симптом: клиенты Python-сервиса получают SSLCertVerificationError: unable to get local issuer certificate при обращении к партнёрскому API; браузер при этом открывается. Диагностика: (1) openssl s_client -connect api.partner.com:443 -servername api.partner.com — в выводе цепочка из одного сертификата (leaf), intermediate отсутствует — браузер достраивает из своего кеша/AIA-fetch, Python со строгим стеком — нет: диагноз подтверждён. (2) Временное решение на своей стороне — собрать fullchain из leaf + скачанного intermediate в свой trust store (не verify=False! — почему); (3) уведомление партнёру: отдавать fullchain — их фикс на стороне сервера; (4) после их фикса — проверка тем же s_client (две записи в цепочке) и прогон интеграционных тестов. Разбор показывает систему: ошибка верификации — сообщение о состоянии цепочки, а не «TLS сломался»; verify=False — удаление симптома ценой аутентификации (MITM становится возможным); правильный фикс всегда на уровне цепочки/trust store. Побочный вывод для своего сервера: nginx ssl_certificate fullchain.pem (не cert.pem) — проверка собственного сервера тем же s_client раз в квартал или мониторинг срока сертификата (алерты).
FAQ
Шифрует ли TLS данные от своего же сервера/провайдера? Нет: TLS защищает путь клиент↔сервер (точнее, до терминирующего TLS узла — обычно reverse-proxy); внутри инфраструктуры трафик может идти открытым (proxy → backend) — для чувствительных систем mTLS между сервисами или end-to-end шифрование полезной нагрузки.
Что такое mTLS и когда нужен? Взаимная аутентификация: сервер проверяет сертификат клиента (оба предъявляют сертификаты). Применяется в service mesh и между доверенными системами (банк↔банк, микросервисы в нулевом доверии); для публичных сайтов избыточен — там аутентификация прикладная (логины/токены).
Почему TLS 1.3 быстрее? Один round-trip до данных (вместо двух в 1.2), 0-RTT для повторных соединений (с оговорками по replay), меньше согласований — меньше задержка на старте соединения; на мобильных сетях с большим RTT выигрыш заметен пользователю.
Проверяют ли мобильные приложения сертификаты так же строго? По умолчанию — да (системный trust store); исключение — certificate pinning (приложение доверяет только конкретному сертификату/ключу — защита от скомпрометированных CA, цена — риск «кирпича» при ротации сертификата без заложенного запасного пина).
Источники: RFC 8446 (TLS 1.3), Let's Encrypt How It Works, MDN — ссылки в шапке.