HTTPS и TLS

Клиент отправляет ClientHello с поддерживаемыми шифрами, hostname в SNI, протоколами ALPN и key share для эфемерного обмена Диффи — Хеллмана. Сервер отвечает ServerHello и своим key share, и обе стороны выводят одинаковые сессионные ключи. С этого момента всё зашифровано: сервер отправляет цепочку сертификатов, подпись, доказывающую владение закрытым ключом, и Finished. Клиент проверяет цепочку и hostname, отправляет Finished и сразу может отправить HTTP-запрос. Это один круговой путь против двух в TLS 1.2. Эфемерные ключи дают forward secrecy, поэтому последующая утечка ключа не позволит расшифровать записанный трафик.

Браузеры и операционные системы доверяют небольшому набору корневых сертификатов CA. Корневые CA подписывают промежуточные, а промежуточные — сертификаты сайтов. Когда сервер предъявляет свой leaf-сертификат вместе с промежуточными, клиент проверяет каждую подпись вверх по цепочке, пока не дойдёт до доверенного корня, а также проверяет сроки действия, hostname в Subject Alternative Name и назначение ключа. Если промежуточного сертификата нет, одни клиенты могут его скачать, а другие падают, — вот почему curl или мобильные приложения ломаются, когда десктопные браузеры работают. Корневые CA хранятся офлайн под защитой; промежуточные можно ротировать, не меняя того, чему доверяют устройства.

Автоматизация плюс мониторинг. Я использую certbot или другой ACME-клиент с systemd-таймером или cron, deploy hook для перезагрузки nginx и запускаю certbot renew --dry-run после настройки и после любого изменения сервера. Порт 80 остаётся открытым для HTTP-01, либо я использую DNS-01 с API-токеном ограниченных прав. Затем мониторю снаружи: uptime-сервис присылает алерт, когда до истечения сертификата остаётся меньше примерно двух недель. Сроки действия по всей отрасли сокращаются и к 2029 году дойдут до 47 дней, поэтому всё ручное рано или поздно сломается. За CDN edge-сертификат управляется провайдером, но origin требует такой же заботы.

HSTS — это заголовок ответа Strict-Transport-Security, который велит браузеру использовать для этого домена только HTTPS в течение заданного срока, например года. После первого визита браузер сам переводит ссылки http:// на HTTPS и не позволяет пользователям пропустить ошибки сертификата, что блокирует атаки SSL stripping. С preload-списком браузеры применяют это даже при самом первом визите. Риск — в «запирании»: если какой-то поддомен, покрытый includeSubDomains, не поддерживает HTTPS или сертификат сломался, пользователи не смогут туда попасть. Поэтому я начинаю с короткого max-age, проверяю все поддомены, затем увеличиваю его, а в preload отправляю только при полной уверенности.

Скорее всего, сервер отдаёт только свой leaf-сертификат без промежуточного. Десктопные браузеры часто это скрывают, потому что кэшируют промежуточные сертификаты или скачивают их через расширение AIA, а curl, многие мобильные клиенты, Node и Java так не делают. Решение — настроить полную цепочку: в nginx ssl_certificate должен указывать на fullchain.pem от certbot, а не на cert.pem. Я проверяю через openssl s_client -showcerts, что промежуточный сертификат присутствует, или использую онлайн-проверку SSL. Реже на клиентской машине устарел сам набор CA, и его нужно обновить.

Каждый участок должен быть зашифрован, если он проходит через сеть, которую вы не контролируете полностью. CDN завершает TLS посетителя. Между CDN и origin я использую Full (strict) с валидным сертификатом, в идеале плюс authenticated origin pulls. Балансировщик может завершать TLS и шифровать заново или пропускать TLS до nginx; завершение на нём упрощает управление сертификатами, повторное шифрование сохраняет защиту данных внутри сети. Между nginx и контейнерами на том же хосте в приватной Docker-сети обычный HTTP — распространённый и допустимый компромисс. Между хостами или в общих кластерах используйте TLS или mTLS, часто через service mesh. Меньше точек завершения — меньше ключей, которые надо защищать, но каждый участок, который инспектирует трафик, требует собственного сертификата и ротации.

Исходите из того, что ничего ручного не выживет. Проведите инвентаризацию всех сертификатов: веб-серверы, балансировщики, почта, VPN, аппаратные устройства и всё, что использует файл сертификата, скопированный вручную. Переведите каждый на автоматизацию через ACME или на managed-сервис вроде CDN или облачного балансировщика, который продлевает сам. Используйте клиенты с поддержкой ARI, чтобы CA мог сигнализировать о раннем продлении. Сделайте перезагрузки автоматическими через deploy hook и убедитесь, что система управления конфигурацией не перезаписывает продлённые файлы. Мониторьте снаружи срок действия и ошибки цепочки, с алертами задолго до того, как останется треть срока. Устройства, которые не умеют ACME, должны стоять за прокси, который умеет. Вложения окупаются не только ради compliance: ротации становятся рутиной, и экстренный отзыв больше не вызывает стресса.

Pinning заставляет приложение принимать только конкретные ключи, что блокирует перехват, даже если пользователь установил поддельный CA или CA скомпрометирован. Цена — хрупкость: если вы ротируете ключи без ведома приложения, перестают работать все установленные версии, а при коротких сроках сертификатов ротация частая. Если pinning обязателен, закрепляйте публичный ключ промежуточного сертификата или собственный долгоживущий ключ, а не leaf, всегда добавляйте резервные пины, предусмотрите удалённый способ обновить или отключить pinning и сохраняйте тот же ключ между продлениями, если процесс вашего CA это позволяет. Для большинства приложений достаточно стандартной валидации TLS плюс проверок Certificate Transparency на уровне платформы. Pinning обычно окупается в банковских и высокорисковых приложениях.