Verso il rinnovo mensile dei certificati

Alla fine del 2024, Apple ha sorpreso tutti riducendo la durata massima dei certificati a soli 45 giorni. Ci sono voluti alcuni mesi e un paio di piccole revisioni, ma ad aprile 2025 la decisione è stata ufficializzata tramite il voto SC-081v3 del CA/Browser Forum. Se non ne sei già a conoscenza, i cambiamenti sono piuttosto drastici: la durata massima consentita passa dagli attuali 398 giorni a soli 47 giorni nel marzo 2029. Non c’è tempo da perdere, perché ci sono due tappe intermedie: la prima riduzione a 200 giorni è prevista per marzo 2026 (ormai vicina!) e la seconda a 100 giorni a marzo 2027.

In pratica, stiamo passando dai rinnovi annuali di oggi, a due rinnovi all’anno nel 2026, a quelli trimestrali nel 2027, fino ad arrivare a rinnovi mensili nel 2029. 

Di conseguenza, tutti si stanno affannando per individuare dove sono presenti certificati pubblici e implementare delle automazioni. A lungo termine, questi cambiamenti rappresenteranno un beneficio, ma il carico di lavoro aggiuntivo a breve termine rappresenta un onere considerevole per molti.

Let's Encrypt, la CA gratuita da cui la maggior parte del mondo ottiene i propri certificati, e la CA che ha introdotto i certificati a 90 giorni, prevede tempi ancora più rapidi: ridurrà la validità dei suoi certificati a 45 giorni nel febbraio 2028. Probabilmente non è qualcosa che ti riguarda troppo da vicino: i loro certificati sono sempre emessi automaticamente, il che significa che non dovrai fare altro che osservare il cambiamento.

Ci sono molti validi motivi per preferire durate ridotte per i certificati. Considera i seguenti punti:

• Il rinnovo manuale è uno spreco. Sono state spese innumerevoli ore di lavoro per pianificare, coordinare ed eseguire questa attività ripetitiva. Inoltre, ogni modifica manuale comporta la possibilità di causare malfunzionamenti, il cui ripristino richiede ulteriori risorse. Quando la durata del certificato si riduce, il rinnovo manuale diventa impraticabile e ciò porterà tutti a dover implementare delle automazioni. A lungo termine, tutti ne trarranno beneficio.
• Il rinnovo automatico è agile. Le PKI pubbliche pongono grande attenzione alla correttezza dei certificati. Essere rigorosi evita lunghe discussioni su quanto gravemente un errore possa influire su una emissione. L’ecosistema ha scelto di essere pignolo, così da evitare tali polemiche. Pertanto, quando si commettono errori, bisogna correggerli anche se non hanno effetti pratici. Il rinnovo forzato causato da errori delle CA non piace mai ai clienti, ma l’automazione risolve il problema. In RFC 9773, ACME è stato esteso per consentire alle CA di attivare la sostituzione automatica dei certificati errati.
• Durate più brevi incentivano l’agilità crittografica. Un tempo facevamo affidamento sulla funzione hash SHA1 per le firme dei certificati, per poi scoprire che era insicura. La migrazione a SHA2 fu lenta, anche perché molti certificati a lunga scadenza utilizzavano ancora SHA1. I browser non potevano quindi semplicemente smettere di accettarli, pena problemi immediati. Con durate più brevi, la gestione di problematiche simili diventa più semplice.
• Il controllo di revoca non viene eseguito. Alcuni anni fa, i principali browser hanno deciso di rinunciare al controllo della revoca per motivi di prestazioni, disponibilità e privacy. (Firefox è l’unica eccezione, con l’implementazione di una soluzione denominata CRLite attualmente su desktop). Questo crea una situazione scomoda: in caso di compromissione di un certificato, la finestra temporale per poterne abusare è di ben 398 giorni. Ridurre la durata dei certificati è l’unica soluzione davvero affidabile a questo problema.
• Certificati residui ovunque. Oggi è raro ottenere certificati proprietari. Preferiamo affidarci a piattaforme, che li generano per nostro conto. È uno degli aspetti ambigui delle PKI pubbliche: questi certificati portano il nostro dominio ma sono gestiti da terzi. Quindi, di chi sono i certificati? Se cambi piattaforma, i vecchi certificati rimangono attivi… da qualche parte. Lo stesso accade con il passaggio di proprietà di un dominio: il precedente proprietario mantiene un certo controllo anche quando non gli appartiene più. Maggiori informazioni in questo articolo di ricerca. Durate di certificato più brevi riducono anche l’impatto di questo problema.

È evidente che la direzione è positiva, ma meno ovvio è perché la soglia debba essere fissata a 47 giorni. Si potrebbe obiettare che anche 90 giorni sarebbero sufficienti, con minore rischio di sovraccarico dei sistemi di emissione e monitoraggio. D’altra parte, potremmo vedere in futuro un’accelerazione verso durate ancora più brevi… ma sarebbe difficile giustificarlo a tutti.

