Da consumarsi preferibilmente entro il…

C’è un tipo di disastro informatico che ha una caratteristica unica: è l’unico che puoi segnare sul calendario con un anno di anticipo. Un certificato ha una data di scadenza scritta dentro di sé — notAfter, nero su bianco — eppure la scadenza dei certificati continua a mettere in ginocchio servizi enormi, di solito nel momento peggiore. Nel 2018 un certificato scaduto in un software Ericsson lasciò milioni di persone senza rete mobile in diversi Paesi. Non un attacco sofisticato: una data, arrivata puntuale.

È il paradosso della PKI: la tecnologia più prevedibile che abbiamo produce alcuni dei guasti più ricorrenti, perché quasi nessuno la conosce dall’inizio alla fine. Nel mio metodo un disservizio del genere è quasi un insulto — correlazione non è causazione, certo, ma qui la causa era annunciata da mesi. Vale la pena capire come funziona la fiducia digitale, perché scade, e perché dimenticarsene è un problema di organizzazione prima ancora che di tecnologia.

Il problema della fiducia, e come lo abbiamo risolto

La crittografia a chiave pubblica — nata con Diffie-Hellman nel 1976 e con RSA l’anno dopo — risolve un problema elegante: due sconosciuti possono comunicare in modo sicuro senza essersi mai scambiati un segreto prima. Ma apre subito una domanda scomoda: come faccio a sapere che quella chiave pubblica appartiene davvero a chi dice di essere, e non a un impostore nel mezzo?

La risposta è stata delegare la fiducia a terze parti riconosciute: le Certificate Authority. Una CA verifica un’identità e firma un certificato — lo standard X.509 — che lega quell’identità a una chiave pubblica. Il tuo sistema operativo e il tuo browser si fidano di un insieme ristretto di root CA, custodite in un trust store; tutto il resto discende da lì. È lo stesso meccanismo che regge HTTPS, da SSL fino alle versioni moderne di TLS.

A questa fiducia tecnica, in Europa, se ne affianca una giuridica. Il regolamento eIDAS definisce un livello «qualificato» di fiducia: prestatori di servizi fiduciari qualificati (QTSP) sottoposti a vigilanza, e certificati e firme elettroniche qualificate a cui la legge riconosce valore probatorio — è il motivo per cui una firma digitale qualificata equivale a una firma autografa. La revisione eIDAS 2 spinge oltre, verso un portafoglio europeo di identità digitale (EUDI Wallet). Per chi lavora in sanità, finanza o PA cambia la domanda: non solo «il certificato è valido?», ma «è del tipo che la normativa richiede?».

Per anni ottenere un certificato è stato costoso e macchinoso, e questo ha tenuto HTTPS un lusso. Nel 2015 Let’s Encrypt ha ribaltato il tavolo: certificati gratuiti e, soprattutto, un protocollo per automatizzarne l’emissione e il rinnovo — ACME. Da lì la durata dei certificati ha iniziato ad accorciarsi: da anni, a uno, a novanta giorni, con il settore che spinge verso finestre ancora più brevi. Meno tempo di vita significa meno tempo utile per un certificato rubato — ma significa anche che rinnovare a mano non è più un’opzione.

Come funziona, in breve

Ogni certificato contiene una chiave pubblica, un’identità (il nome del sito), un intervallo di validità (notBefore e notAfter) e la firma di chi lo ha emesso. La chiave privata corrispondente resta segreta sul server e non lascia mai la macchina — idealmente custodita in un modulo hardware dedicato.

E qui vale la pena insistere: la sicurezza dell’intero sistema poggia sulla segretezza di quella chiave privata. Se viene rubata, un attaccante può impersonare il servizio finché il certificato resta valido — ed è il motivo per cui, negli ambienti che se lo possono permettere, le chiavi vivono dentro moduli hardware (HSM) da cui non escono mai, nemmeno per chi le usa.

Quando ti connetti, il server presenta il suo certificato e la catena che porta a una radice. Il client fa una serie di controlli che quasi nessuno elenca per intero: la firma risale a una radice di cui mi fido? Il certificato è nel suo intervallo di validità, cioè non è scaduto né «non ancora valido»? Il nome corrisponde al sito che ho chiesto? È stato revocato? Basta che un solo controllo fallisca e la connessione si interrompe con uno di quegli errori che l’utente non capisce e imputa «al sito che non va».

La validità è, in fondo, un TTL come quello del DNS: una finestra oltre la quale la fiducia semplicemente scade. E come per il DNS, la parte difficile non è il concetto, ma la gestione su scala: tenere il conto di centinaia di certificati, ognuno con la sua scadenza, distribuiti su sistemi che nessuno ricorda di avere.

