Come adattarsi a cicli di vita dei certificati più brevi e ai cambiamenti del PKI

Sintesi esecutiva: I programmi root dei browser stanno riducendo la durata dei certificati TLS (Transport Layer Security) da 100 giorni a 47 giorni entro il 2029, e la finestra di validazione del dominio che supporta l'emissione si sta riducendo altrettanto rapidamente. Se aggiungiamo al mix la crittografia post-quantistica, la gestione dei certificati smette di essere un'attività trimestrale e diventa un processo continuo. I processi manuali di rinnovo non sopravviveranno a questo cambiamento. L'emissione automatizzata e monitorata sì.

Punti chiave:

• La durata dei certificati TLS scende a 64 giorni entro il 2027 e a 45 giorni a febbraio 2028, portando la maggior parte delle organizzazioni da quattro rinnovi l'anno a circa 12 o 13 per certificato.
• Le finestre di riutilizzo dell'autorizzazione al controllo del dominio si riducono dagli attuali 30 giorni a anche solo 7 ore, quindi i flussi di lavoro di emissione non possono più basarsi sulle validazioni precedenti.
• Gli obiettivi di migrazione verso la crittografia post-quantistica (PQC) vanno dal 2029 per Google al 2033 per i sistemi di sicurezza nazionale degli Stati Uniti, e coinvolgono anche i formati dei certificati, non solo lo scambio delle chiavi.
• Le lacune nell'inventario dei certificati, in particolare per quelli privati, interni e di terze parti, diventano più pericolose man mano che si accorciano le durate, perché i certificati sconosciuti falliscono più rapidamente.

La durata dei certificati per i certificati TLS che assicurano i tuoi siti web, API, servizi interni e integrazioni di terze parti sta per diventare molto più breve, e la frequenza di rinnovo necessaria aumenterà di conseguenza.

I programmi root dei browser stanno riducendo il periodo in cui un certificato rimane affidabile dopo l'emissione. Matthew McPherrin, technical lead del team SRE di Let's Encrypt, ha illustrato il cambiamento in un recente webinar Red Sift ospitato da Billy McDiarmid, VP of Customer Engineering. Ha spiegato molto chiaramente la direzione: il settore si sta spostando verso certificati misurati in settimane, non più in mesi.

La timeline pubblicata è la seguente:

• Febbraio 2027: certificati di 64 giorni
• Febbraio 2028: certificati di 45 giorni
• Marzo 2029: limite industriale di 47 giorni, secondo il CA/Browser Forum Ballot SC-081v3

Oggi la maggior parte delle organizzazioni utilizza certificati di 90 giorni, rinnovandoli circa quattro volte all'anno. Con il passaggio a 47 giorni, si arriva a 12 o 13 cicli di rinnovo l'anno, per certificato. Raddoppiare i rinnovi significa raddoppiare le possibilità che un rinnovo fallito passi inosservato, con una finestra molto più stretta per intervenire prima che qualcosa si blocchi.

Durate più brevi suonano come lavoro operativo in più, e lo sono. Ma la logica di sicurezza alla base rimane solida.

McPherrin ha evidenziato due vantaggi concreti. Un certificato compromesso è utile a un attaccante solo finché è valido, quindi una durata più breve riduce quella finestra, indipendentemente da quando si scopre la compromissione. Anche la revoca diventa più semplice. Le certificate revocation list (CRL) aumentano molto durante gli incidenti, e certificati con durata minore riducono la dipendenza da dati di revoca longevi.

La revoca stessa tende a essere la parte più difficile a livello operativo. Richiede coordinamento tra team, informazione ai clienti, e lavoro manuale di sostituzione. Durate più corte riducono quanto deve durare questo ciclo di risposta.

La validazione del controllo di dominio, la prova che possiedi effettivamente un dominio prima che una certification authority (CA) ti emetta un certificato, avrà anch'essa una finestra di validità più corta.

