Certificate TLS și reînnoire automată

De ce ai nevoie de ea?

TLS criptează traficul „kliyent↔servis”, confirmă autenticitatea serverului (și cu mTLS - client) și, de asemenea, protejează împotriva spoofing. Principalele riscuri: întârzierile certificatului, cheile slabe, lanțul de încredere incorect, procedurile manuale. Scopul articolului este de a descrie arhitectura în care certificatele sunt întotdeauna relevante și rotațiile trec neobservate de utilizatori.

Concepte de bază

CA/Semnatar: autoritatea de certificare (publică sau internă).
Lanț (fullchain): certificat de frunze + intermediar + rădăcină (de obicei rădăcină în depozitele de clienți).
SAN (Subject Alternative Name): lista domeniilor/IP pentru un singur certificat (multi-SAN).
Wildcard: '.example. com' - convenabil pentru multe subdomenii, necesită validare DNS.
Capsarea OCSP: serverul aplică cea mai recentă stare de revocare; reduce latența și dependența de OCSP-urile externe.
HPKP: învechit/neutilizat; în schimb, jurnalele CT și igiena cheie.
CT (Certificate Transparency): jurnalele de emisiune publice - importante pentru controlul versiunilor false.

Profil cripto și chei

• ECDSA (P-256) - rapid și compact; preferat pentru clienții moderni.
• RSA-2048/3072 - încă compatibil; poate avea loc dual-cert (RSA + ECDSA).
• Generare cheie: numai pe partea țintă (nu transferați persoane private prin rețea), protejați drepturile de acces („0600”).
• HSM/KMS: pentru zonele critice (plată/PII) stocați cheile în HSM/KMS, activați operațiunile de audit.
• Durata de viață: Certificatele scurte (90 zile/30 zile pentru interne) încurajează rotația frecventă și reduc riscul de compromis.

Modele arhitecturale de management TLS

1. Public CA prin ACME (Să criptăm/Buypass/etc.)

Validare: HTTP-01 (prin web server/Ingress) sau DNS-01 (pentru domenii wildcard/out-of-stream).
Pro: gratuit/automatizat, încredere largă. Contra: dependențe externe.

2. CA Corporate Interne

Instrumente: HashiCorp Vault PKI, Smallstep (pas cu pas), Microsoft AD CS, CFSSL.
Pro: politici personalizate, mTLS, scurt TTL, eliberare pentru domenii interne. Contra: distribuția rădăcinilor, managementul încrederii.

3. Hibrid

CA public pentru utilizatorii externi; CA intern - pentru service-to-service (mTLS), canale inter-cluster și administratori.

Modele de reînnoire automată (reînnoire)

Principii generale

Prag de reînnoire: începeți cu „≤ 30” de zile înainte de expirare; pentru servicii critice - cel ≤ 45 de zile.
Zero-downtime: emiteți un nou certificat, înlocuire atomică, reîncărcare netedă fără întreruperea conexiunilor.
Cală dublă (albastră/verde): stocați certul curent și următor; comutare - prin symlink sau secret versionat.
Avertizare: 45/30/14/7/3/1 avertismente de zi; o alertă separată în timpul eșecului provocării ACME.

Clientii ACME si aplicatia acestora

certbot/acme. sh/lego: agenți de lumină pe VM/bare-metal.
cert-manager (Kubernetes): operator care lucrează cu Issuer/ClusterIssuer; automatizează eliberarea/reînnoirea și scrie către Secret.
step-ca/Vault Agent: eliberare automată/rotire cu TTL-uri scurte, modele laterale pentru actualizarea cheilor și lanțurilor.

Procese pentru 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 дней

Schimbarea la cald în NGINX-Ingress are loc automat atunci când „Secret” este actualizat. Adăugați 'ssl-ecdh-curve: secp256r1' și activați capsarea OCSP prin adnotările/ConfigMap.

Procese pentru VM/Bare-metal

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

Periodic „certbot reînnoi” prin timer systemd.
Pentru wildcard, utilizați DNS-01 (furnizor de plugin) și similare „--deploy-cârlig”.

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"

Înlocuire atomică NGINX

Păstrează-ţi lanţul. pem 'и' privkey. pem "sub căi stabile (symlink la fișiere versionate), apoi" nginx -s reîncărcare ".

PKI intern și 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

Eliberare automată: prin Vault Agent Injector (K8s) sau ataş; aplicația re-citește cert din fișierul/FS-watcher.
Scurt TTL: 24-720 ore, care încurajează rotația frecventă și reduce valoarea tastei furate.
mTLS: eliberarea certificatelor de client pentru servicii/roluri specifice; la intrare - TLS reciproc în intrare/sidecar-proxy.

