Getting Ahead of Shrinking Certificate Lifespans and the Quantum Clock

Punti di forza

• Entro marzo 2029 la durata dei certificati si ridurrà da 398 a 47 giorni, mentre il “riutilizzo della convalida del dominio” scenderà a soli 10 giorni, rendendo obsoleto il rinnovo manuale e rendendo necessaria la gestione automatica del ciclo di vita dei certificati (CLM).
• Sono già in corso operazioni del tipo “Harvest Now, Decrypt Later” (Raccogli ora, decifra dopo) per archiviare dati con durata di vita lunga in vista di una futura decifrazione tramite computer quantistici; ciò comporta una minaccia immediata per i dati sensibili crittografati che prevedono una conservazione a lungo termine.
• L’inventario dei certificati e delle chiavi crittografiche è fondamentale per le aziende, che devono iniziare a crearlo fin da ora, poiché un inventario continuo e automatizzato rappresenta il primo passo verso la resilienza informatica a lungo termine e l’agilità crittografica.

Il problema nascosto dietro le quinte

La maggior parte delle reti aziendali moderne si basa su un livello nascosto costituito da certificati digitali e crittografia che la maggior parte delle persone non vede mai. Questo livello verifica l’affidabilità delle macchine e protegge i flussi di dati, ma dato che le identità delle macchine superano ormai quelle umane in un rapporto di oltre 80 a 1 nell’azienda media, secondo la ricerca di CyberArk sulle identità delle macchine, è facile sottovalutare l’importanza del livello crittografico e dei certificati.

Un modo utile per concepire un certificato digitale è quello di immaginarlo come un badge identificativo per un dispositivo. Se il badge è valido, le porte si aprono automaticamente e nessuno ci fa caso, ma nel momento in cui il badge scade o è configurato in modo errato, la porta smette di aprirsi, indipendentemente da quanto sia legittimo il dispositivo che si trova dietro. Un singolo certificato scaduto può mettere fuori uso i siti web, interrompere le API che consentono alle applicazioni di comunicare tra loro, bloccare le transazioni e causare violazioni di conformità, il tutto minando la fiducia degli utenti.

Per anni, le organizzazioni hanno gestito i certificati manualmente, ma due cambiamenti renderanno impossibile continuare a farlo manualmente. In primo luogo, la durata massima dei certificati TLS (Transport Layer Security) pubblici, il protocollo che protegge il browser, verrà ridotta a soli 47 giorni entro il 2029. In secondo luogo, l’arrivo imminente di computer quantistici abbastanza potenti da violare la crittografia odierna sta imponendo una transizione verso la crittografia post-quantistica. Queste due questioni indicano entrambe la stessa soluzione: un approccio al CLM (Certificate Lifecycle Management) governato, automatizzato e “crypto-agile”.

La roadmap alla base della riduzione della durata dei certificati

La finestra operativa per i certificati TLS pubblici si sta restringendo da un decennio. All’inizio del 2023, Google ha pubblicato per la prima volta la sua roadmap “Moving Forward, Together”, che proponeva di ridurre la validità dei certificati da 398 a 90 giorni nella speranza di spingere il settore verso l’automazione. Apple ha accelerato tale tempistica nell’ottobre 2024, presentando una bozza di votazione al CA/Browser Forum, l’organismo di settore in cui le autorità di certificazione e i produttori di browser stabiliscono regole condivise. La proposta di Apple, sostenuta da Sectigo, Google Chrome e Mozilla, è stata approvata nell’aprile 2025 come Ballot SC-081v3.

Questa riduzione avverrà in più fasi. Il precedente limite massimo di 398 giorni è già sceso a 200 giorni a partire da marzo 2026; il limite massimo sarà ridotto a 100 giorni a marzo 2027 e, infine, a 47 giorni a marzo 2029. In termini pratici, un’organizzazione che attualmente rinnova ciascun certificato circa una volta all’anno dovrà presto rinnovare ogni certificato all’incirca ogni mese e mezzo; nella fase finale, qualsiasi processo che dipenda dalla richiesta e dall’installazione manuale dei certificati da parte di una persona fallirà.

