Руководство разработчика по SSL-сертификатам

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

Сбои сертификатов приводят к реальным простоям. Microsoft, Slack и множество других компаний столкнулись с этим публично. Для разработчиков, развертывающих сайты или API с поддержкой HTTPS, понимание SSL-сертификатов — это не опция, а основа.

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

Что на самом деле представляет собой сертификат

TLS-сертификат связывает публичный ключ с идентификатором (обычно доменным именем). Когда браузер подключается к вашему серверу, он проверяет, что сертификат действителен, не истёк и подписан доверенным центром сертификации (Certificate Authority, CA).

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

Сертификаты содержат поле Subject Alternative Name (SAN), в котором перечислены домены или IP-адреса, для которых они действительны. Старое поле Common Name (CN) устарело для целей валидации. Современные клиенты требуют SAN.

DV, OV и EV: что действительно важно

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

Организационная валидация (Organization Validation, OV) и расширенная валидация (Extended Validation, EV) включают ручную проверку вашего юридического лица. Они стоят дороже и занимают больше времени.

Вот что важно практически: шифрование идентично. EV-сертификаты когда-то показывали зелёную адресную строку, но браузеры убрали это визуальное различие. Для большинства разработчиков DV-сертификатов от Let’s Encrypt достаточно, и они бесплатны.

Не стройте предположения вокруг визуальных индикаторов EV — их больше нет.

Жизненный цикл TLS-сертификата и автоматизация

Публичные TLS-сертификаты имеют короткий срок действия, который становится ещё короче. Let’s Encrypt выдаёт 90-дневные сертификаты. CA/Browser Forum уже одобрил поэтапное сокращение максимального срока действия сертификатов, начиная с лимита в 200 дней в 2026 году и двигаясь к 47 дням к 2029 году.

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

Стандартный подход использует протокол ACME, который автоматизирует весь жизненный цикл:

1. Ваш ACME-клиент запрашивает сертификат
2. CA предлагает вам доказать контроль над доменом (через HTTP или DNS)
3. Вы автоматически отвечаете на вызов
4. CA выдаёт подписанный сертификат
5. Ваш клиент устанавливает его и планирует обновление

Certbot — самый распространённый ACME-клиент, но существуют альтернативы для любого стека: acme.sh для shell-окружений, Caddy со встроенным ACME, и библиотеки для Node.js, Go и Python.

Лучшие практики ACME и Let’s Encrypt

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

Ключевые практики:

• Обновляйте заранее: запускайте обновление, когда остаётся 30+ дней, а не при истечении срока
• Мониторьте истечение: используйте инструменты вроде cert-manager для Kubernetes или простые оповещения на основе cron
• Тестируйте обновление: запускайте certbot renew --dry-run или эквивалент в CI
• Избегайте привязки к CA: не жёстко задавайте предположения о том, какой CA вы используете

Храните приватные ключи безопасно. Никогда не коммитьте их в репозитории. Используйте управление секретами, соответствующее вашей платформе.

Краткосрочные TLS-сертификаты и сертификаты для IP-адресов

Краткосрочные сертификаты (от часов до дней) сокращают окно уязвимости, если ключ скомпрометирован. Некоторые организации выдают сертификаты, действительные 24 часа или меньше.

TLS-сертификаты для IP-адресов — сертификаты для IP-адресов, а не доменных имён — важны для сценариев разработки и DevOps, где DNS недоступен. Let’s Encrypt теперь поддерживает краткосрочные IP-сертификаты через ACME, согласуя их с более широким движением к автоматизированной выдаче короткого срока действия.

Для локальной разработки инструменты вроде mkcert создают локально доверенные сертификаты без привлечения публичных CA.

Подготовка к постквантовому TLS

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

Как разработчику приложений, вам не нужно реализовывать это самостоятельно. Поддерживайте актуальность ваших TLS-библиотек, используйте текущие конфигурации и избегайте устаревших алгоритмов вроде SHA-1 или RSA-ключей менее 2048 бит.

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

Предположения, которые плохо стареют

Избегайте этих паттернов:

• Ожидание многолетних сертификатов: максимальный срок действия сокращается
• Жёсткое задание идентификатора CA: CA могут быть дискредитированы, и корневые сертификаты ротируются
• Процессы ручного обновления: они не масштабируются и молча ломаются
• Закрепление сертификатов (certificate pinning): создаёт операционные кошмары при изменении сертификатов
• Игнорирование инвентаризации сертификатов: вы не можете обновить то, что не отслеживаете

Заключение

Современное управление TLS-сертификатами требует автоматизации. Индустрия движется к более коротким срокам действия, что означает, что ACME-клиенты, конвейеры обновления и мониторинг — это базовые требования.

Используйте Let’s Encrypt или аналогичные автоматизированные CA. Интегрируйте обновление в процесс развёртывания. Отслеживайте свои сертификаты. Поддерживайте актуальность библиотек. Эти практики обеспечат надёжную работу ваших HTTPS-развёртываний по мере развития стандартов.

Часто задаваемые вопросы

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.