Ciclo di vita e revoca dei certificati

Ogni certificato digitale segue un ciclo di vita definito, dalla creazione al ritiro. Le fasi sono: Richiesta e registrazione (generazione della coppia di chiavi, creazione del CSR), Emissione (la CA convalida e firma), Distribuzione (installazione sul server o sul dispositivo), Utilizzo (periodo operativo attivo), Rinnovo (prima della scadenza) e Revoca o scadenza (fine del ciclo di vita). Gestire questo ciclo su larga scala, soprattutto nelle aziende con migliaia di certificati, richiede strumenti di automazione e di certificate lifecycle management (CLM), poiché il monitoraggio manuale porta inevitabilmente a certificati scaduti che causano interruzioni del servizio.

Il ciclo di vita del certificato inizia con una Certificate Signing Request (CSR). Il richiedente genera una coppia di chiavi, quindi crea un CSR che contiene la chiave pubblica, le informazioni sul Subject (CN, O, C) ed è firmato con la chiave privata (dimostrando il possesso della chiave privata senza rivelarla). Il CSR viene inviato alla CA, che convalida l'identità del richiedente e, se approva la richiesta, firma il certificato. La chiave privata non lascia mai il possesso del richiedente. La generazione del CSR è il passaggio fondamentale in cui viene determinata la robustezza della chiave: è necessario utilizzare almeno RSA a 2048 bit o ECC a 256 bit.

I certificati devono essere rinnovati prima che scada la data notAfter. La pratica raccomandata consiste nell'avviare il processo di rinnovo almeno 30 giorni prima della scadenza (molte organizzazioni puntano a 60-90 giorni). Il rinnovo prevede in genere la generazione di un nuovo CSR e di una nuova chiave privata, l'invio alla CA e la sostituzione del vecchio certificato e della relativa chiave su tutti i server in cui sono distribuiti. Let's Encrypt automatizza questo processo utilizzando il protocollo ACME: lo strumento certbot rinnova automaticamente i certificati quando mancano meno di 30 giorni alla scadenza. I certificati scaduti causano errori nei browser che impediscono agli utenti di accedere ai servizi.

La revoca del certificato è il processo che invalida un certificato prima della data di scadenza prevista. Tra i motivi di revoca vi sono: la chiave privata è stata compromessa (il caso più urgente, che richiede la revoca immediata), il certificato è stato emesso per errore (dominio errato, organizzazione errata), le informazioni del Subject sono cambiate (l'azienda ha cambiato nome, un dipendente ha lasciato l'organizzazione) oppure la CA stessa è stata compromessa. La revoca è fondamentale perché i browser e i sistemi che non sanno che un certificato è stato revocato continueranno a considerarlo attendibile, offrendo a un aggressore in possesso della chiave privata rubata la possibilità di effettuare un attacco MITM fino alla scadenza del certificato o finché la revoca non viene rilevata.

Una Certificate Revocation List (CRL) è un elenco firmato pubblicato da una CA che contiene i numeri di serie di tutti i certificati revocati dalla CA e non ancora scaduti. I client scaricano la CRL, la memorizzano nella cache e verificano se il numero di serie di un certificato presentato compare nell'elenco. Le CRL presentano limiti significativi: possono essere molto grandi (le CA di grandi dimensioni hanno milioni di certificati revocati), i client spesso le memorizzano nella cache per ore o giorni, introducendo ritardi, e scaricare l'intera CRL per ogni connessione è inefficiente. Le CRL sono ancora utilizzate, ma vengono sempre più spesso affiancate o sostituite da OCSP.

OCSP (Online Certificate Status Protocol) consente di verificare in tempo reale la revoca dei certificati senza che i client debbano scaricare intere CRL. Il client invia al responder OCSP della CA una richiesta contenente il numero di serie del certificato. Il responder risponde con una risposta firmata che indica se il certificato è good, revoked (con data e motivo della revoca) oppure unknown. OCSP è più veloce e tempestivo delle CRL, ma ogni connessione TLS richiede un ulteriore round trip HTTP verso il responder OCSP, con conseguente latenza. Le risposte OCSP sono firmate dalla CA per impedire manomissioni.

