Modifiche ai certificati TLS: perché disciplina operativa e automazione sono essenziali

Per anni, la gestione dei certificati TLS è stata considerata principalmente una questione di procurement: acquistare, installare e ricordarsi di rinnovare. Un modello che funzionava quando la validità dei certificati era lunga e gli ambienti IT relativamente semplici.

Ma questo modello sta per diventare obsoleto.

Il CA/Browser Forum ha infatti introdotto un nuovo percorso di riduzione della validità dei certificati pubblici. Se il processo di rinnovo della tua organizzazione parte ancora da un ordine di acquisto e da un promemoria sul calendario, è il momento di ripensarlo.

La nuova timeline è chiara: la validità massima dei certificati pubblici scende a 200 giorni da marzo 2026, a 100 giorni da marzo 2027, fino ad arrivare a soli 47 giorni da marzo 2029. Parallelamente, si restringono anche le possibilità di riutilizzo della validazione del dominio, che entro il 2029 sarà limitata a una finestra di soli 10 giorni.

In pratica, il rinnovo dei certificati TLS pubblici diventerà un processo operativo ad alta frequenza, non più un’attività annuale da spuntare dalla lista.

Per i responsabili IT, questo va letto soprattutto come una sfida progettuale.

La dimensione nascosta della proliferazione dei certificati

Una validità di 47 giorni è facilmente gestibile per un singolo server. Ma la situazione cambia quando si parla di centinaia o migliaia di endpoint.

Uno studio Venafi del 2024 ha rilevato che le aziende con più di 250 dipendenti gestiscono in media 3.730 certificati TLS, e solo una piccola parte di questi è completamente automatizzata.

Nelle architetture reali, i certificati sono distribuiti in numerosi punti dell’infrastruttura: load balancer, CDN, API gateway, ingress Kubernetes, VPN, mail server, gateway IoT e applicazioni legacy.

Il rischio non è teorico.

Un certificato scaduto può provocare un’interruzione immediata del servizio: i browser mostrano pagine di errore, le chiamate API e le pipeline CI/CD falliscono a livello TLS e un certificato scaduto su un WAF o un API gateway può rendere indisponibili tutti i servizi dipendenti.

Nel settore e-commerce questo può tradursi in una perdita di ricavi. Nel banking può diventare un incidente di natura regolamentare e compromettere la fiducia dei clienti. Nel settore pubblico può significare l’interruzione di un servizio destinato ai cittadini.

La compliance entra a far parte del ciclo di vita

Il nuovo scenario cambia anche il livello di responsabilità richiesto alle organizzazioni.

La protezione delle chiavi private non è più soltanto una buona pratica: diventa un obbligo contrattuale e legale. Chiavi deboli o compromesse possono invalidare i certificati, mentre certificati compromessi o contenenti informazioni non corrette devono essere revocati entro 24 ore.

Anche la validazione dei domini si sta evolvendo verso metodi più rigorosi e basati sul DNS, con un ruolo sempre più importante per DNSSEC.

Dal nostro punto di vista, quindi, la domanda non è più se l’organizzazione disponga di un fornitore di certificati.

La vera domanda è: l’organizzazione è in grado di dimostrare continuamente che ogni identità pubblica è valida, protetta, monitorata e, se necessario, revocabile?

Dal rinnovo manuale alla gestione automatizzata del ciclo di vita

In un mondo in cui i certificati durano 47 giorni, l’automazione non è un’ottimizzazione: è un prerequisito per garantire la continuità operativa.

Il ciclo di vita deve comprendere tutte le fasi: discovery, inventario, validazione, emissione, deployment, reload, monitoraggio e gestione degli incidenti.

ACME consente di automatizzare richiesta, validazione, emissione e installazione dei certificati. Ma ACME, da solo, non è sufficiente.

L’organizzazione ha comunque bisogno di una gestione centralizzata, di una pianificazione DNS per i record TXT e CAA, di procedure per il reload dei servizi, di workflow per la revoca e di meccanismi in grado di intervenire rapidamente in caso di errore.

L’automazione può essere costruita attraverso piattaforme enterprise come Venafi, Keyfactor, AppViewX, DigiCert TLM o Sectigo, oppure attraverso strumenti open source come cert-manager e HashiCorp Vault, particolarmente adatti agli ambienti cloud-native.

La scelta della piattaforma è importante, ma conta ancora di più il modello operativo: responsabilità chiare, processi ripetibili e un allineamento continuo ai requisiti del CA/Browser Forum.

La PKI interna non è la fine della storia

La regola dei 47 giorni riguarda i certificati pubblici esposti su Internet. Ma la disciplina operativa deve estendersi anche all’interno dell’organizzazione.

Private CA, PKI interne e certificati utilizzati per le comunicazioni service-to-service richiedono comunque governance e controllo.

I team già sotto pressione per gestire il rinnovo frequente dei certificati pubblici non avranno capacità sufficiente per gestire anche un ambiente interno non governato.

Da dove partire?

Il primo passo non è acquistare un nuovo software. È fare una valutazione dell’ambiente esistente.

Occorre:

  • mappare tutti i certificati TLS pubblici;
  • identificare ownership ed esposizione;
  • verificare i metodi di validazione dei domini;
  • controllare la robustezza delle chiavi e lo stato delle certificate chain;
  • tracciare le dipendenze su gateway, WAF e CDN;
  • progettare un’architettura di automazione in grado di sostenere certificati a breve durata senza richiedere interventi manuali.

Da qui, la roadmap diventa più chiara: assess, design, implement e managed operation.

Per i responsabili IT, il cambiamento è semplice da definire: i certificati TLS non sono più una voce di acquisto. Sono diventati un servizio operativo continuo.

Le organizzazioni che si preparano per tempo possono trasformare una scadenza di compliance in un’opportunità per migliorare e rendere più resiliente la propria gestione operativa.

Chi aspetta, invece, dovrà affrontare la stessa trasformazione sotto pressione. E in quel caso il vero costo non sarà l’automazione, ma il rischio di outage, data breach e conseguenze regolamentari.

 

Vuoi approfondire il tema e capire come preparare la tua organizzazione?

Scrivici a welisten@sorint.com per una consulenza.