I nuovi accessi VPN falliscono mentre i certificati sono validi: controllate la CRL

Certificati con mesi ancora davanti e accessi che falliscono subito indicano due oggetti diversi con due orologi diversi. Il server rifiuta le connessioni perché l’elenco dei certificati revocati che consulta ha superato la propria data di scadenza, non perché i certificati degli utenti siano diventati obsoleti. Rinnovare un certificato utente non fa nulla per quell’elenco.

Separare i due calendari è tutta la diagnosi, e cambia quale debba essere la correzione.

Due orologi, e solo uno dei due è il certificato

Un certificato porta una finestra di validità. Un elenco di revoca dei certificati porta la propria finestra, oltre a un emittente e una firma, e i verificatori rifiutano di fidarsi di un elenco la cui ora di prossimo aggiornamento è passata. Quando questo accade, il client presenta un certificato perfettamente valido e il server interrompe comunque la connessione con un messaggio sull’elenco. Gli utenti leggono quel messaggio come «il certificato è scaduto», il che invia la richiesta di rinnovo nel posto sbagliato.

I due oggetti hanno anche proprietari diversi: il certificato viene dall’autorità che lo ha emesso, mentre l’elenco è generato secondo un calendario da chi gestisce quell’autorità. Un utente non può aggiornarlo, e la riemissione dei certificati non può prolungarlo.

Leggete l’elenco che il servizio carica davvero

Partite dalla configurazione in esecuzione invece che dal file che vi aspettate. Il percorso di crl-verify può essere assoluto, relativo al profilo o una copia incorporata in un’immagine, e il verificatore legge quella copia. Ispezionatela sul posto con openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate e confrontate le date con l’orologio del server.

Poi confermate che il file sia davvero quello in uso: controllate la sua firma con openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, che riporta un esito di verifica invece di stampare i campi in silenzio. Un elenco firmato da un’altra autorità, o una copia obsoleta lasciata in una seconda directory, fallisce esattamente come uno scaduto.

Rigenerate dal database di revoca, non da zero

Il nuovo elenco deve venire dall’attuale database di revoca dell’autorità, tramite il processo di firma approvato. Generare un elenco vuoto, o rigenerare da un vecchio backup dell’indice, annulla silenziosamente la revoca di ogni identità aggiunta dopo quel backup. Questo trasforma un’interruzione di accesso in una regressione di sicurezza, e nessuno se ne accorge perché il sintomo scompare.

Tenete l’operazione di generazione sotto controllo di versione insieme al resto degli strumenti dell’autorità, così che l’intervallo e la chiave di firma siano documentati anziché ricordati. Basta una voce di runbook che nomini il comando, il firmatario e la destinazione di pubblicazione. Così chiunque sia di turno può rigenerare senza indovinare quale file di indice faccia fede. Archiviate il numero di serie e l’ora del prossimo aggiornamento dell’elenco insieme al record di distribuzione.

Distribuite dove il verificatore guarda

Copiate il nuovo elenco nel percorso che il servizio legge, impostate proprietà e modalità in modo che l’account del servizio possa leggerlo ma gli altri no, e ricaricate o riavviate secondo il comportamento documentato. Se il demone mette in cache l’elenco all’avvio, sostituire il file senza ricaricare non cambia nulla che il processo in esecuzione noterà. Confermate il timestamp che il processo riporta dopo la ricarica.

Se più servizi verificano i client, distribuite su ciascuno di essi. Aggiornare un endpoint e lasciarne un altro con la vecchia copia produce un guasto che compare solo per gli utenti che finiscono sul secondo. Tenete un breve elenco di questi endpoint nello stesso runbook. Dopo il rollout, verificate la data dell’elenco riportata da ciascuno invece di dare per scontato che la copia sia arrivata.

Rendete visibile la prossima scadenza prima che passi

Un intervallo di pubblicazione più lungo riduce la frequenza di questo incidente senza creare un processo. Scegliete l’intervallo dalla politica dell’operatore, poi impostate un avviso sul campo di prossimo aggiornamento dell’elenco distribuito con un anticipo sufficiente a rigenerare e distribuire. Avvisate sulla copia distribuita, non sull’host dell’autorità, perché è la copia distribuita a fallire.

Dopo la distribuzione, verificate entrambe le direzioni: un utente autorizzato si connette, e un’identità revocata nota fallisce ancora. Il secondo controllo è quello che intercetta una rigenerazione incompleta, e richiede un solo comando contro un profilo di test che tenete proprio per questo scopo.