OCSP Stapling risolve il problema della latenza causata dal controllo OCSP in tempo reale. Anziché interrogare il responder OCSP della CA durante ogni handshake TLS, il server recupera in anticipo la propria risposta OCSP dalla CA e la «staples» (la allega) all’handshake TLS. Il client riceve direttamente dal server una risposta OCSP aggiornata e firmata dalla CA, senza richiedere un ulteriore round trip. Il server aggiorna periodicamente la risposta OCSP allegata (in genere ogni ora). OCSP Stapling migliora la velocità di connessione e riduce il carico sui responder OCSP delle CA, mantenendo al contempo il controllo della revoca.

OCSP Must-Staple è un’estensione X.509 che comunica ai browser che il server deve fornire una risposta OCSP allegata. In sua assenza, se il controllo OCSP non riesce, i browser eseguono un «soft fail»: consentono comunque la connessione, per evitare che eventuali interruzioni dei responder OCSP blocchino tutte le connessioni TLS. Un attaccante può sfruttare questo comportamento bloccando la richiesta OCSP del client e facendo sembrare che il certificato sia ancora valido anche dopo la revoca. OCSP Must-Staple impedisce questo attacco richiedendo una risposta allegata valida; in sua assenza, il browser rifiuta la connessione. L’adozione rimane limitata a causa della complessità di distribuzione.

La revoca dei certificati e il certificate pinning affrontano lo stesso problema — la fiducia nei certificati fraudolenti — ma da prospettive diverse. La revoca (CRL/OCSP) è un meccanismo reattivo: la CA invalida un certificato dopo che è stato scoperto un problema. Il pinning è un meccanismo proattivo: l’applicazione rifiuta qualsiasi certificato diverso da quello approvato in precedenza. Il pinning offre garanzie più solide della revoca perché funziona anche se la CA non revoca tempestivamente il certificato, ma introduce una maggiore rigidità nella distribuzione. Per l’esame Security+, è necessario conoscere entrambi i meccanismi e comprendere che la revoca è il meccanismo PKI standard, mentre il pinning è una misura opzionale di difesa in profondità.

Quando un certificato viene revocato, la CA assegna un codice motivo della revoca che aiuta client e amministratori a comprenderne la ragione. Tra i codici motivo comuni definiti nella RFC 5280 figurano: keyCompromise (la chiave privata è stata compromessa), cACompromise (la CA emittente è stata compromessa), affiliationChanged (l’organizzazione del soggetto è cambiata), superseded (è stato emesso un nuovo certificato in sostituzione), cessationOfOperation (il dominio non è più attivo) e privilegeWithdrawn (l’autorizzazione è stata revocata). Il codice motivo compare sia nelle voci della CRL sia nelle risposte OCSP, fornendo un contesto ai team di risposta agli incidenti che analizzano gli eventi di revoca.

Il protocollo ACME (Automatic Certificate Management Environment), utilizzato da Let's Encrypt, automatizza l’intero ciclo di vita dei certificati. I client ACME (come certbot) richiedono, rinnovano e distribuiscono automaticamente i certificati senza intervento umano. La CA utilizza le prove di convalida del dominio per confermare la titolarità del dominio: la challenge HTTP-01 richiede di collocare un file specifico in un URL noto; la challenge DNS-01 richiede di creare un record TXT DNS. ACME ha trasformato la gestione dei certificati: oggi i certificati di 90 giorni di Let's Encrypt, rinnovati automaticamente, proteggono una grande parte del traffico HTTPS di Internet.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) presentati in questa lezione.

In questa lezione ha imparato che il ciclo di vita dei certificati va dalla generazione della CSR all’emissione, alla distribuzione e al rinnovo o alla revoca; la CRL fornisce elenchi di revoca in batch, mentre OCSP fornisce lo stato in tempo reale dei singoli certificati; OCSP Stapling elimina la latenza dell’OCSP in tempo reale; e ACME (Let's Encrypt) automatizza l’intero ciclo di rinnovo. Ora esamineremo i casi d’uso della PKI.