OpenVPN sin certificado de cliente: política del servidor, no del perfil

Usted borra las líneas de certificado y clave, entrega el perfil, y la conexión sigue fallando con un error de certificado. El perfil nunca fue lo que imponía ese requisito. El servidor decide si un certificado de cliente es obligatorio, y ninguna edición en el lado del cliente lo negocia. Así que la solución es un cambio de política del servidor, hecho a propósito, con todo lo que depende de él actualizado en la misma pasada.

El perfil no es la política

Community OpenVPN 2.6 se distribuye con certificados de cliente obligatorios, porque verify-client-cert toma por defecto el valor require. Ponerlo en none es lo que detiene la exigencia de un certificado y entrega la autenticación del cliente al arreglo de usuario y contraseña que el servidor ya ejecuta. Las guías antiguas recurren a client-cert-not-required, la grafía heredada de la misma idea, así que use la directiva que documente su versión instalada. En cualquier caso, el cambio ocurre en el servidor, y ningún perfil de cliente puede realizarlo.

El fragmento siguiente es todo el cambio del lado del servidor, y por sí solo no es una configuración de autenticación funcional. verify-client-cert none elimina el requisito de certificado, mientras que username-as-common-name hace que el nombre de la cuenta sea la identidad que ven las devoluciones de llamada posteriores y los archivos de cada cliente. Ninguna de las dos líneas comprueba una contraseña, así que todavía debe existir un verificador.

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

Ese verificador es un complemento o un script impulsado por auth-user-pass-verify, y debe estar en su sitio antes de que cualquiera de las líneas anteriores signifique algo. Invertir el orden le da una ventana en la que el servidor no pide certificado y no comprueba cuenta alguna.

Qué sigue verificando al servidor

Descartar el certificado de cliente no significa descartar TLS. El servidor conserva su certificado y su clave, y el cliente conserva la confianza en la CA y las comprobaciones de nombre de host que le impiden hablar con un impostor. Quitar remote-cert-tls server o el paquete de CA porque el cliente ya no tiene certificado es una mala interpretación común y grave, y la referencia de la 2.6 es explícita en que las dos direcciones son independientes. Una demuestra el servidor al cliente; la otra demuestra el cliente al servidor.

Un perfil también puede llevar un bloque tls-auth o tls-crypt. Es una clave compartida del canal de control con su propio ciclo de distribución y rotación, así que un archivo sin líneas de certificado ni clave no es automáticamente seguro para publicar. Trátelo como un secreto hasta que lo haya leído.

Un archivo de certificado copiado de un perfil funcional no demuestra nada por sí solo; la posesión significa tener la clave privada que le corresponde, cosa que comprueba un despliegue autenticado por certificado. Un archivo que contiene un certificado no es un archivo con el que se pueda autenticar.

Qué debe hacer el verificador

Con el requisito de certificado eliminado, todo descansa en el verificador: un complemento o un script impulsado por auth-user-pass-verify. Debe rechazar credenciales no válidas, rechazar cuentas desactivadas o no elegibles y fallar cerrado cuando no puede alcanzar su backend. username-as-common-name suele activarse al mismo tiempo, y cambia la identidad que ven las devoluciones de llamada posteriores y los archivos de configuración de cada cliente. No verifica una contraseña ni hace elegible una cuenta que no lo es. Son trabajos separados, y mezclarlos es como una migración supera su prueba de camino feliz y falla en su primer incidente real.

Pruebe los casos negativos con tanto cuidado como el positivo. Un perfil que muestra una petición de contraseña solo demuestra que el cliente puede dibujar una petición, mientras que un servidor que acepta la contraseña equivocada demuestra algo mucho peor. Añada una cuenta desactivada y una credencial caducada al conjunto de pruebas, no solo una contraseña incorrecta.

Cambie la política, el perfil y el mapeo a la vez

Coordine tres cosas: la directiva del servidor, el perfil del cliente y el mapeo de identidad por cliente. Cámbielos por separado y los clientes fallan antes de la verificación, o se conectan con un nombre que el administrador no esperaba, lo cual es peor porque parece un éxito. Una conexión que tiene éxito con la identidad equivocada es más difícil de notar que una que falla.

Mantenga dos cuentas de prueba para esta ruta, una válida y otra conocida como mala, y use ambas después de cualquier cambio en el verificador. La cuenta válida demuestra el camino feliz y el mapeo de identidad; la mala demuestra que el rechazo sigue funcionando. Ninguna de las pruebas le dice nada sobre las reglas de elegibilidad, así que añada una cuenta que deba rechazarse por motivos de política si el despliegue las tiene. Ejecute las tres después de cada cambio, porque un verificador que empieza a aceptarlo todo parece exactamente un inicio de sesión funcional.

Registre qué métodos de autenticación acepta realmente el servidor, no los que sugiere el perfil. Ese registro responde a la pregunta que la gente sigue haciendo, que es quién puede conectarse a este servicio. También sobrevive al siguiente administrador, que de lo contrario lo redescubriría a partir de una captura de paquetes.