Funcționare sigură

Partajarea secretelor: chei private - numai pe gazdă/pod, acces în conformitate cu principiul celor mai puține privilegii.
Drepturi de fișier: „600” pentru cheie; proprietar - utilizator de proces.
Perioada de grație: Setați 'renewBefore' pentru a fi suficient pentru a contabiliza eșecurile DNS/ACME/furnizor.
OCSP Capsare: porniți la fronturi; monitorizează prospețimea răspunsului (de obicei 12-72 ore).
HSTS: porniți treptat (fără „preîncărcare” la început), asigurându-vă că livrarea corectă HTTPS a întregului conținut.
Dual-cert (RSA + ECDSA): îmbunătățește compatibilitatea și performanța; Oferiți ECDSA clienților moderni.

Monitorizare și SLO

• Zile înainte de expirare (ecartament) pentru fiecare domeniu/secret; SLO: „fără cert de la <7 zile până la expirare”.
• Valabilitatea lanțului (linting), conformitatea SAN cu domeniile/IP necesare.
• Statusul de capsare OCSP (prospețimea răspunsului).
• Procentul provocărilor ACME reușite/nereușite.
• Strângeri de mână Leitency TLS, versiuni de protocol/cifruri (audit).

• Avertisment: 30 de zile până la expirare.
• Crit: 7 zile/eșec „reînnoire”.
• Pagina: 72 ore/lanț invalid în prod/nu OCSP capsare.

Incidente și rollback-uri

Întârzierea certificatului: reemiteți temporar și implementați manual, fixați RCA (de ce nu a funcționat reînnoirea, restricțiile DNS de blocare/API).
Compromis cheie: reemiterea/revocarea imediată, rotirea secretelor, auditul accesului, rotirea jetoanelor din contul DNS/ACME.
Lanț incorect: depunerea urgentă a „întregului” corect, reîncărcarea forțată a fronturilor.
Blocare la furnizorul DNS: păstrați calea de validare de backup (HTTP-01) sau DNS secundar.

Lista de verificare a implementării reînnoirii automate

1. Selectați modelul (public CA prin ACME/intern PKI/hibrid).
2. Definiți profilul cripto: ECDSA-P256, dacă este necesar dual-cert cu RSA-2048.
3. Configurați agentul automat (cert-manager, certbot, acme. sh, Agent Vault).
4. Organizați înlocuirea zero-downtime (model symlink, intrare la cald/NGINX/Envoy).
5. Activați capsarea OCSP și HSTS (în etape).
6. Adăugați date de alertă și stări de provocare; prescrie SLO.
7. Documentați procesele de spargere și eliberare manuală.
8. Efectuați exerciții „false”: DNS-01 rupte, căderea ACME, rădăcina expirată/intermediară.
9. Revizuiți accesul la cheile private, rotiți jetoanele furnizorului DNS și conturile ACME.

Caracteristici pentru iGaming/fintech

PCI DSS/PII: strict Cifru Suites, forțat TLS 1. 2+/1. 3, opriți cifrurile slabe/compresie, reluarea sesiunii fără compromisuri de securitate.
Segmentarea domeniului: certificate separate pentru subdomenii și administratori de plată; pentru furnizorii de conținut - lanțuri izolate.
Audit și logare: înregistrare de lansare/rechemare/rotație; semnează artefacte CI/CD.
Multiregionalitate: emitenți locali în regiuni, pentru a nu depinde de eșecurile transregionale.

Configurații de probă

NGINX (RSA + ECDSA, OCSP capsare)

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: profil și emisiune

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

ÎNTREBĂRI FRECVENTE

Am nevoie de un wildcard?
Dacă apar adesea subdomenii noi, da (prin DNS-01). În caz contrar, utilizaţi multi-SAN pentru domenii explicite.

Ce să alegeți: cert-manager sau certbot?
Kubernetes → manager de cert. VM/microservices din K8s → certbot/lego/acme. sh. PKI intern → Vault/step-ca.

TTL poate fi redus la o zi?
Pentru mTLS interne, da, în cazul în care automatizarea/sidecar garantează rotația și aplicațiile pot reîncărca la cald.

Cum de a asigura DNS-01?
Separat token/acces minim la zona, rotație cheie, restricționa accesul IP API, audit.

Total

Managementul TLS fiabil este o combinație între profilul cripto corect, eliberarea automată și reînnoirea, rotațiile zero-downtime, observabilitatea și procedurile clare de incident-răspuns. Construiți o conductă ACME/PXI, adăugați alertă strictă și instruiți în mod regulat scenarii de „urgență” - iar certificatele expirate nu vor mai fi sursa pagerelor de noapte.