Certificato della lista di revoca: una guida pratica al WiFi

Un laptop aziendale viene rubato sul treno. L'helpdesk disabilita l'account Active Directory del dipendente, il dispositivo scompare dal registro dei beni e tutti presumono che il rischio sia stato rimosso. Due giorni dopo, il laptop appare ancora sul SSID aziendale perché il suo supplicant 802.1X contiene un certificato client che non è scaduto e che nessuno ha revocato.

Questo è il divario che un processo basato su elenco di revoca dei certificati è progettato colmare. La scadenza del certificato stabilisce il limite massimo di attendibilità, mentre la revoca interrompe la fiducia in anticipo quando una chiave viene compromessa, un dispositivo viene smarrito o un utente lascia l'azienda. Per un amministratore di rete WiFi aziendale, la questione fondamentale non è la presenza dei certificati. È se il RADIUS e i relativi controlli di rete vengano informati rapidamente di un certificato revocato e gestiscano il guasto in modo sicuro.

L'Accesso WiFi Che Non Voleva Scomparire

Un deployment WiFi basato su certificati appare spesso sicuro dall'esterno. Il client utilizza EAP-TLS, il servizio RADIUS convalida la catena di certificati e le password condivise non vengono passate tra il personale. Ma quel design dipende comunque da un ciclo di vita funzionante. L'emissione di un certificato è solo l'inizio. Devi anche sapere chi lo possiede, quando scade e cosa succede se il dispositivo o la chiave privata non sono più attendibili.

Nell'esempio del laptop rubato, la rimozione dell'account da Active Directory può interrompere l'autenticazione futura della directory, ma non invalida necessariamente un certificato già installato sul dispositivo. Se il servizio WiFi si fida del certificato solo in base alla sua catena e alle date di validità, il laptop può continuare a presentare credenziali apparentemente valide. La data notAfter del certificato indica che esso rientra ancora nella sua durata prevista. Non dice che l'organizzazione emittente desideri ancora fidarsi di esso.

Regola pratica: considerare la scadenza del certificato e la revoca dello stesso come controlli distinti. La scadenza è una gestione pianificata del ciclo di vita. La revoca è il freno di emergenza.

Il modello PKI del settore pubblico del Regno Unito rende esplicita tale distinzione. Una Certificate Revocation List, o CRL, è un elenco firmato di numeri di serie di certificati revocati prima della scadenza, che indica alle parti affidatarie che tali certificati non devono più essere considerati attendibili. Le linee guida per l'infrastruttura a chiave pubblica del Regno Unito identificano inoltre le CRL come uno dei metodi di revoca comuni e si aspettano che i client verifichino se un certificato presentato appare nell'elenco della CA emittente.

Questo aspetto è fondamentale per il WiFi poiché le decisioni di autenticazione avvengono al perimetro della rete, spesso attraverso numerosi controller, access point, server RADIUS e archivi di convalida memorizzati nella cache. Un aggiornamento manuale della CRL può lasciare una lacuna di sicurezza, mentre una policy di chiusura in sicurezza (fail-closed) mal progettata può causare un'interruzione del servizio se il punto di distribuzione della CRL diventa non disponibile.

Il modello mentale di funzionamento è semplice: la CA emette e firma le informazioni sullo stato, la parte affidataria le verifica e la rete rifiuta un certificato che è stato revocato. Il resto di questa guida esamina il funzionamento di questo processo, le differenze tra CRL e OCSP e il modo in cui i controlli di accesso basati su directory possono eliminare gran parte dell'ostacolo rappresentato dalla revoca manuale.

Che cos'è effettivamente un certificato di lista di revoca

In parole povere, una Certificate Revocation List è un avviso ufficiale di "non considerare più attendibili questi certificati" emesso da un'autorità di certificazione. Identifica i certificati tramite i loro numeri di serie, non tramite un nome descrittivo del dispositivo o l'indirizzo email di un dipendente. Un client che trova il numero di serie del certificato presentato nella relativa lista deve rifiutarlo, anche se la data di scadenza del certificato è ancora nel futuro.

