OpenVPN senza certificato client: politica del server, non del profilo

Elimini le righe di certificato e chiave, consegni il profilo, e la connessione continua a fallire con un errore di certificato. Il profilo non è mai stato ciò che imponeva quel requisito. È il server a decidere se un certificato client è obbligatorio, e nessuna modifica lato client lo negozia via. Quindi la correzione è un cambiamento di politica lato server, fatto deliberatamente, con tutto ciò che ne dipende aggiornato nello stesso passaggio.

Il profilo non è la politica

Community OpenVPN 2.6 arriva con certificati client obbligatori, perché verify-client-cert per impostazione predefinita vale require. Impostarlo su none è ciò che ferma la richiesta di un certificato e affida l'autenticazione del client alla disposizione di nome utente e password che il server già esegue. Le guide più vecchie ricorrono a client-cert-not-required, la grafia legacy della stessa idea, quindi usa la direttiva che la tua versione installata documenta. In ogni caso il cambiamento avviene sul server, e nessun profilo client può eseguirlo.

Il frammento qui sotto è l'intera modifica lato server, e da solo non è una configurazione di autenticazione funzionante. verify-client-cert none rimuove il requisito del certificato, mentre username-as-common-name rende il nome dell'account l'identità che i callback successivi e i file per client vedono. Nessuna delle due righe controlla una password, quindi un verificatore deve comunque esistere.

verify-client-cert none
username-as-common-name

Quel verificatore è un plugin o uno script guidato da auth-user-pass-verify, e deve essere in posizione prima che una delle righe qui sopra significhi qualcosa. Invertire l'ordine ti dà una finestra in cui il server non chiede alcun certificato e non controlla alcun account.

Cosa verifica ancora il server

Abbandonare il certificato client non significa abbandonare TLS. Il server conserva il proprio certificato e la propria chiave, e il client conserva la fiducia nella CA e i controlli del nome host che gli impediscono di parlare con un impostore. Rimuovere remote-cert-tls server o il pacchetto di CA perché il client non ha più un certificato è una lettura errata comune e grave, e il riferimento 2.6 è esplicito sul fatto che le due direzioni sono indipendenti. Una dimostra il server al client; l'altra dimostra il client al server.

Un profilo può anche portare un blocco tls-auth o tls-crypt. È una chiave condivisa del canale di controllo con il proprio ciclo di distribuzione e rotazione, quindi un file senza righe di certificato o chiave non è automaticamente sicuro da pubblicare. Trattalo come un segreto finché non l'hai letto.

Un file di certificato copiato da un profilo funzionante non dimostra nulla da solo; il possesso significa tenere la chiave privata che vi corrisponde, cosa che un deployment autenticato tramite certificato controlla. Un file che contiene un certificato non è un file con cui ci si può autenticare.

Cosa deve fare il verificatore

Rimosso il requisito del certificato, tutto poggia sul verificatore: un plugin, o uno script guidato da auth-user-pass-verify. Deve rifiutare credenziali non valide, rifiutare account disabilitati o non idonei e fallire chiuso quando non riesce a raggiungere il proprio backend. username-as-common-name è spesso abilitato accanto, e cambia l'identità che i callback successivi e i file di configurazione per client vedono. Non verifica una password e non rende idoneo un account che non lo è. Sono compiti separati, e confonderli è il modo in cui una migrazione supera il test del percorso felice e fallisce al suo primo incidente reale.

Prova i casi negativi con la stessa cura di quello positivo. Un profilo che mostra una richiesta di password dimostra solo che il client sa disegnare una richiesta, mentre un server che accetta la password sbagliata dimostra qualcosa di molto peggio. Aggiungi un account disabilitato e una credenziale scaduta al set di test, non solo una password errata.

Cambia insieme politica, profilo e mappatura

Coordina tre cose: la direttiva del server, il profilo del client e la mappatura dell'identità per client. Cambiale separatamente e i client falliscono prima della verifica, o si connettono con un nome che l'amministratore non si aspettava, il che è peggio perché sembra un successo. Una connessione che riesce con l'identità sbagliata è più difficile da notare di una che fallisce.

Tieni due account di test per questo percorso, uno valido e uno notoriamente cattivo, e usa entrambi dopo ogni modifica al verificatore. L'account valido dimostra il percorso felice e la mappatura dell'identità; quello cattivo dimostra che il rifiuto funziona ancora. Nessuno dei due test ti dice nulla sulle regole di idoneità, quindi aggiungi un account che dovrebbe essere rifiutato per motivi di politica se il deployment ne ha. Esegui tutti e tre dopo ogni modifica, perché un verificatore che inizia ad accettare tutto sembra esattamente un login funzionante.

Registra quali metodi di autenticazione il server accetta davvero, non quali suggerisce il profilo. Quel registro risponde alla domanda che le persone continuano a fare, cioè chi può connettersi a questo servizio. Sopravvive anche all'amministratore successivo, che altrimenti lo riscoprirebbe da una cattura di pacchetti.