I produttori di browser stanno promuovendo queste durate di validità più brevi per imporre l’automazione, che elimina l’errore umano che è la causa principale delle interruzioni dei certificati. Inoltre, consentono all’intero web di adottare nuovi standard crittografici in poche settimane anziché in anni, poiché i vecchi certificati vengono sostituiti rapidamente. Contribuiscono inoltre a ridurre la dipendenza dai sistemi di revoca legacy, che presentano problemi di prestazioni e privacy. Infine, qualora un registro di Certificate Transparency (un registro pubblico dei certificati emessi) venisse mai squalificato, i certificati a breve durata riducono drasticamente il numero di quelli che devono essere sostituiti con breve preavviso.

La crisi della convalida

Sebbene il limite di 47 giorni faccia notizia e attiri l’attenzione, il cambiamento più dirompente potrebbe riguardare la Domain Control Validation (DCV). La DCV è il processo attraverso cui si dimostra a un’Autorità di Certificazione (CA) di avere il controllo del dominio per cui si richiede un certificato. Storicamente, una volta che un’organizzazione dimostrava la titolarità, la CA poteva riutilizzare tale prova per un massimo di 398 giorni, ma secondo lo standard SC-081v3, il periodo di riutilizzo si ridurrà a 200 giorni nel 2026 e a soli 10 giorni entro marzo 2029.

Ciò crea un vero e proprio squilibrio, poiché anche un’organizzazione che automatizza completamente l’installazione dei certificati subirà un rallentamento se non sarà in grado di dimostrare nuovamente la proprietà del dominio ogni 10 giorni. Qualsiasi ritardo nella convalida blocca l’intero processo di emissione e porta direttamente a interruzioni del servizio.

La soluzione pratica a questo problema consiste nell’adottare il protocollo ACME (Automatic Certificate Management Environment) con la convalida automatizzata tramite API DNS-01, in modo che la dimostrazione della proprietà avvenga a livello di programmazione anziché attendere l’intervento di una persona.

La minaccia quantistica e la tempistica

Mentre la durata dei certificati si riduce, gli algoritmi al loro interno devono affrontare una minaccia quantistica. Le infrastrutture a chiave pubblica (PKI) tradizionali si basano sulla crittografia asimmetrica per proteggere le firme digitali, gli scambi di chiavi e le connessioni TLS. Un computer quantistico sufficientemente potente che esegua l’algoritmo di Shor potrebbe compromettere completamente questi sistemi. Aspettare che l’informatica quantistica sia abbastanza potente da decriptare i dati non è un’opzione praticabile; come ha scritto Vidya Shankaran, Field CTO di Commvault, «la data esatta del Q-Day potrebbe rimanere incerta. La direzione in cui ci stiamo muovendo, invece, non lo è».

Secondo le stime, il Q-Day, ovvero il momento in cui un computer quantistico sarà in grado di violare la crittografia a chiave pubblica, si collocherà da qualche parte nei prossimi 5-10 anni. Tuttavia, sarebbe un errore considerarlo un problema futuro. Gli autori delle minacce stanno già conducendo operazioni del tipo «Harvest Now, Decrypt Later» (HNDL), intercettando e archiviando oggi il traffico crittografato con l’intenzione di decrittografarlo una volta che l’informatica quantistica avrà raggiunto la maturità. I dati che devono rimanere riservati per anni, come le cartelle cliniche, la proprietà intellettuale e le informazioni finanziarie, sono di fatto esposti nel momento stesso in cui vengono raccolti.

