TLS-сертификаты и автоматическое продление

Зачем это нужно

TLS шифрует трафик «клиент↔сервис», подтверждает подлинность сервера (и при mTLS — клиента), а также защищает от подмены. Главные риски: просрочка сертификатов, слабые ключи, неверная цепочка доверия, ручные процедуры. Цель статьи — описать архитектуру, при которой сертификаты всегда актуальны и ротации проходят незаметно для пользователей.

Базовые понятия

CA / Подписант: центр сертификации (публичный или внутренний).
Chain (fullchain): листовой сертификат + промежуточные + корневой (обычно корневой в клиентских хранилищах).
SAN (Subject Alternative Name): список доменов/IP для одного сертификата (мульти-SAN).
Wildcard: `.example.com` — удобно для множества поддоменов, требует DNS-валидации.
OCSP stapling: сервер прикладывает свежий статус отзыва; снижает задержки и зависимость от внешних OCSP.
HPKP: устарело/не использовать; вместо этого — CT-логи и ключевая гигиена.
CT (Certificate Transparency): публичные логи выдачи — важно для контроля поддельных выпусков.

Криптопрофиль и ключи

• ECDSA (P-256) — быстрый и компактный; предпочтителен для современных клиентов.
• RSA-2048/3072 — по-прежнему совместимее; можно держать dual-cert (RSA+ECDSA).
• Генерация ключей: только на целевой стороне (не передавать приватники по сети), защитить права доступа (`0600`).
• HSM/KMS: для критичных зон (платежные/PII) храните ключи в HSM/KMS, включайте аудит операций.
• Сроки жизни: короткие сертификаты (90 дней/30 дней для внутренних) поощряют частую ротацию и снижают риск компрометации.

Архитектурные модели управления TLS

1. Публичная CA через ACME (Let’s Encrypt/Buypass/и т. п.)

Валидация: HTTP-01 (через веб-сервер/Ingress) или DNS-01 (для wildcard/внепоточных доменов).
Плюсы: бесплатно/автоматизировано, широкое доверие. Минусы: внешние зависимости.

2. Внутренняя корпоративная CA

Инструменты: HashiCorp Vault PKI, Smallstep (step-ca), Microsoft AD CS, CFSSL.
Плюсы: кастомные политики, mTLS, короткие TTL, выпуск для внутренних доменов. Минусы: дистрибуция корня, управление доверием.

3. Гибрид

Публичная CA для внешних пользователей; внутренняя CA — для сервис-к-сервис (mTLS), межкластерных каналов и админок.

Паттерны автоматического продления (renew)

Общие принципы

Порог продления: начинать при `≤ 30` дней до истечения; для критичных сервисов — при `≤ 45` дней.
Zero-downtime: выпуск нового сертификата, атомарная замена, плавный reload без разрыва соединений.
Двойное держание (blue/green): хранить текущий и следующий cert; переключение — через symlink или версионированный secret.
Алертинг: предупреждения за 45/30/14/7/3/1 день; отдельный алерт при провале ACME-челленджа.

ACME-клиенты и их применение

certbot / acme.sh / lego: легкие агенты на VM/ bare-metal.
cert-manager (Kubernetes): оператор, работающий с Issuer/ClusterIssuer; автоматизирует release/renew и записывает в Secret.
step-ca/Vault Agent: автоматический выпуск/ротация с короткими TTL, sidecar-паттерны для обновления ключей и цепочек.

Процессы для Kubernetes

yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx

yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней

Горячая замена в NGINX-Ingress происходит автоматически при обновлении `Secret`. Добавьте `ssl-ecdh-curve: secp256r1` и включите OCSP stapling через аннотации/ConfigMap.

Процессы для VM/Bare-metal

bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"

Периодический `certbot renew` через systemd timer.
Для wildcard используйте DNS-01 (провайдер-плагин) и аналогичный `--deploy-hook`.

bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"

NGINX: атомарная замена

Храните `fullchain.pem` и `privkey.pem` под стабильными путями (symlink на версионированные файлы), затем `nginx -s reload`.

Внутренняя PKI и mTLS

bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256

Автовыпуск: через Vault Agent Injector (K8s) или sidecar; приложение перечитывает cert с файла/FS-watcher.
Короткие TTL: 24–720 часов, что стимулирует частую ротацию и снижает ценность украденного ключа.
mTLS: выдайте клиентские сертификаты для конкретных сервисов/ролей; на входе — mutual TLS в ingress/sidecar-proxy.

Безопасная эксплуатация