Oggi la maggior parte delle CA ti permette di riutilizzare un'autorizzazione validata per un massimo di 30 giorni. Questa finestra scenderà a 10 giorni, e infine fino a 7 ore.

Se il tuo processo di emissione si basa su assunzioni di lunga durata, su un'approvazione manuale, su una credenziale che nessuno controlla spesso, o su un job di rinnovo che gira solo trimestralmente, è qui che il sistema si rompe prima. L'automazione deve poter rivalidare in autonomia quando il riutilizzo scade. Non può aspettare che qualcuno si accorga del problema.

Il consiglio che si ripete in tutto il settore: automatizza l'emissione e il rinnovo usando protocolli standard così che i certificati vengano sostituiti senza che nessuno debba toccare la tastiera.

Anche l'automazione può fallire. Le credenziali scadono, le API non funzionano, le pipeline si interrompono. La soluzione non è qualcuno che controlla un foglio di calcolo una volta a trimestre, ma monitoraggio, logiche di ripetizione e visibilità sull'intero percorso di rinnovo dall'emissione al reload.

In pratica, ciò significa:

• Automatizzare emissione e rinnovo tramite ACME (Automated Certificate Management Environment), il protocollo supportato dalla maggior parte delle autorità di certificazione.
• Monitorare costantemente il successo dei rinnovi, non solo le date di scadenza dei certificati.
• Testare l'intera catena end-to-end: emissione, rinnovo, distribuzione e reload del servizio.
• Evitare flussi di lavoro che si affidano ad assunzioni di autorizzazione a lungo termine.
• Provare in ambienti di test i profili a durata più breve prima che le scadenze arrivino in produzione.

ACME già riduce il vendor lock-in, dato che la maggior parte delle CA supporta lo stesso protocollo e i tuoi strumenti non devono cambiare se cambi fornitore. Vale la pena seguire alcune delle sue estensioni.

I profili ACME permettono ai client di optare per durate dei certificati più brevi prima che venga imposto l'obbligo, offrendo così alle grandi organizzazioni l'opportunità di testare la transizione ai 45 giorni prima che diventi obbligatoria.

Renewal Info è pensato per rendere la revoca lato CA meno una corsa contro il tempo, consentendo ai client di apprendere automaticamente il percorso di remediation corretto invece di costringere qualcuno a ricostruire manualmente cosa si è rotto.

I certificati a vita breve, compresa un'opzione di sei giorni tramite meccanismi di opt-in, spingono ancora di più verso l'automazione. McPherrin sottolinea in modo pragmatico: funziona solo se il monitoraggio è già settato bene, perché non c'è più spazio per un fallback manuale lento.

Si stanno inoltre sviluppando nuovi metodi di validazione per facilitare l'adozione della validazione del dominio basata su DNS anche per aziende che attualmente non possono usare le tipologie di challenge in uso.

Il rinnovo automatico non risolve nulla se non sai cosa stai rinnovando. La maggior parte degli sforzi di visibilità si limita ai certificati esposti verso l'esterno, gestiti da uno o due team. La realtà è più ampia:

• Certificati privati e interni
• Certificati in ambienti shadow IT
• Certificati di terze parti integrati in tool SaaS e integrazioni
• Certificati su servizi dismessi che nessuno ha eliminato
• Certificati associati a CDN o piattaforme esterne
• Deriva dell'inventario dopo fusioni e acquisizioni

Un inventario dei certificati è l'elenco completo e aggiornato di ogni certificato in uso nella tua organizzazione, compreso dove è installato, quale CA lo ha emesso, quando scade e quali sistemi lo presentano o lo considerano affidabile. Quando le durate si accorciano, i certificati sconosciuti falliscono prima e il rischio di disservizio causato da un rinnovo mancato cresce proporzionalmente.

Le durate più brevi sono il problema a breve termine. La crittografia post-quantistica (PQC) è quello a lungo termine, e riguarda allo stesso tempo la fiducia dei browser, i formati dei certificati, gli algoritmi di firma delle CA e le tempistiche di supporto dei dispositivi.

