remote-cert-tls server: qué comprueba en un perfil de OpenVPN

Tres preguntas distintas reciben respuesta de tres partes distintas de un perfil de OpenVPN, y fusionarlas es como la gente acaba desactivando una comprobación que funcionaba. ¿El certificado del par está firmado por la autoridad en la que confío? ¿Ese certificado declara el rol de servidor TLS? ¿Es el servidor concreto al que quería llegar? remote-cert-tls server solo responde a la pregunta intermedia, y lo hace leyendo extensiones dentro del certificado.

Tres comprobaciones fáciles de fusionar en la cabeza

El ancla de confianza vive en la directiva ca. La comprobación del rol pertenece a remote-cert-tls. La comprobación de identidad pertenece a verify-x509-name, cuando un perfil la usa, o a cualquier comprobación de nombre que añada el despliegue.

Cubren fallos distintos:

Un perfil puede tener las tres y seguir siendo débil si la CA se comparte demasiado ampliamente, lo que es una cuestión de gestión de claves y no de directivas.

Qué lee la comprobación del rol

La directiva es una macro. Se expande en un requisito de uso de clave y un requisito de uso de clave extendido que nombra el rol de servidor web TLS, así que el certificado del par debe declarar realmente ese propósito. Un certificado emitido para autenticación de cliente no lo satisface, incluso cuando la misma autoridad firmó ambos.

Eso importa porque una CA compartida es habitual en despliegues pequeños. Una autoridad firma todos los clientes y el servidor, y sin una comprobación de rol cualquiera de esos certificados podría completar el lado servidor del apretón de manos. La comprobación no hace imposible ese escenario, pero elimina su versión trivial.

La directiva es asimétrica por diseño: los clientes llevan remote-cert-tls server, y los servidores llevan remote-cert-tls client. Cámbielos y cada conexión falla con un error de rol que parece un certificado roto.

Los perfiles antiguos a veces usan ns-cert-type para el mismo propósito. Las páginas de manual actuales tratan esa opción como superada, así que un perfil que aún depende de ella merece migrarse en lugar de depurarse.

Por qué desactivarla parece una solución

Cuando la comprobación del rol falla, la conexión se detiene con un error de verificación y el movimiento obvio es borrar la línea. Entonces la conexión sube, lo que parece un progreso y en realidad es el modo de fallo que la directiva existe para evitar. Ahora acepta un par cuyo certificado nunca estuvo pensado para ese rol.

Lea el error en su lugar. Nombra la comprobación que falló, y el certificado del otro lado puede inspeccionarse para ver qué extensiones lleva realmente. Dos minutos de lectura deciden si el fallo es de emisión o de configuración. Adivinar cuesta una tarde y suele acabar con un perfil debilitado. Un certificado de servidor renovado que perdió su uso de clave extendido es un fallo real en la renovación, no una razón para relajar al cliente.

La comprobación del nombre es una directiva aparte

Satisfacer la comprobación del rol dice que el par es algún servidor firmado por su autoridad. No dice nada sobre cuál, lo que importa cuando la misma CA emite certificados para varias puertas de enlace y una de ellas está comprometida o reutilizada.

verify-x509-name compara el sujeto del certificado con un valor que usted configura, con modos de coincidencia para un sujeto exacto, un prefijo o un solo campo. Use el campo que realmente identifica la puerta de enlace, y espere actualizarlo deliberadamente cuando cambie el nombre.

Ninguna de las dos directivas sustituye un buen manejo de claves. Si el archivo de clave del cliente se copia de un lado a otro con el perfil, la identidad del par es tan fuerte como la lista de distribución.

Inspeccione el certificado antes de editar el perfil

Lea el certificado del par y el registro del cliente, en ese orden. El certificado le dice qué roles declara; el registro le dice qué comprobación lo rechazó.

Estos comandos imprimen las extensiones de uso y las líneas de verificación de una conexión detallada:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Si las extensiones muestran el rol de servidor y el registro sigue informando un fallo de rol, el perfil probablemente apunta a un archivo de certificado equivocado y no a un certificado defectuoso. Si las extensiones solo muestran autenticación de cliente, deje de mirar al cliente y arregle la emisión. En cualquier caso, restaure la comprobación antes de dar la conexión por sana, porque un apretón de manos exitoso tras eliminar la verificación demuestra menos que el error que sustituyó.