La definizione del Regno Unito è formale. Descrive una CRL come un elenco firmato di numeri di serie di certificati revocati prima della scadenza, per cui le relying party non dovrebbero più fidarsi di tali certificati. La firma è importante perché un server RADIUS o un altro verificatore deve confermare che l'elenco provenga dall'emittente previsto e non sia stato alterato durante il transito. Una blocklist in formato testo semplice gestita da un amministratore non fornisce tale garanzia crittografica.

Tre parti rendono utile questo processo:

• L'autorità di certificazione: La CA, o un emittente CRL autorizzato, crea l'elenco e lo firma utilizzando una chiave privata associata alla gerarchia di attendibilità emittente.
• La relying party: Un server RADIUS, supplicant, controller, sistema operativo o strumento amministrativo scarica l'elenco, ne convalida la firma e le informazioni sulla validità, quindi cerca il numero di serie del certificato.
• Il titolare del certificato: La persona, il dispositivo o il servizio il cui certificato è stato revocato. Il suo numero di serie rimane nell'elenco in modo che i verificatori possano identificarlo come non attendibile.

Una CRL non è normalmente un certificato nel senso comune in cui lo è il certificato di un utente o di un dispositivo. È un artefatto PKI firmato che contiene informazioni sull'emittente, sulla validità e sulla pubblicazione. A volte si usa l'espressione "certificato dell'elenco di revoche" come abbreviazione per il meccanismo di revoca dei certificati, ma l'oggetto operativo effettivo che viene verificato è la CRL firmata.

La relying party di solito non chiede alla CA di spiegare perché a un utente debba essere negato l'accesso. Segue le informazioni di revoca del certificato, recupera la CRL corrente dell'emittente, verifica la CRL e controlla il numero di serie. Se c'è una corrispondenza, il certificato è revocato. In caso contrario, il risultato è comunque limitato dalla freschezza della CRL e dalla cache della relying party stessa.

Quest'ultimo punto causa molti incidenti. Un certificato potrebbe essere assente da un vecchio elenco memorizzato nella cache e presente in uno più recente. La decisione della rete dipende quindi sia da ciò che la CA ha pubblicato sia da quando l'autenticatore lo ha recuperato l'ultima volta.

Come Funziona una CRL Dietro le Quinte

Il ciclo di vita di una CRL segue una catena di eventi prevedibile. In primo luogo, la CA genera un elenco di base in base alla sua politica dei certificati. Firma l'elenco, aggiunge i campi di pubblicazione e validità e lo rende disponibile tramite un punto di distribuzione. I certificati emessi si riferiscono comunemente a tali percorsi tramite l'estensione CRL Distribution Points, consentendo a un validatore di scoprire a dove appartengono le informazioni sullo stato.

Quando un amministratore revoca un certificato di un dispositivo, la CA ne registra il numero di serie e i dettagli del motivo. Il certificato non apparirà necessariamente subito nella cache di ogni relying party. La successiva CRL pubblicata deve contenere la voce e ciascun server RADIUS o controller deve recuperare una copia corrente prima di poter prendere la decisione corretta.

Alcuni ambienti PKI utilizzano anche CRL delta. Una CRL delta contiene solo le modifiche apportate rispetto a una CRL di base, riducendo così il traffico di trasferimento e l'elaborazione quando l'elenco completo è di grandi dimensioni. Questa efficienza non elimina la necessità di gestire l'elenco di base, convalidare le firme, tracciare l'aggiornamento dei dati o garantire che ogni componente di rete comprenda il modello di pubblicazione scelto.

La finestra di freschezza

Le policy del Regno Unito forniscono punti di riferimento utili per riflettere sulla propagazione. La dichiarazione di pratica CVCA del governo del Regno Unito richiede che le CRL vengano emesse al massimo ogni 90 giorni e che un certificato revocato appaia nella relativa CRL entro 72 ore dalla revoca. Tali limiti sono descritti nella UK national certificate policy.