Il governo federale degli Stati Uniti ha reagito di conseguenza: nel giugno 2026, la Casa Bianca ha emanato l’Ordine Esecutivo 14412, “Securing the Nation Against Advanced Cryptographic Attacks” (Proteggere la nazione dagli attacchi crittografici avanzati), che fissa scadenze ben prima dell’obiettivo originale del NIST fissato al 2035: i sistemi federali di alto valore devono adottare la generazione di chiavi post-quantistiche entro la fine del 2030 e le firme digitali post-quantistiche entro la fine del 2031.

Nonostante questa urgenza, i progressi effettivi verso la «cripto-agilità» a livello aziendale sono stati lenti. Il rapporto «DigiCert Quantum Readiness Outlook» ha rilevato che più della metà delle organizzazioni intervistate prevede che la crittografia asimmetrica classica venga violata entro cinque anni, eppure solo il 7% ha implementato una crittografia quantistica o ibrida nel proprio parco certificati, e il livello complessivo di Readiness è migliorato di soli 2 punti percentuali nell’ultimo anno.

Perché la “crypto-agility” è importante?

Il ponte più pratico tra la crittografia classica e quella post-quantistica è il certificato composito ibrido, che combina un algoritmo classico (RSA o ECC) con un algoritmo post-quantistico (ML-DSA, lo schema di firma standardizzato basato su reticoli) all’interno di un unico certificato X.509. La combinazione di entrambi in un unico certificato è concepita in modo che il certificato rimanga valido finché uno dei due algoritmi lo sarà, il che è essenziale, poiché gli algoritmi post-quantistici sono nuovi e non hanno ancora superato innumerevoli tentativi di attacco come ha fatto l’RSA.

Tuttavia, le chiavi e le firme post-quantistiche occupano diversi kilobyte anziché poche centinaia di byte, il che aumenta la latenza di rete, comporta il rischio di frammentazione dei pacchetti durante l’handshake TLS e aggiunge un sovraccarico computazionale che potrebbe richiedere aggiornamenti hardware per i dispositivi con risorse limitate. È proprio per questo che la “cripto-agilità” è fondamentale: le organizzazioni devono poter testare, implementare e ruotare gli algoritmi senza dover riconfigurare l’infrastruttura sottostante ogni volta che gli standard si evolvono.

Gestione automatizzata del ciclo di vita dei certificati

La gestione manuale dei certificati non è solo inefficiente; è un vero e proprio rischio operativo. Quando i certificati vengono gestiti in fogli di calcolo fuori dalla vista, le organizzazioni perdono visibilità e il risultato sono credenziali scadute, chiavi di dimensioni insufficienti, algoritmi di firma obsoleti e configurazioni non conformi che nessuno nota finché qualcosa non va storto. Le interruzioni che ne derivano possono confondere gli utenti, interrompere i ricavi e ricadere sul team meno preparato a spiegarle.

Una piattaforma CLM completa affronta questo problema durante l’intero ciclo di vita di un certificato:

• Individuazione: scansione continua di ambienti cloud, data center, container e domini esterni per individuare tutti i certificati in uso.
• Monitoraggio: tracciamento in tempo reale di date di scadenza, algoritmi, livelli di sicurezza delle chiavi e conformità alle politiche di sicurezza.
• Convalida: utilizzo dell’integrazione diretta tramite API con CA pubbliche e private, automatizzando al contempo la convalida dei domini e le approvazioni
• Installazione: distribuzione dei certificati e delle chiavi rinnovati a livello di programmazione tramite ACME o API sicure, senza passaggi manuali.
• Revoca: è necessario eseguire una revoca rapida e basata su criteri, in modo che un certificato compromesso possa essere sostituito o revocato ovunque contemporaneamente, anziché doverlo individuare macchina per macchina.

C’è anche un vantaggio nascosto nella fase di individuazione: l’inventario dei certificati gestito da una piattaforma CLM costituisce, di fatto, l’inizio dell’inventario crittografico necessario per la pianificazione della migrazione post-quantistica, il che può trasformare un compito di conformità in un vantaggio competitivo.

Identità non umane e IA agentica

