Certificato VPN revocato ancora connesso? Verifica l'applicazione della CRL

Hai revocato il certificato, generato una lista nuova, e il vecchio profilo apre ancora un tunnel. La revoca in sé non è rotta: una CRL è una dichiarazione firmata che un numero di serie non è più valido, e cambia l'accesso solo quando il componente che termina TLS la carica, per l'emittente giusto, prima di prendere la decisione di accettazione. È lì che sta la maggior parte di questi casi, ed è per questo che revoca e rifiuto sono due fatti distinti.

Percorri i cinque controlli qui sotto in ordine, e fermati al primo che non regge, perché ogni controllo successivo dà per veri i precedenti.

Verifica quale componente prende la decisione di accettazione

Individua il processo che convalida il certificato del client, perché solo quel processo può applicare una lista. Su un server OpenVPN è il daemon stesso, configurato con crl-verify. Su ocserv è la riga crl in ocserv.conf. Su strongSwan gli input sono le CRL caricate insieme a strictcrlpolicy. Un proxy o un appliance che termina TLS davanti alla VPN può essere il verificatore reale, e se lo è, il daemon dietro non vede mai il certificato del client.

WireGuard appartiene a un'altra categoria. Non ha certificati né lista di revoca; un peer viene ammesso dalla sua chiave pubblica nella configurazione, quindi chiudere l'accesso significa rimuovere quella chiave. Se cerchi una CRL in un deployment solo WireGuard, quel meccanismo non c'è.

Occhio anche alla trappola lato client. Un client che rifiuta di connettersi perché non gradisce il certificato del server sta applicando la catena del server, non revocando la propria credenziale. Un certificato utente viene revocato solo dove quel certificato utente viene convalidato, e questo è quasi sempre il lato server.

Verifica per quale emittente è stata firmata la lista

Una CRL è limitata a una CA emittente. Con una radice e un'intermedia, i certificati foglia provengono dall'intermedia, quindi la lista che conta è la CRL dell'intermedia; la lista della radice non dice nulla su quelle foglie. Un verificatore puntato sul file sbagliato la analizza allegramente, non trova nessuna voce corrispondente e accetta tutto.

Conferma l'accoppiamento prima di toccare il daemon. L'emittente del certificato deve corrispondere al subject della lista:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Quando entrambi provengono dalla stessa CA, il numero di serie stampato per il certificato è il valore che deve comparire nella lista. Se non coincidono, hai la CRL sbagliata o la copia sbagliata.

La validità appartiene allo stesso controllo. Un nextUpdate nel passato rende la lista obsoleta, e un verificatore che fallisce chiuso rifiuterà allora tutti i client invece del solo revocato.

Verifica che il numero di serie sia nella copia caricata dal daemon

La revoca scrive una voce nel database della CA, e la rigenerazione scrive un file nuovo. Nessuna delle due azioni raggiunge un daemon in esecuzione che ha caricato la copia vecchia all'avvio. Esegui il dump della lista e cerca il numero di serie:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Poi verifica come la tua implementazione prende il file. OpenVPN legge un percorso passato a crl-verify una volta all'avvio, quindi una lista nuova richiede un riavvio o un segnale di riavvio; la stessa opzione puntata a una directory viene riletta a ogni connessione, ed è per questo che esiste la modalità directory. strongSwan deve ricaricare le proprie credenziali, per esempio con swanctl --load-creds. Che il file su disco sia corretto e che il verificatore lo usi sono due fatti diversi.

Verifica la politica per una lista mancante o scaduta

Questa è la decisione che molti deployment non prendono mai esplicitamente, e decide se la revoca ti protegge o chiude fuori tutti. Fail-closed significa che nessuna informazione di revoca utilizzabile produce un rifiuto; fail-open significa che il verificatore procede senza. strongSwan espone la scelta come strictcrlpolicy. OpenVPN con crl-verify si rifiuta di avviarsi su un file che non riesce a leggere o analizzare, e una lista scaduta compare come errore di verifica TLS su una CRL scaduta invece che come accettazione silenziosa.

Qualunque direzione scegli, l'automazione conta più della scelta: un job che rigenera la CRL prima di nextUpdate e un avviso quando la copia distribuita invecchia tengono entrambe le politiche lontane dal diventare un incidente. Il controllo online con OCSP sposta la freschezza su un responder, ma vale la stessa regola, perché un verificatore non configurato per controllare la risposta non cambia nulla.

Verifica la sessione attiva, poi le copie della chiave

La revoca viene valutata durante la convalida del certificato, che avviene alla connessione e alla rinegoziazione. Una sessione stabilita continua finché non rinegozia, e il valore predefinito di OpenVPN è una volta all'ora con reneg-sec 3600. Se la persona deve uscire dalla rete subito, termina la sessione oltre a pubblicare la lista, e poi conferma che la riconnessione viene rifiutata.

Separa la credenziale dalle sue copie. Cancellare un profilo su un portatile non impedisce a un'altra copia della stessa chiave privata di autenticarsi; la revoca è ciò che rende inutile ogni copia, e solo quando i controlli precedenti reggono. Dai a un dispositivo sostitutivo il suo certificato, così se ne può revocare uno senza toccare l'altro.

Prima di dichiararlo concluso: il componente di convalida è identificato, l'emittente della lista corrisponde all'emittente della foglia, il numero di serie revocato è nella copia che il daemon ha effettivamente caricato, la politica per liste mancanti o scadute è deliberata e monitorata, e la sessione attiva è stata terminata invece di attesa. I formati dietro tutto questo sono specificati in RFC 5280.