La revoca dei certificati fallisce: quale host non raggiunge cosa

I certificati possono trovarsi entro il periodo di validità mentre la VPN continua a segnalare un errore di autenticazione, e qualcuno conclude che il certificato è revocato. Sono tre fatti diversi. I dati di revoca deve recuperarli il dispositivo che esegue la convalida, da un punto di pubblicazione indicato all’interno del certificato stesso. Quando quel dispositivo non riesce a raggiungere il punto, il controllo fallisce per motivi estranei allo stato del certificato.

Il validatore possiede il percorso di recupero

Iniziate identificando il validatore. Quando un portatile controlla il certificato del gateway, è il portatile a eseguire il recupero; quando il gateway controlla un certificato client, è il gateway a farlo. Un servizio di autenticazione nel back-end può aggiungere un terzo validatore con la propria posizione di rete. Ognuno ha un percorso diverso verso internet e una configurazione proxy diversa. Le prove raccolte sulla postazione di un amministratore non dicono nulla su un server all’interno di una DMZ.

Annotate il certificato, il validatore, l’ora del tentativo e il codice di stato esatto prima di cambiare qualsiasi cosa.

Leggete il punto di pubblicazione dal certificato

Il certificato indica dove risiede il suo stato. Leggete quei campi invece di indovinare un indirizzo della CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

La prima estensione elenca i punti di distribuzione CRL, la seconda elenca i metodi di accesso alle informazioni dell’autorità, che possono coprire lo stato OCSP e il recupero del certificato dell’emittente. Sono meccanismi diversi, e un responder OCSP non è un file CRL. L’host di pubblicazione è spesso un normale server web e non la macchina della CA, perché un emittente offline può firmare una CRL che un altro server distribuisce. Una regola del firewall descritta come accesso alla CA è quindi troppo vaga per essere attuata o verificata.

Provate il recupero dal dispositivo che convalida

Eseguite il test di recupero nell’ambiente che esegue davvero la convalida, con materiale di certificato approvato e senza chiavi private.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

L’esecuzione di certutil verifica la catena e riporta quali recuperi di URL sono riusciti o falliti, mentre la chiamata curl prova un solo indirizzo di pubblicazione dallo stesso host e restituisce solo un codice di stato. Un recupero fallito da un indirizzo raggiungibile indica problemi di contenuto o di firma; un errore di connessione indica instradamento, DNS o proxy. Conservate entrambi i risultati, perché un recupero riuscito non dimostra che l’intera catena sia utilizzabile. Sostituite host e percorso dell’esempio con il punto di distribuzione trovato nel certificato.

Separate i dati mancanti dallo stato revocato

Quattro esiti sembrano uguali dall’esterno: il punto non è raggiungibile, l’elenco è scaduto, l’elenco è firmato dall’emittente sbagliato, oppure il certificato è davvero revocato. Solo l’ultimo è un esito di stato, e solo quello giustifica la rimozione dell’accesso. La cache complica ulteriormente il quadro, perché i dati recuperati in precedenza possono nascondere un percorso di pubblicazione guasto fino al refresh successivo. Disattivare il controllo di revoca, eliminare certificati non correlati o riavviare il gateway sostituiscono tutti la diagnosi con l’attività.

Dopo la correzione, forzate una nuova autenticazione e confermate che il recupero di stato previsto riesca. Dove esiste un’identità di test controllata, confermate che viene ancora rifiutata, perché una disponibilità che elimina il controllo non è una riparazione.