Certificato client autofirmato? Il server VPN lo rifiuta comunque

L’operatore invia un indirizzo e un nome utente, e il client chiede un file di AC, un certificato e una chiave. Generare questi tre elementi localmente sembra il passo successivo ovvio. Si ottiene un certificato a cui crede solo la vostra macchina. La fiducia del server è ancorata a un’AC che non controllate, quindi lo handshake finisce prima di iniziare.

La fiducia vive sul server, non nel vostro profilo

L’autenticazione tramite certificato è un confronto. Il client presenta un certificato; il gateway verifica se è stato firmato da una delle AC nella sua configurazione.

Il vostro profilo indica il file di AC che il client deve usare per verificare il server. Non può indicare un’AC che il server deve usare per verificare voi. Quella metà della configurazione non è vostra.

Un certificato fatto da voi fallisce questo confronto anche quando è tecnicamente perfetto. Ha una firma valida, un soggetto e delle date, ma l’emittente è un’AC di cui il gateway non ha mai sentito parlare. L’errore compare durante lo handshake, dopo che il server ha già chiesto un certificato. Nulla nel profilo del client può cambiare la risposta.

Perché un certificato autofirmato non può sostituirlo

Un certificato autofirmato è firmato con la propria chiave. La firma si verifica contro lo stesso file, il che lo rende autocoerente e inutile come credenziale per il gateway di qualcun altro.

Il gateway non chiede se il certificato è coerente al suo interno. Chiede se lo ha firmato un emittente fidato.

Per questo i messaggi di errore confondono. Il client può segnalare un errore di verifica che sembra un problema del server, mentre il server registra un emittente sconosciuto. Entrambi descrivono la stessa discrepanza da estremità opposte.

La via della CSR conserva la vostra chiave privata

Potete ancora fare la maggior parte del lavoro localmente. Generare una coppia di chiavi, costruire una richiesta di firma del certificato attorno alla metà pubblica e inviare quella richiesta all’operatore. Solo la richiesta lascia la vostra macchina. La metà privata resta dove l’avete generata.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

L’operatore firma la richiesta con la sua AC e restituisce un certificato. La vostra chiave privata non ha mai viaggiato, e il risultato si concatena all’ancora di cui il gateway si fida.

I servizi gestiti spesso saltano la CSR ed emettono il pacchetto intero. È uno scambio ragionevole quando lo stesso fornitore termina già il tunnel e detiene l’AC. La custodia della chiave non migliora tenendola, perché il fornitore potrebbe coniarne una nuova in qualsiasi momento.

I pacchetti si importano, non si installano

I pacchetti dei fornitori con nomi che suonano sicuri sono spesso profili OpenVPN. Contengono configurazione e talvolta certificati, e non installano nulla. Importate il file in un client che parla il protocollo, e la connessione è configurata.

La regola di gestione deriva dal contenuto. Se il profilo incorpora una chiave privata, è una credenziale e merita la stessa cura di una password: niente email, niente repository, niente cartella di download condivisa. Quando l’operatore fornisce ca.crt, client.crt e client.key separatamente, conservateli insieme con permessi restrittivi e puntate il profilo su di essi.

Aggiungete i controlli che l’operatore potrebbe aver saltato

Un profilo generato dal router a volte manca della verifica del peer. remote-cert-tls server richiede che il certificato del peer porti lo scopo di autenticazione server, così un certificato client non può essere riprodotto come server. Quella riga è una piccola modifica con una giustificazione chiara.

verify-x509-name va oltre quando l’operatore può indicare il soggetto o il SAN attesi. Entrambi sono piccole aggiunte a un profilo, ed entrambi sono difendibili. Ispezionate ciò che avete ricevuto prima di importarlo.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Le impostazioni di verifica non sono una riparazione di una catena rotta. Se l’emittente è sbagliato, la risposta è un certificato dall’AC giusta, non un flag che disattiva il controllo. Disattivare la verifica trasforma un errore di autenticazione in uno non rilevato.

Chiedete un solo pacchetto: il certificato dell’autorità in PEM, un certificato client firmato da quell’autorità, una chiave che avete generato o che è arrivata tramite un canale di cui vi fidate, e il nome esatto del server che il certificato deve presentare. Annotate la data di scadenza nello stesso messaggio, perché un certificato scaduto sembra un guasto di rete mesi dopo.