Dove si nasconde (e dove ti sorprende)

Il riflesso è pensare ai certificati come «la cosa del lucchetto nel browser». In realtà sono l’impalcatura dell’identità digitale, e vivono in posti che nessuno collega alla parola «certificato».

Il traffico tra microservizi in mTLS, dove client e server si autenticano a vicenda. Le VPN e i portali che usano certificati al posto delle password. La firma del codice, che dice al sistema operativo che un eseguibile è autentico. L’identità delle macchine e dei dispositivi IoT. E soprattutto Kubernetes, dove praticamente ogni componente — API server, kubelet, etcd — parla in TLS con certificati che, se scadono, fermano il cluster in blocco. A questi si aggiungono i database, i bilanciatori, la federazione delle identità in SAML.

Ma i più pericolosi sono quelli che nessuno inventaria: la CA interna il cui certificato scade e porta giù tutto insieme, perché era la radice di fiducia di mezza infrastruttura; il certificato client di quell’integrazione fatta tre anni fa; la CA intermedia che scade prima del previsto. La regola d’oro è impietosa: non puoi rinnovare ciò che non sai di avere. Metà dei disastri da certificato non è un problema di crittografia, ma di inventario.

Un caso che ho visto più di una volta, in forme diverse: a cadere non è il certificato del sito pubblico — quello lo tengono d’occhio tutti — ma quello silenzioso di una CA intermedia interna o di un certificato di servizio, che alle prime ore del mattino manda in tilt l’autenticazione tra sistemi che «non c’entravano nulla con i certificati». Il sintomo è ovunque; la causa in un punto solo che nessuno stava guardando.

Quando la fiducia diventa una superficie d’attacco

Se la fiducia è delegata alle CA, allora una CA compromessa è una catastrofe: può emettere certificati validi per qualsiasi sito e permettere a un attaccante di impersonarlo in modo indistinguibile. Non è teoria: nel 2011 la compromissione di DigiNotar fu usata per intercettare centinaia di migliaia di utenti, e portò alla sua rimozione da tutti i trust store. Anche un colosso come Symantec è stato progressivamente «distrusted» dai browser per pratiche di emissione poco rigorose.

C’è anche un rischio più quotidiano e meno spettacolare: il trust store che si gonfia. Ogni radice in più — aggiunta da un antivirus, da un proxy aziendale che intercetta il TLS, da un software installato senza troppe domande — è una nuova entità di cui ti stai fidando ciecamente. Un trust store è affidabile quanto è corto: più radici contiene, più ampia è la superficie che nessuno controlla davvero.

La revoca, che dovrebbe essere la rete di sicurezza, nella pratica è fragile: i meccanismi classici (CRL e OCSP) vengono spesso interrogati in modalità «soft-fail», cioè se il controllo non risponde si procede comunque. Il risultato è che un certificato rubato resta utilizzabile più a lungo di quanto dovrebbe. Le contromisure moderne vanno in due direzioni: la Certificate Transparency, registri pubblici e verificabili di tutti i certificati emessi, che rende visibile un’emissione fraudolenta; e la riduzione della durata, che limita la finestra di abuso di un certificato compromesso. Ed è proprio quest’ultima a rendere obbligatoria l’automazione: con scadenze a novanta giorni o meno, il rinnovo manuale non è sostenibile, e un processo automatico e monitorato diventa esso stesso una misura di sicurezza. È una scelta di architettura — e di gestione dell’identità delle macchine — non un dettaglio operativo.

Perché capirlo fa la differenza

La scadenza di un certificato è l’unico grande disservizio che puoi prevenire con un calendario e un po’ di automazione. Ma per farlo davvero devi capire l’intera catena: la foglia, l’intermedia, la radice, il trust store, la finestra di rinnovo. Devi possedere un inventario vivo di ciò che hai, monitorare le scadenze con anticipo, e automatizzare il rinnovo là dove è possibile. In un ambiente critico un certificato non gestito non è un rischio astratto: è un disservizio già programmato, con tanto di data.

I tecnici bravi trattano i certificati come un dettaglio finché non ne salta uno alle due di notte; poi si scopre che nessuno sapeva quanti ce n’erano, né dove. Per questo, la prossima volta che un servizio «inspiegabilmente» smette di funzionare e nell’errore compare la parola certificate, non stupirti: non è scaduto il certificato, era scaduto — e lo sapevi da un anno.

Fa parte della serie sulle fondamenta invisibili dell’infrastruttura. Leggi anche È sempre il DNS e È sempre colpa del firewall.