OpenVPN username-as-common-name: por que a túa comprobación do CN está baleira
Un script client-connect que compara common_name con username pode comparar un nome consigo mesmo. Vincula o certificado á conta antes de que se execute a substitución.
Engades un script client-connect que rexeita calquera conexión na que common_name difire de username, e parece unha vinculación entre un certificado e unha conta. Nun servidor que executa username-as-common-name, esa comparación xa perdeu o seu significado cando o script se executa. Ambos os valores son a mesma cadea, así que a proba pasa para un certificado emitido a outra persoa completamente distinta.
A comprobación non está mal porque o script estea mal escrito. Está mal porque o valor que le foi substituído antes na mesma conexión.
O que a comparación parece demostrar
A autenticación por certificado e a autenticación por contrasinal son probas separadas, e un servidor pode esixir ambas sen esixir que pertenzan á mesma persoa. A fenda é real: un certificado de dispositivo válido máis calquera conta válida é unha afirmación distinta da dese certificado de dispositivo máis unha conta concreta. Un script que compara common_name con username lese como o elo perdido entre os dous. Seríao, se common_name aínda significase o que dicía o certificado.
Se o fai depende dunha opción do servidor, e esa opción adoita activarse por un motivo non relacionado, como facer que os ficheiros de configuración por usuario sexan máis fáciles de nomear.
O que username-as-common-name fai co nome
Con username-as-common-name activado, OpenVPN substitúe o nome común do certificado polo nome de usuario autenticado unha vez verificado o usuario e o contrasinal. O gancho de verificación que se executa durante esa comprobación aínda recibe o nome común do certificado, porque a substitución aínda non ocorreu. Todo o posterior, client-connect incluído, ve o nome de usuario. Así, a devolución de chamada posterior recibe unha identidade dúas veces e non pode comparala co certificado presentado.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Segue unha conexión ilustrativa: un certificado emitido para bob-device, un inicio de sesión correcto no directorio como alice e a opción activada. A fase de verificación aínda pode ver dúas cadeas diferentes. A fase de conexión ve alice e alice.
Ese exemplo mostra por que a comparación está baleira. Non mostra que a conexión fose aceptada doutro xeito, xa que a validación do certificado e a verificación do contrasinal aínda se executan por separado.
Pon a vinculación onde ambas as identidades aínda existen
A regra debe aplicarse nunha fase que vexa a identidade do certificado e a conta ao mesmo tempo, o que na práctica significa o gancho de verificación de usuario e contrasinal ou un complemento cargado alí. Un complemento compatible que xa realiza a verificación de contrasinal adoita ser o lugar correcto para engadir unha regra de emparellamento, porque substituílo por unha comparación de nomes eliminaría a comprobación do contrasinal por completo.
Define a asignación antes de escribir código, xa que a igualdade raramente é a política real. Un certificado adoita identificar un dispositivo mentres que o inicio de sesión identifica unha persoa, e un dispositivo pode servir lexitimamente a varias persoas. Garda a relación nunha forma cuxa emisión controles, e decide que ocorre ao renomear, ao reemitir e con nomes cualificados por dominio. Converter a minúsculas ou eliminar un prefixo de dominio sen entender o directorio pode fusionar dúas contas que debían permanecer distintas.
Lembra que a opción tamén cambia que configuración por cliente se aplica, porque client-config-dir está indexado polo nome común.
Proba o emparellamento con dúas credenciais válidas
Comeza co par que permite a túa política e confirma que conecta. Despois presenta o mesmo certificado válido cunha conta diferente pero igualmente válida: ese intento debe fallar, e debe fallar pola regra de emparellamento e non por un contrasinal mal escrito. Un contrasinal incorrecto demostra que a comprobación do contrasinal funciona e non di nada sobre a regra entre certificado e conta.
Comproba tamén os camiños sen certificado e con certificado non válido, e confirma que identidade usa o servidor para a configuración por cliente. Se o único xeito de que a comparación funcione é desactivar username-as-common-name, calcula primeiro o custo desa cambio, porque devolve a busca de configuración de cada cliente ao nome do certificado.