Разделение секретов: приватные ключи — только на хосте/поде, доступ по принципу наименьших привилегий.
Права файлов: `600` для ключа; владелец — пользователь процесса.
Грейс-период: устанавливайте `renewBefore` достаточным, чтобы учесть сбои DNS/ACME/провайдера.
OCSP Stapling: включить на фронтах; следить за свежестью ответа (обычно 12–72 ч).
HSTS: включить постепенно (без `preload` на старте), убедившись в корректной HTTPS-доставке всего контента.
Dual-cert (RSA+ECDSA): улучшает совместимость и производительность; современным клиентам отдавайте ECDSA.

Мониторинг и SLO

• Дни до истечения (gauge) по каждому домену/секрету; SLO: «нет cert с < 7 дней до expiry».
• Валидность цепочки (линтинг), соответствие SAN требуемым доменам/IP.
• Статус OCSP stapling (свежесть ответа).
• Доля успешных/неуспешных ACME-челленджей.
• Лейтенси TLS-рукопожатия, версии протокола/шифры (audit).

• Warn: 30 дней до истечения.
• Crit: 7 дней / провал `renew`.
• Page: 72 часа / невалидная цепочка в проде / отсутствует OCSP stapling.

Инциденты и откаты

Просрочка сертификата: временно перевыпустить и задеплоить вручную, зафиксировать RCA (почему не сработал renew, блокировки DNS/ограничения API).
Компрометация ключа: немедленное перевыпуск/отзыв, ротация секретов, аудит доступа, ротация токенов DNS-провайдера/ACME-аккаунта.
Неверная цепочка: срочный деплой корректного `fullchain`, принудительный reload фронтов.
Lock-in к провайдеру DNS: держите резервный путь валидации (HTTP-01) или вторичный DNS.

Чек-лист внедрения автопродления

1. Выберите модель (публичная CA через ACME / внутренняя PKI / гибрид).
2. Определите криптопрофиль: ECDSA-P256, при необходимости dual-cert с RSA-2048.
3. Настройте автоматический агент (cert-manager, certbot, acme.sh, Vault Agent).
4. Организуйте zero-downtime замену (symlink-паттерн, hot-reload ingress/NGINX/Envoy).
5. Включите OCSP stapling и HSTS (поэтапно).
6. Добавьте алертинг сроков и статусов челленджей; прописать SLO.
7. Документируйте процессы break-glass и ручного выпуска.
8. Проведите «фейловые» учения: сломанный DNS-01, падение ACME, истекший корень/промежуточный.
9. Пересматривайте доступы к приватным ключам, ротируйте токены DNS-провайдера и аккаунты ACME.

Особенности для iGaming/финтех

PCI DSS/PII: строгие Cipher Suites, принудительный TLS 1.2+/1.3, выключить слабые шифры/компрессию, session resumption без компромиссов безопасности.
Сегментация доменов: отдельные сертификаты для платежных поддоменов и админок; для провайдеров контента — изолированные цепочки.
Аудит и логирование: фиксируйте выпуск/отзыв/ротации; подписывайте артефакты CI/CD.
Многорегиональность: локальные Issuer-ы на регионы, чтобы не зависеть от кросс-регионных отказов.

Примеры конфигураций

NGINX (RSA+ECDSA, OCSP stapling)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;

ssl_certificate   /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate   /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000" always;

OpenSSL: CSR (ECDSA-P256)

bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"

CFSSL: профиль и выдача

json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}

bash cfssl gencert -profile=server ca. json csr. json      cfssljson -bare server

FAQ

Нужен ли wildcard?
Если часто появляются новые поддомены — да (через DNS-01). Иначе используйте мульти-SAN для явных доменов.

Что выбрать: cert-manager или certbot?
Kubernetes → cert-manager. VM/микросервисы вне K8s → certbot/lego/acme.sh. Внутренняя PKI → Vault/step-ca.

Можно ли сократить TTL до суток?
Для внутренних mTLS — да, если автоматизация/sidecar гарантируют ротацию и приложения умеют hot-reload.

Как обезопасить DNS-01?
Отдельный токен/минимальный доступ к зоне, ротация ключей, ограничить IP API-доступа, вести audit.

Итог

Надежное управление TLS — это сочетание правильного криптопрофиля, автоматизированного выпуска и продления, zero-downtime ротаций, наблюдаемости и четких процедур инцидент-респонса. Постройте ACME/PXI-конвейер, добавьте строгий алертинг и регулярно тренируйте «аварийные» сценарии — и истекшие сертификаты перестанут быть источником ночных пейджеров.