Nell’Annual Report 2024, l’Internet Security Research Group (ISRG, l’organizzazione dietro Let's Encrypt) ha portato all’estremo la riduzione della durata dei certificati e annunciato certificati di sei giorni per il 2025. Per la maggior parte delle organizzazioni non avrebbero senso, ma sono perfetti per chi vuole minimizzare il rischio derivante da certificati compromessi: nel peggiore dei casi la finestra di esposizione è solo di sei giorni. È addirittura una garanzia migliore di quella offerta dal controllo di revoca online (come implementato nella pratica), che era di 7 giorni.

Mi piace la "archeologia" delle PKI, quindi ho passato un po’ di tempo a ricostruire la storia delle durate massime dei certificati. In un certo senso, i cambiamenti di questi anni riflettono l’evoluzione delle PKI pubbliche: da un “far west” agli inizi, a un sistema oggi regolato e monitorato rigorosamente. È anche un po’ una soap opera.

Le prime restrizioni furono introdotte con la prima versione delle Baseline Requirements (BR) del CA/Browser Forum, che stabilisce le regole per l’emissione dei certificati. Prima del BR non c’erano limiti: era possibile ottenere un certificato anche per 10 anni, se lo si desiderava. La prima versione BR nel 2012 impose il limite a 60 mesi, con una successiva riduzione a 39 mesi rinviata al 2015.

Due anni dopo, nel 2017, ci fu un primo tentativo fallito (Ballot 185) di limitare i certificati a 398 giorni. Praticamente tutte le CA votarono “no”. Curiosamente, anche due produttori di browser votarono “no” e uno si astenne. Tuttavia, solo un mese dopo, Ballot 193 andò a buon fine e la durata fu ridotta a 825 giorni.

Due anni più tardi, nell’ottobre 2019, il secondo tentativo di portare la durata a 398 giorni (Ballot SC-022v2) fallì nuovamente. Le CA non erano favorevoli: leggendo le motivazioni, il problema principale era l’aumento del carico sui clienti. Fare qualcosa due volte costa il doppio. I browser non risentono di questo, le CA sì: gli incentivi erano diversi e questa votazione rivelò profondi contrasti fra questi attori.

Alla fine, anche se Google sosteneva SC022, Apple prese una decisione unilaterale e durante il CA/Browser Forum meeting del febbraio 2020 annunciò che da settembre 2020 non avrebbe più accettato certificati oltre i 398 giorni. Formalmente, il cambiamento al BR fu sancito dal Ballot SC-031, significativamente intitolato “Browser Alignment”.

Come già sai, anche la recente proposta dei 47 giorni è partita da Apple. Questa volta quasi tutte le CA hanno votato a favore: la domanda è quante lo desiderassero davvero e quante si siano sentite obbligate.

A essere onesti, la situazione nel 2025 appare molto migliore per quanto riguarda l’automazione, dopo 10 anni di emissioni automatiche tramite Automatic Certificate Management Environment (ACME). C’è forse la sensazione che l’automazione totale sia davvero a portata di mano? Inoltre, questa votazione prevede chiaramente un approccio graduale, per poter tornare indietro in caso di gravi problemi.

Un’attenta lettura di Ballot SC-081v3 (che ha introdotto la riduzione finale delle durate) rivela un analogo accorciamento dei periodi di riutilizzo della validazione. Se non hai dimestichezza con le PKI potresti non sapere che le validazioni si possono riutilizzare – ma è così.

Un tempo, quando quasi tutte le validazioni erano manuali, la possibilità di riutillizzare i risultati della validazione era un enorme risparmio di tempo per clienti e CA. Le CA validavano i propri clienti e i relativi domini solo periodicamente, dopodiché potevano emettere certificati [per i loro asset] quasi istantaneamente. Chiunque abbia affrontato una validazione manuale sa che può richiedere giorni. Questo meccanismo era pienamente giustificato e ha davvero snellito il lavoro.

Per la validazione del soggetto (ad esempio, l’identità dell’organizzazione) il limite attuale è di 825 giorni, che scenderà a 398 giorni nel marzo 2026, senza ulteriori riduzioni. Dato che richiede sempre lavoro manuale, ha senso permettere un riutilizzo più lungo.

Invece, per il riutilizzo dei risultati della validazione di domini e indirizzi IP, che può essere automatizzata completamente, il periodo sarà accorciato in modo analogo alle durate dei certificati, con una soglia finale di soli 10 giorni.

Questi cambiamenti spingono ulteriormente verso l’automazione di tutto ciò che è automatizzabile. Si tratta di una più ampia attività di “pulizia”, che ha incluso anche il ritiro dei metodi di validazione più vecchi, come WHOIS, email e telefono (ad esempio SC-090, SC-091 e SC-080v3). In questo modo, i proprietari di dominio avranno maggiore controllo su chi può rilasciare certificati per i loro asset. Tuttavia, non dovrebbe necessariamente significare più lavoro per nessuna delle parti, perché saranno introdotte nuove funzionalità che permettono di comunicare in modo continuo chi è autorizzato a emettere, come un record DNS persistente per la validazione del dominio (anch’esso parte di SC-091).