Cosa controlla il tuo client VPN prima di fidarsi di un certificato

Il tuo client VPN dice che il certificato non è stato verificato, e la finestra si ferma lì. Il file c’è, il server è attivo, e lo stesso profilo funzionava su un altro portatile il mese scorso. Sotto quell’avviso di una riga il client ha fatto passare il certificato del peer attraverso quattro cancelli: un’autorità di certificazione che hai configurato garantisce il percorso della firma, quel percorso raggiunge l’autorità, il nome del peer è quello che hai richiesto, e il certificato è utilizzabile adesso per questo scopo. Trova il cancello che si è chiuso e la riparazione di solito è un file; salta quel passaggio e reimporterai pacchetti tutto il pomeriggio.

Leggi la finestra prima di modificare il profilo

Gli errori dei certificati sono formulati dalla libreria sottostante, non dal prodotto VPN che hai installato, quindi la stringa esatta è la tua prima prova. «Impossibile ottenere il certificato dell’emittente locale» indica il percorso o l’ancora di fiducia. «Il certificato è scaduto o non è ancora valido» indica il tempo. «Scopo del certificato non supportato» indica l’uso esteso della chiave. Una mancata corrispondenza del nome ti dice quale nome voleva. Nessuno dei quattro si ripara reinstallando il client.

Alza il livello di log prima di cambiare qualsiasi cosa. OpenVPN segnala l’errore di verifica intorno allo handshake quando lo esegui con --verb 4, e strongSwan scrive le sue decisioni su identità e catena nel log charon. Poi conferma quale certificato stai esaminando, perché di solito si prova il file su disco mentre il profilo incorpora una copia più vecchia. Quando il profilo incorpora blocchi PEM, il certificato incorporato è quello in prova.

Un’autorità di certificazione firma identità, non permessi

L’autorità detiene un nome e una chiave di firma. Emette certificati che legano una chiave pubblica a quel nome secondo la propria politica, con una finestra di validità e vincoli d’uso allegati. Il tuo client ha bisogno solo del certificato dell’autorità per riconoscere l’emittente; non ha mai bisogno della chiave di firma, e distribuire quella chiave ai client darebbe loro la capacità di coniare qualsiasi identità di cui si fida la distribuzione.

Fidarsi di un’autorità rende candidato ogni certificato che ha firmato, non il peer giusto. Anche un certificato di server web della stessa CA interna è un candidato. Per questo esistono i cancelli di nome e scopo, e per questo una chiave CA compromessa conta più di qualsiasi server singolo: raggiunge ogni identità che l’autorità abbia mai emesso. Distribuisci certificati client per dispositivo, così un portatile perso è una revoca e non una rigenerazione di chiavi su tutta la distribuzione.

Ricostruisci il percorso che il client sta cercando di costruire

Il percorso va dal certificato del peer, attraverso zero o più intermedi, a una radice nel tuo archivio di fiducia. Un intermedio mancante è il guasto di catena più comune, e dal lato client appare identico a una radice non attendibile. Leggi prima la foglia, poi lascia che OpenSSL costruisca il percorso con il materiale che intendi distribuire.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Uno stato di uscita zero significa che il percorso è stato costruito da quei file; un errore nomina il certificato che non è riuscito a raggiungere. Se openssl verify riesce mentre il client rifiuta ancora, la differenza sta in ciò che il server invia davvero o in quale file di fiducia carica il profilo. In OpenVPN gli intermedi possono viaggiare nel file del certificato del server o essere forniti separatamente con --extra-certs, e un pacchetto con due radici scritte sotto lo stesso nome di soggetto manderà uno dei tuoi client sul ramo sbagliato.

Nome e scopo sono cancelli separati

La costruzione della catena non chiede mai se il nome è tuo. OpenVPN lo controlla solo quando il profilo imposta --verify-x509-name, e la vecchia abitudine di far corrispondere solo il nome comune si rompe sui certificati le cui identità vivono in subjectAltName. Le distribuzioni IKEv2 confrontano l’identità configurata con le voci SAN o con il nome distinto, a seconda del client, e un valore jolly o %any disattiva silenziosamente il confronto che credevi di avere.

Poi vengono tempo e scopo. Un portatile il cui orologio è avanti di qualche ora rifiuta un certificato non ancora valido, e un intermedio scaduto fa fallire il percorso mentre la foglia è valida. I guasti di scopo derivano da un certificato senza serverAuth nell’uso esteso della chiave, o con un keyUsage che non consente la firma dello handshake, che OpenSSL segnala come scopo del certificato non supportato. Reemetti dal modello corretto; nulla in quel messaggio è un motivo per disattivare la verifica.

La revoca funziona solo se qualcuno l’ha configurata

Una CRL o una risposta OCSP non vengono consultate automaticamente. Su un server OpenVPN i certificati client vengono confrontati con un elenco solo quando --crl-verify ne indica uno. Il controllo del certificato del server lato client dipende dall’implementazione ed è spesso assente. strongSwan ha bisogno del suo plugin di revoca e di una politica prima di guardare una CRL per un peer.

Questo spiega il ticket che prima o poi riceverai: un certificato client revocato si connette ancora, e tutti concludono che la revoca è rotta. Niente stava controllando. Pubblica e aggiorna la CRL, oppure tieni i certificati client così effimeri che una revoca obsoleta conti per poco, e prova il percorso di revoca su un certificato di laboratorio prima di averne bisogno durante un incidente.

Un ordine di riparazione che tiene attiva la verifica

Ordina per sintomo prima di toccare i file, perché ogni riga della tabella ti manda a un oggetto diverso.

Percorri l’elenco in un solo passaggio: conferma il file che il profilo carica, costruisci il percorso tu stesso, controlla che il server invii l’intermedio, confronta l’orologio, leggi il SAN, leggi l’EKU, poi riconnettiti e guarda scomparire la stessa riga di log. Se a un dispositivo non si può dare alcuna CA, il pinning è l’alternativa onesta, perché OpenVPN 2.6 accetta --peer-fingerprint e restringe la fiducia a una chiave invece di rimuovere il controllo. RFC 5280 è il riferimento per il significato di ciascuno di quei campi.