TLS-сертифікати та автоматичне продовження

Навіщо це потрібно

TLS шифрує трафік «kliyent↔servis», підтверджує справжність сервера (і при 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-провайдера/АСМЕ-аккаунта.
Невірний ланцюжок: терміновий деплою коректного «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-конвеєр, додайте строгий алертинг і регулярно тренуйте «аварійні» сценарії - і закінчені сертифікати перестануть бути джерелом нічних пейджерів.