Altre policy del Regno Unito utilizzano aspettative di servizio differenti. HM Land Registry stabilisce che il proprio elenco di revoca per i certificati revocati e sospesi deve essere aggiornato almeno una volta al giorno, mentre la dichiarazione sulla pratica di certificazione dell'Università di York prevede una latenza massima di 10 giorni tra la revoca e l'emissione della CRL. Questi esempi, tra cui il punto di pubblicazione della HMPO Country Signing Certificate Authority, dimostrano perché un amministratore debba leggere la policy effettiva della CA emittente anziché presumere che ogni CRL si comporti allo stesso modo.

Al momento dell'autenticazione, il server RADIUS controlla il numero di serie del certificato rispetto alla CRL disponibile localmente. Controlla anche se la CRL rientra nel suo periodo di validità, se la firma si collega all'emittente previsto e se il punto di distribuzione è raggiungibile quando è previsto un aggiornamento. Il server memorizza quindi il risultato in cache in base alla sua implementazione e al valore nextUpdate della CRL.

Ciò produce un'equazione di rischio pratica senza bisogno di calcoli complessi: la latenza di revoca include il tempo di pubblicazione della CA, il ritardo di distribuzione, la durata della cache e la frequenza di autenticazione. Una policy può pubblicare rapidamente, ma una cache RADIUS disconnessa o non aggiornata può comunque ritardare l'applicazione.

CRL vs OCSP e Perché È Importante per il WiFi

Le CRL e l'OCSP risolvono lo stesso problema di fondo in modi diversi. Una CRL fornisce al validatore un lotto firmato di numeri di serie revocati. L'OCSP interroga un responder autorizzato sullo stato di un singolo certificato nel momento in cui viene verificato.

Per un amministratore WiFi aziendale, la scelta influisce su aspetti che vanno oltre l'eleganza della PKI. Modifica il comportamento di un controller su una rete WAN congestionata, la gestione richiesta all'infrastruttura CA e la possibilità di completare un tentativo di autenticazione quando un responder o un punto di distribuzione non è raggiungibile.

Criterio	CRL	OCSP
Aggiornamento dati	Periodico. Un certificato appena revocato attende la pubblicazione e l'aggiornamento da parte del client.	L'interrogazione per singolo certificato può fornire uno stato più recente quando il risponditore è raggiungibile.
Carico infrastrutturale	I client scaricano ed elaborano un elenco, il che può essere efficiente per controlli ripetuti su un parco macchine gestito, ma può generare traffico di distribuzione.	Il risponditore gestisce le singole richieste di stato, il che evita il download dell'intero elenco ma aumenta il volume delle richieste.
Privacy	La parte ricevente ottiene un elenco e non ha bisogno di rivelare ogni controllo di certificato alla CA.	Una query diretta può rivelare al risponditore quale certificato viene controllato.
Modalità di guasto	Una CRL irraggiungibile o scaduta può impedire una convalida dello stato affidabile. Le cache locali possono continuare a funzionare fino al loro limite di validità.	Un risponditore irraggiungibile influisce sulla singola query di stato, e il comportamento di soft-fail o hard-fail configurato determina l'esito per la connessione WiFi.

Un controller che serve un campus di grandi dimensioni potrebbe preferire una CRL memorizzata nella cache locale perché può verificare molti numeri di serie di certificati senza inviare una richiesta separata per ogni autenticazione. Questo modello funziona bene quando i punti di distribuzione sono raggiungibili, gli aggiornamenti vengono monitorati e la policy RADIUS gestisce intenzionalmente un elenco scaduto.

OCSP può essere adatto a una progettazione in cui l'operatore necessita di una risposta per singolo certificato e accetta la dipendenza da un responder. Può ridurre la necessità di trasferire un elenco completo, ma introduce una dipendenza di rete in tempo reale durante l'autenticazione. Lo stapling può spostare l'interazione con il responder altrove in alcuni protocolli, ma la progettazione del WiFi richiede comunque una risposta chiara per i dati di stato non disponibili o scaduti.

