OpenVPN username-as-common-name: perché il tuo controllo CN è vuoto

Aggiungi uno script client-connect che rifiuta ogni connessione in cui common_name differisce da username, e sembra un vincolo tra un certificato e un account. Su un server che esegue username-as-common-name, quel confronto ha già perso il suo significato quando lo script viene eseguito. Entrambi i valori sono la stessa stringa, quindi il test passa per un certificato rilasciato a qualcun altro del tutto.

Il controllo non è sbagliato perché lo script è scritto male. È sbagliato perché il valore che legge è stato sostituito prima nella stessa connessione.

Cosa sembra dimostrare il confronto

L'autenticazione tramite certificato e l'autenticazione tramite password sono prove separate, e un server può richiedere entrambe senza richiedere che appartengano alla stessa persona. Il divario è reale: un certificato di dispositivo valido più un account qualsiasi valido è un'affermazione diversa da quel certificato di dispositivo più un unico account con nome. Uno script che confronta common_name con username si legge come l'anello mancante tra i due. Lo sarebbe, se common_name significasse ancora ciò che diceva il certificato.

Se lo faccia dipende da un'opzione del server, e quell'opzione di solito viene attivata per un motivo non correlato, come rendere più facile dare un nome ai file di configurazione per utente.

Cosa fa username-as-common-name al nome

Con username-as-common-name abilitato, OpenVPN sostituisce il nome comune del certificato con il nome utente autenticato una volta verificati nome utente e password. L'hook di verifica che viene eseguito durante quel controllo riceve ancora il nome comune del certificato, perché la sostituzione non è ancora avvenuta. Tutto ciò che segue, client-connect incluso, vede il nome utente. Così la callback successiva riceve una sola identità due volte e non può confrontarla con il certificato presentato.

Segui una connessione illustrativa: un certificato rilasciato per bob-device, un accesso alla directory riuscito come alice e l'opzione abilitata. La fase di verifica può ancora vedere due stringhe diverse. La fase di connessione vede alice e alice.

Quell'esempio mostra perché il confronto è vuoto. Non mostra che la connessione sarebbe altrimenti accettata, poiché la validazione del certificato e la verifica della password vengono comunque eseguite da sole.

Metti il vincolo dove entrambe le identità esistono ancora

La regola deve essere applicata in una fase che vede insieme l'identità del certificato e l'account, il che in pratica significa l'hook di verifica di nome utente e password o un plugin caricato lì. Un plugin supportato che esegue già la verifica della password è di solito il posto giusto per aggiungere una regola di abbinamento, perché sostituirlo con un confronto di nomi eliminerebbe del tutto il controllo della password.

Definisci la mappatura prima di scrivere codice, poiché l'uguaglianza raramente è la vera policy. Un certificato spesso identifica un dispositivo mentre l'accesso identifica una persona, e un dispositivo può legittimamente servire più persone. Conserva la relazione in una forma di cui controlli l'emissione, e decidi cosa accade alla rinomina, alla riemissione e con nomi qualificati dal dominio. Convertire in minuscolo o rimuovere un prefisso di dominio senza capire la directory può unire due account che dovevano restare distinti.

Ricorda che l'opzione cambia anche quale configurazione per client si applica, perché client-config-dir è indicizzato sul nome comune.

Metti alla prova l'abbinamento con due credenziali valide

Inizia con la coppia che la tua policy consente e conferma che si connetta. Poi presenta lo stesso certificato valido con un account diverso ma comunque valido: quel tentativo deve fallire, e deve fallire per la regola di abbinamento e non per una password digitata male. Una password sbagliata dimostra che il controllo della password funziona e non dice nulla sulla regola tra certificato e account.

Controlla anche i percorsi con certificato mancante e certificato non valido, e conferma quale identità il server usa per le impostazioni per client. Se l'unico modo per far funzionare il confronto è disattivare username-as-common-name, valuta prima il costo di quel cambiamento, perché riporta la ricerca della configurazione di ogni client al nome del certificato.