Un profilo OpenVPN ha tre blocchi di certificato: quale è segreto?

Aprite un file .ovpn per cambiare una riga e trovate tre blocchi di base64 che sembrano tutti credenziali. Uno è sicuro da pubblicare, uno è sensibile quanto una password e uno è una chiave pubblica che non significa nulla se qualcos'altro non è stato firmato con la sua coppia. Le persone incollano l'intero file in un thread di supporto perché i blocchi sembrano intercambiabili, ed è così che una chiave client finisce in un archivio pubblico. Distinguere cosa fa ogni blocco spiega gran parte della confusione attorno a questi profili e vi dice anche quali guasti tocca a voi correggere.

Un file, tre blocchi, compiti diversi

Un profilo tipico incorpora un blocco ca, un blocco cert e un blocco key tra i marcatori BEGIN e END, oppure rimanda agli stessi tre come file separati. Alcuni profili aggiungono un quarto blocco per una chiave tls-auth o tls-crypt, che è un segreto condiviso e non un certificato. Il client legge ogni blocco secondo la direttiva che lo nomina, quindi le etichette contano più dell'ordine in cui compaiono.

Trattate il profilo assemblato come sensibile finché non ci avete davvero guardato dentro. Un certificato pubblico e una chiave privata possono stare a poche righe di distanza nello stesso file, e uno screenshot che include l'intestazione può includerli entrambi. Oscurare a mano il base64 visibile non è affidabile, perché un blocco parziale lascia comunque trapelare i metadati del certificato che nominano la vostra distribuzione. Copiare le tre direttive senza i loro valori di solito basta per fare una domanda utile.

Le direttive attorno ai blocchi decidono come vengono usati. Cambiate ca e il client si fida di un'altra autorità; cambiate cert senza cambiare key e la stretta di mano fallisce con una discrepanza che non ha nulla a che vedere con la fiducia.

Il blocco CA è pubblico, la chiave CA mai

Un'autorità di certificazione firma certificati che legano una chiave pubblica a un'identità, e il suo certificato è l'ancora con cui un client decide se una catena è affidabile. Quel certificato è pubblico per progetto: spedirlo dentro ogni profilo è normale, ed è il motivo per cui una distribuzione autofirmata può funzionare senza un'autorità commerciale.

Ciò che non deve mai comparire in un profilo client è la chiave di firma privata dell'autorità. Il client non ne ha bisogno per validare nulla, e la sua presenza significa che chiunque possieda il profilo può coniare nuove identità per l'intera distribuzione.

Fidarsi di un'autorità è anche più stretto di quanto sembri. Un client che accetta qualsiasi certificato firmato dalla CA accetterà comunque un certificato emesso per un altro servizio sulla stessa CA. Le opzioni che fissano il ruolo o il nome atteso del server chiudono quella lacuna, e il riferimento delle opzioni TLS elenca le direttive di verifica che lo fanno.

I certificati server e client puntano in direzioni opposte

Il certificato del server è ciò che il client ispeziona per confermare di aver raggiunto l'endpoint giusto. Il vostro certificato client va nel senso opposto: il server lo usa per decidere che questo dispositivo o utente è uno che ha registrato. Stesso formato, direzione di fiducia opposta.

Un indirizzo non è un'identità. Raggiungere l'IP giusto non prova nulla su chi ha risposto, perciò il controllo del nome host o del nome del certificato appartiene ancora al profilo. Una password dell'account non sostituisce neppure silenziosamente un certificato client richiesto, perché i due sono controllati in fasi diverse e una distribuzione può esigere entrambi.

La chiave privata del client è la parte che deve restare privata. Se può essere stata esposta, cancellare il file dal vostro portatile non cambia nulla sul server, che continuerà ad accettare il certificato corrispondente finché l'operatore non lo revoca. Chiedere all'operatore di sostituire o revocare quell'identità è l'unica correzione che viaggia con voi.

Due richieste che sembrano identiche e non lo sono

Una chiave memorizzata in forma cifrata chiede una passphrase prima che il client possa usarla. Il servizio VPN può chiedere separatamente una password dell'account, e le due richieste possono comparire a pochi secondi di distanza con quasi le stesse parole. La passphrase protegge un file sul vostro disco; la password dimostra un account a un server. Confonderle manda le persone verso reimpostazioni che non possono in alcun modo aiutare.

Leggete la richiesta prima di reimpostare qualcosa. Una reimpostazione della password dell'account non fa nulla per una passphrase dimenticata, un certificato revocato o uno scaduto, e reimpostare la password quando il guasto è la validazione del certificato trasforma una correzione di due minuti in un caso di supporto. Se il reclamo cita date di validità, controllate prima l'orologio del dispositivo e poi la finestra propria del certificato indicato.

Quando il certificato è davvero scaduto, la sostituzione deve venire da chi lo ha emesso. Una chiave che appartiene a qualcun altro non è una via di rinnovo, e nemmeno prendere in prestito un profilo funzionante da un collega.

Cosa dimostra una stretta di mano pulita e cosa no

Raggiungere una stretta di mano TLS completata significa che la relazione di identità configurata ha tenuto: il certificato del server si è concatenato alla vostra CA e il vostro certificato è stato accettato. Non dice nulla sulla politica di registrazione dell'operatore, né se le vostre applicazioni funzioneranno una volta alzato il tunnel.

Rotte e DNS sono fasi successive della connessione, quindi un host intranet irraggiungibile dopo un accesso riuscito è un problema di connettività e non di certificato. Lavorate su quello strato invece di scambiare le credenziali, e tenete insieme l'origine del profilo, il suo materiale privato e i suoi controlli di identità quando lo consegnate a qualcuno.