Le linee guida del Regno Unito sono utili in questo caso perché non presentano la CRL come unico metodo. La politica del Regno Unito descrive le CRL come uno dei meccanismi di revoca comuni, mentre le linee guida del settore della giustizia le considerano come un meccanismo offline primario ed evidenziano i requisiti di disponibilità per i servizi di revoca nella dichiarazione di divulgazione PKI.

Per i dispositivi 802.1X gestiti, la CRL è solitamente pratica per la convalida periodica in batch, specialmente quando il parco macchine ha una distribuzione interna affidabile. OCSP è preferibile laddove sia essenziale una maggiore freschezza dello stato e la disponibilità del risponditore sia progettata di conseguenza. Le reti ad alta sicurezza possono eseguire entrambi, ma solo se il comportamento di fallback è documentato e testato anziché presunto.

La revoca in pratica su una rete Purple WiFi

La differenza operativa emerge quando l'accesso WiFi è legato a una directory di identità attiva invece che a un elenco di certificati gestito manualmente. Un'integrazione con la directory può rendere lo stato corrente dell'account dell'utente parte della decisione di autenticazione, in modo che la disattivazione di un account diventi un evento di controllo dell'accesso anziché un ticket che qualcuno deve successivamente tradurre in una revoca della CA.

Un flusso tipico si presenta così:

1. La directory registra lo stato dell'identità. Un account viene creato, modificato, sospeso o disattivato in Active Directory, Microsoft Entra ID o Google Workspace.
2. Il servizio di identità WiFi riceve la modifica. Il servizio mappa lo stato della directory sulla policy di autenticazione per l'organizzazione.
3. L'autenticazione successiva viene valutata in base a tale stato. Un'identità disattivata non soddisfa più la regola di accesso, anche se una credenziale precedentemente emessa rimane all'interno del periodo di validità del certificato.
4. La rete nega l'accesso. La decisione RADIUS impedisce l'autorizzazione di una nuova sessione 802.1X con l'identità inattiva.

Questo modello affronta una debolezza delle operazioni basate esclusivamente su CRL. Una CRL dipende dalla pubblicazione della CA, dai punti di distribuzione, dagli aggiornamenti della cache e dai controlli della relying party. L'applicazione guidata dalla directory rende il sistema di identità la fonte di verità operativa per lo stato dell'account, riducendo la necessità per un amministratore di trovare ogni numero di serie di certificato associato a un utente in uscita.

Distinzione operativa: una CRL risponde alla domanda se un certificato è revocato. L'autenticazione basata su directory può rispondere se l'identità è attualmente autorizzata a utilizzare la rete.

Purple fornisce RADIUS gestito e controlli WiFi aziendali basati su certificati con integrazioni di directory come Entra ID e Google Workspace. La sua offerta RADIUS-as-a-Service è rilevante quando un'organizzazione desidera collegare lo stato dell'identità all'autenticazione 802.1X senza dover gestire internamente ogni componente RADIUS locale e di revoca.

Questo non fa sparire il lavoro sul ciclo di vita della PKI. I certificati richiedono comunque l'emissione, il rinnovo, la gestione della catena di attendibilità e i controlli di revoca laddove l'architettura lo richieda. Tuttavia, elimina un collo di bottiglia manuale dal percorso di offboarding. Il service desk può disabilitare l'identità tramite il flusso di lavoro stabilito nella directory, mentre il livello di autenticazione di rete applica tale stato alla successiva decisione di accesso.

Best Practice Operative per il WiFi Aziendale

Un design di revoca affidabile combina controlli crittografici con la normale disciplina operativa. Inizia con la durata del certificato. Per i dispositivi WiFi gestiti, una durata del certificato da 12 a 24 mesi è un riferimento operativo comune nelle linee guida di implementazione fornite, ma la scelta corretta dipende dalla proprietà del dispositivo, dalla capacità di rinnovo e dai danni che una chiave privata esposta potrebbe causare. I certificati degli sponsor per gli ospiti dovrebbero generalmente avere durate più brevi perché il loro contesto di accesso cambia più spesso.

Integrare il rinnovo nel ciclo di vita dei dispositivi

