OpenVPN username-as-common-name: por qué tu comprobación de CN está vacía

Añades un script client-connect que rechaza cualquier conexión en la que common_name difiere de username, y parece un vínculo entre un certificado y una cuenta. En un servidor que ejecuta username-as-common-name, esa comparación ya ha perdido su significado cuando el script se ejecuta. Ambos valores son la misma cadena, así que la prueba pasa para un certificado emitido a una persona completamente distinta.

La comprobación no está mal porque el script esté mal escrito. Está mal porque el valor que lee se sustituyó antes en la misma conexión.

Qué parece demostrar la comparación

La autenticación por certificado y la autenticación por contraseña son pruebas separadas, y un servidor puede exigir ambas sin exigir que pertenezcan a la misma persona. La diferencia es real: un certificado de dispositivo válido más cualquier cuenta válida es una afirmación distinta de ese certificado más una cuenta concreta. Un script que compara common_name con username se lee como el eslabón que falta entre ambos. Y lo sería, si common_name todavía significara lo que decía el certificado.

Que sea así depende de una opción del servidor, y esa opción suele activarse por un motivo no relacionado, como facilitar el nombre de los archivos de configuración por usuario.

Qué hace username-as-common-name con el nombre

Con username-as-common-name activado, OpenVPN sustituye el nombre común del certificado por el nombre de usuario autenticado una vez verificados el nombre de usuario y la contraseña. El gancho de verificación que se ejecuta durante esa comprobación sigue recibiendo el nombre común del certificado, porque la sustitución aún no ha ocurrido. Todo lo posterior, incluido client-connect, ve el nombre de usuario. Así que la llamada posterior recibe una identidad dos veces y no puede compararla con el certificado presentado.

Sigue una conexión ilustrativa: un certificado emitido para bob-device, un inicio de sesión correcto en el directorio como alice y la opción activada. La fase de verificación todavía puede ver dos cadenas distintas. La fase de conexión ve alice y alice.

Ese ejemplo muestra por qué la comparación está vacía. No muestra que la conexión se aceptaría de otro modo, ya que la validación del certificado y la verificación de la contraseña siguen ejecutándose por su cuenta.

Pon el vínculo donde ambas identidades todavía existen

La regla debe aplicarse en una fase que vea la identidad del certificado y la cuenta al mismo tiempo, lo que en la práctica significa el gancho de verificación de nombre de usuario y contraseña o un complemento cargado allí. Un complemento compatible que ya realiza la verificación de contraseña suele ser el lugar correcto para añadir una regla de emparejamiento, porque sustituirlo por una comparación de nombres eliminaría por completo la comprobación de la contraseña.

Define el mapeo antes de escribir código, porque la igualdad rara vez es la política real. Un certificado a menudo identifica un dispositivo mientras que el inicio de sesión identifica a una persona, y un dispositivo puede servir legítimamente a varias personas. Guarda la relación en una forma cuya emisión controles, y decide qué ocurre al renombrar, al reemitir y con nombres cualificados por dominio. Pasar a minúsculas o quitar un prefijo de dominio sin entender el directorio puede fusionar dos cuentas que debían permanecer separadas.

Recuerda que la opción también cambia qué configuración por cliente se aplica, porque client-config-dir se indexa por el nombre común.

Prueba el emparejamiento con dos credenciales válidas

Empieza por el par que permite tu política y confirma que se conecta. Luego presenta el mismo certificado válido con una cuenta distinta pero válida por lo demás: ese intento debe fallar, y debe fallar por la regla de emparejamiento, no por una contraseña mal escrita. Una contraseña incorrecta demuestra que la comprobación de la contraseña funciona y no dice nada sobre la regla entre certificado y cuenta.

Comprueba también las rutas de certificado ausente y certificado no válido, y confirma qué identidad usa el servidor para la configuración por cliente. Si la única forma de hacer funcionar la comparación es desactivar username-as-common-name, calcula primero el coste de ese cambio, porque devuelve la búsqueda de configuración de cada cliente al nombre del certificado.