OpenVPN verify-x509-name: subject, name y name-prefix

Lea primero el tipo de coincidencia y luego el texto: una verify-x509-name directiva puede parecer correcta y aun así aceptar un certificado en el que no quería confiar. Dos líneas con el mismo texto esperado pero tipos distintos son requisitos distintos. Lea primero el tipo y luego el texto. Trate la directiva como una condición más de la conexión, no como toda la comprobación.

Qué afirma realmente la opción

La directiva nombra una identidad que el certificado del otro extremo debe llevar. Cuando la comparación falla, OpenVPN aborta el handshake y no se levanta ningún túnel. Todo lo demás del perfil sigue aplicándose: el certificado debe encadenar con una CA de confianza y la comprobación de rol debe pasar, así que es una condición adicional y no un sustituto. Un perfil que satisface la expectativa del nombre y falla la comprobación de rol sigue roto, y el registro suele decirlo.

También difiere de la validación de nombre de host que hace un navegador. El navegador compara nombres con los nombres alternativos del subject según las reglas de su pila TLS, mientras que OpenVPN compara un solo campo del certificado con el tipo que eligió. Por eso pegar un nombre de host al estilo del navegador en la directiva puede producir una discrepancia incluso cuando el certificado cubre realmente el servicio.

subject: el nombre distinguido completo, carácter por carácter

Con subject, el valor predeterminado cuando no se escribe ningún tipo, el valor esperado debe reproducir todo el DN del subject del certificado. El orden de los campos, los separadores, los espacios y el escapado cuentan, porque la comparación se ejecuta sobre la cadena tal como está codificada. Si omite el tipo, ha elegido la más estricta de las tres comparaciones. No hay ningún paso de normalización que rescate una diferencia cosmética. Merece la pena saberlo antes de la primera renovación, no después.

Esa rigidez es frágil entre renovaciones. Una CA que reordena atributos, inserta un campo extra o cambia cómo escapa un valor produce una cadena nueva para la misma máquina, y una directiva que funcionó durante años empieza a fallar en la siguiente emisión. Guardar el DN aceptado en el registro de cambios convierte la siguiente renovación en una diferencia. Donde el operador publica un DN completo y garantiza su forma, subject es una opción razonable; en otros casos, un campo más estrecho es más fácil de mantener cierto.

name: un solo campo, normalmente el nombre común

El tipo name compara un solo campo del subject. Salvo que el perfil diga lo contrario, ese campo es el nombre común, y el valor esperado es exactamente ese campo, no el DN que lo rodea.

La trampa es que los certificados modernos no siempre ponen el nombre del servicio en el CN. Muchos lo llevan en un nombre alternativo del subject y dejan el CN vacío o genérico, así que un certificado que un navegador acepta puede fallar esta comparación. Inspeccione el certificado que realmente le emitieron antes de escribir la expectativa y confirme qué campo selecciona el perfil. Un CN vacío comparado con un nombre es una discrepancia, no un accidente de configuración.

name-prefix: amplio por diseño, así que delimítelo

Una expectativa de tipo name-prefix coincide con el inicio del campo seleccionado. Eso es cómodo para un esquema de nombres y peligroso para cualquier cosa compartida.

Con vpn.example como expectativa, tanto vpn.example.com como vpn.example.net pasarían, siempre que el resto de la cadena sea de confianza. La amplitud es la característica, y también es la parte que hay que justificar por escrito. Un prefijo es razonable cuando la CA y el esquema de nombres son suyos, y mucho más débil cuando una CA pública emite dentro del mismo patrón. Si el esquema necesita flexibilidad, limítelo en la CA en lugar de ampliar la comprobación del cliente.

Elija el tipo a partir del identificador y luego demuéstrelo

Trabaje hacia atrás desde la identidad que el operador pretende. Si publica un DN completo y lo mantiene estable, subject lo expresa. Si nombra el servicio por el nombre común, use name. Si posee un esquema de nombres y acepta todo su espacio, name-prefix lo dice explícitamente.

Las renovaciones son donde se pone a prueba la directiva. Compare la identidad aprobada con el certificado nuevo en lugar de con el archivo antiguo, porque una dirección nueva de punto final no implica una identidad nueva de certificado. No elimine la directiva solo porque una dirección conocida responde: la accesibilidad y el par previsto son hechos distintos, y la dirección solo demuestra que algo respondió. Anote el error exacto y los datos públicos del nombre en un informe depurado, porque una discrepancia de nombre puede mostrarse sin ningún material de clave privada.

Tras una corrección admitida, vuelva a conectarse con todas las comprobaciones previstas activadas y verifique el recurso que realmente necesita. El éxito significa que se aceptó el servidor previsto, no que se forzara el paso de algún certificado. El manual oficial OpenVPN 2.6 manual documenta los tres tipos y sus notas de confianza, y es la referencia que se cita cuando una interfaz de proveedor no coincide con el perfil.