Utilizza SCEP, una piattaforma MDM o un altro percorso di registrazione automatizzato per rinnovare i certificati prima della loro scadenza. Il rinnovo manuale può funzionare durante una fase pilota, ma diventa instabile in un'infrastruttura distribuita. Testa il rinnovo su laptop in modalità di sospensione, dispositivi remoti, dispositivi riconfigurati e dispositivi che non si sono connessi alla rete aziendale di recente.

Monitorare i punti di distribuzione della CRL dagli stessi percorsi di rete utilizzati da RADIUS e dai controller. Verificare la raggiungibilità, la validità della firma, l'identità dell'emittente e nextUpdate, non solo se una richiesta web restituisce contenuti. Una CRL raggiungibile ma scaduta rappresenta comunque un controllo di revoca fallito.

Mantenere pulito il lato RADIUS

I certificati dei server RADIUS hanno bisogno di una validità corrente, di una catena di emissione fidata e di un processo di rinnovo che non dipenda da una finestra di manutenzione dell'ultimo minuto. Verificare i trust store su server, controller e client gestiti per evitare che un vecchio certificato CA crei decisioni incoerenti tra i vari siti.

Documenta il runbook di revoca in un linguaggio comprensibile per un ingegnere reperibile:

• Identificare la credenziale: Registrare l'utente, il dispositivo, il numero di serie del certificato e la CA emittente.
• Disattivare l'identità: Applicare l'azione di offboarding approvata nella directory o nel reparto HR.
• Revocare quando richiesto: Aggiornare lo stato della CA e confermare la pubblicazione.
• Aggiornare le relying party: Forzare o pianificare il recupero della CRL dove supportato.
• Testare il rifiuto: Tentare l'autenticazione con la credenziale interessata e conservare il risultato.

Allinea i trigger delle risorse umane con le modifiche alla directory. Se il servizio di assistenza deve attendere un ticket PKI separato, la rete può continuare a considerare attendibile un'identità che l'organizzazione ha già contrassegnato come inattiva. Il provisioning e il rinnovo automatizzati riducono questo disallineamento, mentre una procedura manuale documentata rimane fondamentale in caso di furto di dispositivi o sospetta compromissione delle chiavi.

Per l'accesso del personale senza password, esaminare come questi controlli si integrano con la distribuzione di WPA-Enterprise, inclusi la registrazione dei certificati, la validazione RADIUS e la gestione del deprovisioning.

Risoluzione dei Problemi di Revoca Comuni

La maggior parte degli incidenti relativi alle CRL rientra in tre categorie: il validatore dispone di informazioni obsolete, non riesce a trovare il punto di pubblicazione corretto o l'archivio delle revoche è diventato difficile da gestire. Diagnosticare il percorso decisionale anziché iniziare con la riemissione dei certificati.

Una cache locale obsoleta

Un server o controller RADIUS potrebbe conservare ancora una CRL precedente alla revoca. Verifica i campi thisUpdate e nextUpdate della CRL, convalida la sua firma rispetto alla CA emittente e ispeziona la copia memorizzata nella cache dell'autenticatore. Confronta il numero di serie presentato dal client con le voci presenti nella CRL appena pubblicata.

La soluzione immediata consiste nel forzare l'aggiornamento della CRL se la piattaforma lo supporta, quindi ripetere un test di autenticazione con il certificato interessato. Se la cache continua a restituire dati obsoleti, verificare il comportamento del proxy, il caching del punto di distribuzione e la policy di aggiornamento del validatore.

Un punto di distribuzione mancante

Leggere le estensioni CDP e AIA del certificato emesso. Il CDP indica alla parte ricevente dove trovare le informazioni di revoca, mentre l'AIA può aiutarla a identificare le informazioni sull'emittente necessarie per la convalida della catena. Verificare che l'URL sia corretto, raggiungibile dalla rete RADIUS e che serva una CRL firmata dall'emittente previsto.

