Certificati TLS e rinnovo automatico

Perché è necessario

TLS crittografa il traffico « », conferma l'autenticità del server (e del client) e protegge contro la sostituzione. I rischi principali sono il ritardo dei certificati, chiavi deboli, catene di fiducia sbagliate, procedure manuali. Lo scopo dell'articolo è di descrivere l'architettura in cui i certificati sono sempre validi e le rotazioni sono discrete per gli utenti.

Concetti di base

CA/Firmatario: autorità di certificazione (pubblica o interna).
Chain (fullchain) - Certificato di lamiera + intermedio + radice (in genere radice nei repository client).
SAN (Subject Alternative Name) - Elenco di domini/IP per un singolo certificato (multi-SAN).
Wildcard: `.example. com "è utile per molti sottotitoli, richiede una convalida DNS.
OCSP stapling: il server applica lo stato di richiamo recente riduce i ritardi e la dipendenza da OCSP esterni.
HPKP: obsoleto/non utilizzato; invece, loghi CT e igiene chiave.
CT (Certificate Transparency) - I fogli di rilascio pubblici sono importanti per il controllo delle versioni false.

Crittoprofile e chiavi

• ECDSA (P-256): veloce e compatto preferita per i clienti moderni.
• RSA-2048/3072 è ancora più compatibile; è possibile mantenere dual-cert (RSA + ECDSA).
• Generazione delle chiavi: solo sul lato target (non trasferire i privati in rete), proteggere i diritti di accesso ('0600').
• HSM/KMS: per le zone critiche (pagamenti/PII), memorizzare le chiavi in HSM/KMS, attivare il controllo delle transazioni.
• Tempi di vita: certificati brevi (90 giorni/30 giorni per quelli interni) incoraggiano la rotazione frequente e riducono il rischio di compromissione.

Modelli di gestione architettonica TLS

1. CA pubblico tramite ACME (Let's Encrypt/Buypass/ecc.)

Convalida HTTP-01 (tramite Web Server/Ingress) o DNS-01 (per wildcard/domini extra-thread).
Pro: gratuito/automatizzato, ampia fiducia. Contro dipendenze esterne.

2. CA aziendale interna

Strumenti: HashiCorp Vault PKI, Smallstep (step-ca), Microsoft AD CS, CFSSL.
Pro: politica di castoma, mTLS, TTL brevi, rilascio per domini interni. Contro: distribuzione radice, gestione della fiducia.

3. Ibrido

CA pubblico per utenti esterni CA interno - per servizio-a-servizio (mTLS), canali interclaster e ammiragli.

Pattern di rinnovo automatico (renew)

Principi generali

Soglia di estensione: inizia a 30 giorni dalla scadenza; per i servizi critici a 45 giorni.
Zero-downtime: rilascio di un nuovo certificato, sostituzione atomica, reload fluido senza interruzione delle connessioni.
Doppia forza (blue/green) - Memorizza il cert corrente e il cert seguente; il passaggio è tramite symlink o segreto versionalizzato.
Alerting: avvisi per 45/30/14/7/3/1; un alert separato in caso di fallimento del challenge ACME.

Client ACME e loro applicazione

certbot / acme. sh/lego: agenti leggeri su VM/bare-metal.
cert-manager (Kubernets) - Operatore che lavora con l' Issuer/ClusterIssuer. automatizza release/renew e scrive in Secret.
step-ca/Vault Agente: rilascio automatico/rotazione con TTL brevi, sidecar-pattern per l'aggiornamento di chiavi e catene.

Processi per Kubernets

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

La sostituzione a caldo in NGINX-Ingress avviene automaticamente quando si aggiorna «Secret». Aggiungete «ssl-ecch-curve: secp256r1» e attivate OCSP stapling tramite annotazioni/ConfigMap.

Processi VM/Bare-metal

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

Periodico «certbot renew» attraverso systemd timer.
Per wildcard utilizzare DNS-01 (provider plugin) e un «--deploy-hook» simile.

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"

Sostituzione atomica NGINX

Conservate'fullchain '. pem` и `privkey. pem 'sotto i percorsi stabili (symlink sui file versionati), seguito'nginx -s reload'.

PKI interno e 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

Accesso automatico: tramite Vault Agente Inquector (K8s) o sidecar; l'applicazione rilegge il cert dal file/FS-watcher.
TTL brevi: 24-720 ore per stimolare la rotazione frequente e ridurre il valore della chiave rubata.
mTLS: rilasciare certificati client per servizi/ruoli specifici all'ingresso - mutual TLS in ingress/sidecar-proxy.

Funzionamento sicuro

Separazione dei segreti: chiavi private - solo su host/sottofondo, accesso ai minori privilegi.
Diritti file: '600' per la chiave; proprietario - Utente del processo.
Il periodo di Grace è sufficiente per tenere conto dei guasti DNS/ACME/provider.
OCSP Stapling - Attiva sui fronti monitorare la freschezza della risposta (solitamente 12-72 h).
HSTS: abilita gradualmente (senza «pratoad» alla partenza) assicurandosi che tutti i contenuti vengano consegnati correttamente da HTTPS.
Dual-cert (RSA + ECDSA) - Migliora la compatibilità e le prestazioni ai clienti moderni di consegnare ECDSA.

Monitoraggio e SLO

• Giorni precedenti alla scadenza (gauge) per ogni dominio/segreto; SLO: nessun cert da <7 giorni a expiry.
• Validità della catena (linting), conformità SAN ai domini/IP richiesti.
• Stato OCSP stapling (risposta recente).
• Percentuale di successi/fallimenti del challenge ACME.
• Leitensi TLS strette di mano, versioni del protocollo/cifrario.

• Warn: 30 giorni prima della scadenza.
• Crit: 7 giorni/fallimento «renew».
• Pagina: 72 ore/catena di non-calore in vendita/mancante OCSP stapling.

Incidenti e rimborsi

Ritardo del certificato: reindirizzare e fissare manualmente il certificato, fissare l'RCA (perché non è stato attivato il RCA, il blocco DNS/API).
Compromettere la chiave: reimpostazione immediata, rotazione dei segreti, controllo degli accessi, rotazione dei token del provider DNS/ASME.
Catena non valida: deposito urgente «fullchain» corretto, rettifica di fronte forzata.
Lock-in al provider DNS - Mantenere il percorso di convalida di riserva (HTTP-01) o il DNS secondario.

Foglio di assegno per l'implementazione del rinnovo automatico

1. Selezionare un modello (CA pubblico tramite ACME/PKI/ibrido interno).
2. Definire il crittoprofile ECDSA-P256, se necessario, dual-cert con RSA-2048.
3. Impostare l'agente automatico (cert-manager, certbot, acme. sh, Vault Agent).
4. Organizza un ricambio zero-downtime (symlink-pattern, hot-reload ingress/NGINX/Avvoy).
5. Includere OCSP stapling e HSTS (graduale).
6. Aggiungere alerting a scadenze e states challenge; prescrivere lo SLO.
7. Documentare i processi break-glass e manuale.
8. Eseguire esercitazioni «feeling»: DNS-01 rotto, ACME collassato, radice scaduta/intermedio.
9. Rivedere l'accesso alle chiavi private, ruotare i token del provider DNS e gli account ACME.

Caratteristiche iGaming/Fintech

PCI DSS/PII: Cipher Suites rigoroso, TLS 1 obbligatorio. 2+/1. 3, spegnere codici/compressioni deboli, sessione respumption senza compromessi di sicurezza.
Segmentazione dei domini: certificati separati per sottocartelle di pagamento e ammiragli; per i provider di contenuti - catene isolate.
Controllo e logica: fissa il rilascio/review/rotazione; firmare manufatti CI/CD.
Multiregionalità: Issuer locali per regione per non dipendere da guasti crocifissi.

Esempi di configurazione

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"

Profilo e estrazione 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

C'è bisogno di wildcard?
Se sono frequenti nuovi sottotitoli, sì (tramite DNS-01). In alternativa, utilizzare la multi-SAN per domini espliciti.

Cosa scegliere tra cert-manager o certbot?
Kubernetes → cert-manager. VM/microservizi fuori da K8s → certbot/lego/acme. sh. PKI interno di Vault/step-ca.

È possibile ridurre la TTL a 24 ore?
Per gli interni, sì, se l'automazione/sidecar garantisce la rotazione e le applicazioni sanno hot-reload.

Come mettere in sicurezza DNS-01?
Accesso singolo/minimo alla zona, rotazione delle chiavi, limitazione dell'API IP, controllo.

Totale

La gestione affidabile di TLS è una combinazione di cryptoprofilm, rilascio automatico e rinnovo, rotazioni zero-downtime, osservabilità e procedure chiare per l'incidente-response. Costruisci una catena di montaggio ACME/PXI, aggiungi un alerting rigoroso e alleni regolarmente gli scenari di emergenza e i certificati scaduti smetteranno di essere la fonte dei cercapersone notturni.