remote-cert-tls server: cosa controlla in un profilo OpenVPN

Tre domande diverse ricevono risposta da tre parti diverse di un profilo OpenVPN, ed è fondendole che le persone finiscono per disattivare un controllo che funzionava. Il certificato del peer è firmato dall'autorità di cui mi fido? Quel certificato dichiara il ruolo di server TLS? È il server preciso che volevo raggiungere? remote-cert-tls server risponde solo alla domanda centrale, e lo fa leggendo le estensioni dentro il certificato.

Tre controlli facili da fondere nella testa

L'ancora di fiducia vive nella direttiva ca. Il controllo del ruolo appartiene a remote-cert-tls. Il controllo dell'identità appartiene a verify-x509-name, quando un profilo lo usa, o a qualunque controllo del nome aggiunga la distribuzione.

Coprono guasti diversi:

Un profilo può avere tutti e tre e restare debole se la CA è condivisa troppo ampiamente, il che è una questione di gestione delle chiavi e non di direttive.

Cosa legge il controllo del ruolo

La direttiva è una macro. Si espande in un requisito di utilizzo della chiave e in un requisito di utilizzo esteso della chiave che nomina il ruolo di server web TLS, quindi il certificato del peer deve davvero dichiarare quello scopo. Un certificato emesso per l'autenticazione del client non lo soddisfa, anche quando la stessa autorità ha firmato entrambi.

Questo conta perché una CA condivisa è comune nelle piccole distribuzioni. Un'autorità firma ogni client e il server, e senza un controllo del ruolo uno qualsiasi di quei certificati potrebbe completare il lato server della stretta di mano. Il controllo non rende impossibile quello scenario, ma ne elimina la versione banale.

La direttiva è asimmetrica per progettazione: i client portano remote-cert-tls server, e i server portano remote-cert-tls client. Scambiateli e ogni connessione fallisce con un errore di ruolo che sembra un certificato rotto.

I profili più vecchi a volte usano ns-cert-type per lo stesso scopo. Le pagine di manuale attuali considerano quell'opzione superata, quindi un profilo che vi si affida ancora merita una migrazione invece di un debug.

Perché disattivarlo sembra una soluzione

Quando il controllo del ruolo fallisce, la connessione si ferma con un errore di verifica e la mossa ovvia è cancellare la riga. La connessione allora sale, il che sembra un progresso ed è in realtà la modalità di guasto che la direttiva esiste per impedire. Ora accettate un peer il cui certificato non era mai destinato a quel ruolo.

Leggete invece l'errore. Nomina il controllo fallito, e il certificato dall'altra parte può essere ispezionato per vedere quali estensioni porta davvero. Due minuti di lettura decidono se il guasto è nell'emissione o nella configurazione. Indovinare costa un pomeriggio e di solito finisce con un profilo indebolito. Un certificato server rinnovato che ha perso l'utilizzo esteso della chiave è un vero guasto nel rinnovo, non un motivo per allentare il client.

Il controllo del nome è una direttiva separata

Soddisfare il controllo del ruolo dice che il peer è qualche server firmato dalla vostra autorità. Non dice quale, cosa che conta quando la stessa CA emette certificati per diversi gateway e uno di essi è compromesso o riutilizzato.

verify-x509-name confronta il soggetto del certificato con un valore che configurate, con modalità di corrispondenza per un soggetto esatto, un prefisso o un singolo campo. Usate il campo che identifica davvero il gateway, e aspettatevi di aggiornarlo deliberatamente quando il nome cambia.

Nessuna delle due direttive sostituisce una buona gestione delle chiavi. Se il file della chiave del client viene copiato in giro con il profilo, l'identità del peer è forte quanto la lista di distribuzione.

Ispezionate il certificato prima di modificare il profilo

Leggete il certificato del peer e il registro del client, in quest'ordine. Il certificato vi dice quali ruoli dichiara; il registro vi dice quale controllo lo ha rifiutato.

Questi comandi stampano le estensioni di utilizzo e le righe di verifica di una connessione dettagliata:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Se le estensioni mostrano il ruolo di server e il registro segnala ancora un errore di ruolo, il profilo probabilmente punta al file di certificato sbagliato e non a un certificato guasto. Se le estensioni mostrano solo l'autenticazione del client, smettete di guardare il client e correggete l'emissione. In ogni caso, ripristinate il controllo prima di definire sana la connessione, perché una stretta di mano riuscita dopo aver rimosso la verifica dimostra meno dell'errore che ha sostituito.