Gli obiettivi di migrazione variano a seconda del settore. Google punta al 2029. I sistemi di sicurezza nazionale USA guardano al 2030 e 2033. NIST e i programmi governativi allineati definiscono gli standard dietro entrambi.

La PQC non è un singolo interruttore da attivare. Le firme post-quantistiche tendono a essere più grandi di quelle attualmente in uso e firme più grandi significano maggiore uso di banda e handshake TLS più lenti su larga scala. Una proposta per risolvere il problema, i Merkle Tree Certificates, raggruppa i dati di validazione delle firme e li distribuisce ai browser fuori banda anziché allegare una firma completa a ogni handshake TLS. Ma il vantaggio arriverà solo quando browser e client li supporteranno.

La migrazione PQC non riguarda solo i certificati. Anche lo scambio delle chiavi, la parte del TLS che negozia un segreto condiviso per la sessione, è importante a causa di un modello di minaccia noto come harvest now, decrypt later: un attaccante cattura traffico cifrato oggi e aspetta che la computazione quantistica renda possibile decifrarlo in futuro.

Il consiglio di McPherrin qui è semplice da mettere in pratica rispetto al lato certificati: usa TLS 1.3 e attiva lo scambio chiavi ibrido post-quantum ovunque l'infrastruttura lo supporti. Comporta meno rischi rispetto alla migrazione completa dei certificati, perché è più probabile che sia retrocompatibile e non richiede di cambiare i formati dei certificati.

I dispositivi con risorse limitate non si adattano facilmente a un piano standard di Web PKI (public key infrastructure). Limiti di batteria, banda ridotta e meccanismi di aggiornamento minimi fanno sì che molte installazioni IoT finiranno probabilmente per avere più diversità algoritmica rispetto ai server e ai browser. Alcuni dispositivi potranno supportare soluzioni basate su Merkle tree. Altri necessiteranno di strategie di firma differenti con compromessi diversi in termini di banda. Qualunque sia il piano per la tua infrastruttura web, verifica che sia compatibile con i cicli di vita dei dispositivi prima di pensare che funzioni con l'IoT.

Cercare di risolvere durata dei certificati, automazione ACME, lacune nell'inventario e preparazione alla PQC nello stesso trimestre è il modo migliore per trovarsi con downtime imprevisti. Suddividi le attività in parti che puoi testare in sicurezza:

1. Prova i profili a durata ridotta in un ambiente di test.
2. Rafforza il monitoraggio dei rinnovi e i flussi di deployment e reload associati.
3. Costruisci una copertura completa dell'inventario dei certificati, inclusi quelli interni e di terze parti che spesso sfuggono ai team.
4. Attiva TLS 1.3 e lo scambio chiavi ibrido post-quantum dove è supportato.
5. Pianifica la prontezza dei certificati PQC secondo le tempistiche realistiche di supporto di browser e dispositivi, non la prima data possibile.

La gestione dei certificati sta passando da qualcosa che si controlla una volta al trimestre a qualcosa che dovrai gestire costantemente. Come ha detto McPherrin, aspettati che il Web PKI abbia sempre meno pazienza per chi gestisce ancora tutto a mano.

Conoscere davvero quali certificati possiedi, automatizzare il loro rinnovo e monitorare attentamente tutto il percorso ti permetteranno di individuare le configurazioni errate prima che causino un disservizio.

Se ancora tieni traccia dei certificati su un foglio di calcolo, Red Sift's Certificate Essentials offre totale trasparenza sui certificati e monitoraggio in tempo reale, così non sfugge nulla. Include ispezione DNS, verifica della sicurezza TLS e monitoraggio pronto per la PQC, pronto a seguire i cambiamenti futuri. Se ti serve una guida pratica per iniziare con l'automazione ACME, la guida introduttiva di Let's Encrypt è un ottimo punto di partenza.

Puoi anche guardare il webinar completo on demand per tutte le domande e risposte, comprese le problematiche dei dispositivi IoT e come funzioneranno i certificati post-quantum con ACME.