Se il modello della CA contiene una posizione errata, correggere il modello ed emettere certificati sostitutivi. L'aggiornamento del solo endpoint non correggerà i certificati che contengono già un punto di distribuzione inutilizzabile.

Un archivio di revoca ingestibile

Le vecchie voci possono complicare l'amministrazione e aumentare il lavoro di elaborazione. Eliminare le voci solo in conformità con la policy di conservazione della CA e solo dopo aver considerato la durata del certificato pertinente e i requisiti di audit. Non rimuovere mai un numero di serie solo perché il ticket di incidente è stato chiuso.

Gli esempi di policy del Regno Unito mostrano perché la "freschezza" deve essere definita a livello locale. Alcune autorità del Regno Unito richiedono aggiornamenti giornalieri, mentre la policy nazionale CVCA richiede la pubblicazione entro 72 ore per un certificato revocato e fissa un periodo massimo di emissione di 90 giorni. Considerateli come linee guida di policy, non come un permesso per accettare dati aziendali non aggiornati.

Uno strumento di analisi dei certificati può essere utile per verificare i dettagli dell'emittente, della validità, del CDP e della catena. Lo strumento di verifica dei certificati SSL di Purple è un'opzione valida per esaminare lo stato di salute dei certificati, mentre l'applicazione delle policy basata su directory consente di evitare di dipendere esclusivamente da un aggiornamento ritardato della CRL per il deprovisioning degli utenti.

Mettere Tutto Insieme Questa Settimana

Trasforma la revoca in un'attività assegnata anziché in un semplice paragrafo di policy. Inserisci queste azioni nella prossima finestra di manutenzione e assegna a ciascuna un responsabile designato.

• Team PKI, verificate i percorsi dei certificati: Censite ogni modello di certificato client WiFi, CA di emissione, CDP e relazione di trust RADIUS. Confermate che ogni punto di distribuzione sia raggiungibile da ogni sito di autenticazione.
• Team PKI ed endpoint, impostate una durata difendibile: Riducete la durata dei certificati client WiFi a 12 mesi o meno laddove il processo di rinnovo dei dispositivi sia in grado di supportarlo. Una durata inferiore riduce la dipendenza dalla revoca di emergenza, ma solo se il rinnovo è automatizzato e testato.
• Team endpoint, automatizzate il rinnovo: Utilizzate l'MDM o il protocollo SCEP per registrare e rinnovare i certificati senza l'intervento dell'utente. Testate il processo dopo la riconfigurazione di un dispositivo, un lungo periodo offline e un cambio utente.
• Servizio di help desk e team identity, collegate l'offboarding al diniego di accesso: Fate in modo che lo stato inattivo impostato dalle risorse umane o dall'help desk si rifletta direttamente nel controllo della directory utilizzato dall'autenticazione WiFi. Verificate che un'identità disabilitata non possa stabilire una nuova sessione 802.1X.
• Team di rete, monitorate le dipendenze di revoca: Configurate avvisi per punti di distribuzione non disponibili, CRL scadute, firme non valide e controlli di stato falliti. Iscrivetevi alle notifiche di modifica della CA affinché una variazione nella pubblicazione non comprometta l'autenticazione senza che ve ne accorgiate.

Misura due risultati durante il periodo di revisione successivo. In primo luogo, registra la latenza tra un evento di disattivazione della directory e la terminazione o il rifiuto di una nuova sessione WiFi. In secondo luogo, misura quante autenticazioni RADIUS hanno completato con successo un controllo CRL invece di proseguire attraverso un percorso di soft-fail. Queste misure indicano se il design funziona sotto pressione, e non solo se i certificati appaiono corretti in un foglio di calcolo.

Se il tuo team desidera ridurre l'amministrazione PKI manuale mantenendo al contempo un sistema WiFi aziendale basato sull'identità, Purple può fornire un'autenticazione gestita basata su certificati, decisioni di accesso connesse alla directory e servizi RADIUS che supportano il controllo delle revoche. Visita Purple per valutare come questo approccio possa integrarsi con il tuo flusso di lavoro di offboarding WiFi e con il ciclo di vita dei certificati.