Il problema della scala è aggravato dal modo in cui sono costruite le applicazioni moderne. Container, pod Kubernetes, macchine virtuali, dispositivi dell’Internet delle cose (IoT) e API necessitano tutti di credenziali proprie, e molti di questi carichi di lavoro esistono solo per pochi minuti o ore prima di terminare. Nessun team di esseri umani può emettere e ritirare certificati a quella velocità.

Per stare al passo con questo ritmo vertiginoso, è possibile utilizzare agenti di IA in grado di individuare, emettere, rinnovare e gestire i certificati in autonomia, pur rimanendo entro i limiti prestabiliti quali le politiche di sicurezza, il controllo degli accessi basato sui ruoli (RBAC) e le tracce di audit centralizzate. Il risultato è un’automazione alla velocità delle macchine senza rinunciare alla governance aziendale.

Da dove iniziare

1. Il primo passo verso la «crypto-agilità» e la resilienza a livello aziendale è di natura organizzativa piuttosto che tecnica. Seguendo le linee guida del NIST, le aziende dovrebbero istituire un team centrale dedicato ai servizi di identità delle macchine che gestisca la piattaforma CLM, standardizzi i modelli di certificato e mantenga le integrazioni con le CA pubbliche e private. I singoli responsabili delle applicazioni e i team DevOps, a loro volta, dovrebbero occuparsi di integrare i rinnovi automatizzati nelle proprie pipeline di distribuzione, utilizzando la piattaforma centrale come servizio condiviso. Questa suddivisione mantiene coerente la governance, eliminando al contempo i passaggi di mano manuali che causano interruzioni del servizio.
2. Le organizzazioni dovrebbero sostituire fin da ora le tecniche e i flussi di lavoro di convalida manuali con ACME e la convalida automatizzata DNS-01, ben prima che scada il periodo di 10 giorni previsto per la DCV, eliminando progressivamente ogni processo manuale di rinnovo e convalida.
3. 1. 1. Parallelamente, le organizzazioni dovrebbero condurre un inventario completo delle proprie risorse crittografiche per individuare chiavi hardcoded, algoritmi legacy e percorsi di fiducia di lunga durata che proteggono i dati sensibili.
      2. La preparazione post-quantistica dovrebbe iniziare in un ambiente controllato piuttosto che in produzione. È necessario istituire un laboratorio di test dedicato per consentire ai team di testare certificati compositi ibridi e aggiornamenti “crypto-agili” in un ambiente sandbox. Sviluppando applicazioni su librerie crittografiche modulari collegate a una piattaforma CLM dinamica, le imprese possono ottenere una vera “crypto-agilità”: la capacità di ruotare chiavi, cifrari e algoritmi all’interno della propria infrastruttura man mano che gli standard cambiano, senza necessità di ricostruire il sistema.

Il filo conduttore che collega tutte le raccomandazioni è l’inventario. La fase di individuazione di una piattaforma CLM non è un’attività di routine prima della vera soluzione; è la stessa disciplina di cui le organizzazioni avranno bisogno in ogni livello della Readiness quantistica. I certificati sono identità non umane, e le stesse domande valgono per gli account di servizio, gli agenti di intelligenza artificiale, le dipendenze open source e gli algoritmi nascosti nel codice delle applicazioni: cosa abbiamo, cosa protegge e quale parte è più importante per l’azienda?

Le organizzazioni che rafforzano ora la propria capacità di inventario, a partire dai certificati, troveranno il resto della transizione molto meno scoraggiante, perché la definizione delle priorità diventa un calcolo piuttosto che una supposizione. Considerare i prossimi anni come una finestra di pianificazione piuttosto che come un periodo di grazia aiuterà le organizzazioni a compiere questa transizione secondo i propri tempi, invece di lasciare che sia un’interruzione a decidere per loro.

Caitlin Dodson è stagista per l’estate 2026 presso FCTO – Americas di Commvault.