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

Lea primeiro o tipo de coincidencia e despois o texto: unha verify-x509-name directiva pode parecer correcta e aínda así aceptar un certificado no que non quería confiar. Dúas liñas co mesmo texto esperado pero tipos distintos son requisitos distintos. Lea primeiro o tipo e despois o texto. Trate a directiva como unha condición máis da conexión, non como toda a comprobación.

Que afirma realmente a opción

A directiva nomea unha identidade que o certificado da outra parte debe levar. Cando a comparación falla, OpenVPN aborta o handshake e non se ergue ningún túnel. Todo o demais do perfil segue aplicándose: o certificado debe encadear cunha CA de confianza e a comprobación de rol debe pasar, así que é unha condición adicional e non un substituto. Un perfil que satisface a expectativa do nome e falla a comprobación de rol segue roto, e o rexistro adoita dicilo.

Tamén difire da validación do nome de host que fai un navegador. O navegador compara nomes cos nomes alternativos do subject segundo as regras da súa pila TLS, mentres que OpenVPN compara un só campo do certificado co tipo que escolleu. Por iso pegar un nome de host ao estilo do navegador na directiva pode producir unha discrepancia aínda que o certificado cubra realmente o servizo.

subject: o nome distinguido completo, carácter por carácter

Con subject, o valor predeterminado cando non se escribe ningún tipo, o valor esperado debe reproducir todo o DN do subject do certificado. A orde dos campos, os separadores, os espazos e o escapado contan, porque a comparación se executa sobre a cadea tal como está codificada. Se omite o tipo, escolleu a máis estrita das tres comparacións. Non hai ningún paso de normalización que rescate unha diferenza cosmética. Paga a pena sabelo antes da primeira renovación, non despois.

Esa rixidez é fráxil entre renovacións. Unha CA que reordena atributos, insire un campo extra ou cambia como escapa un valor produce unha cadea nova para a mesma máquina, e unha directiva que funcionou durante anos comeza a fallar na seguinte emisión. Gardar o DN aceptado no rexistro de cambios converte a seguinte renovación nunha diferenza. Onde o operador publica un DN completo e garante a súa forma, subject é unha opción razoable; noutros casos, un campo máis estreito é máis fácil de manter certo.

name: un só campo, normalmente o nome común

O tipo name compara un só campo do subject. Salvo que o perfil diga o contrario, ese campo é o nome común, e o valor esperado é exactamente ese campo, non o DN que o rodea.

A trampa é que os certificados modernos non sempre poñen o nome do servizo no CN. Moitos lévao nun nome alternativo do subject e deixan o CN baleiro ou xenérico, así que un certificado que un navegador acepta pode fallar esta comparación. Inspeccione o certificado que realmente lle emitiron antes de escribir a expectativa e confirme que campo selecciona o perfil. Un CN baleiro comparado cun nome é unha discrepancia, non un accidente de configuración.

name-prefix: amplo por deseño, así que delimíteo

Unha expectativa de tipo name-prefix coincide co inicio do campo seleccionado. Iso é cómodo para un esquema de nomes e perigoso para calquera cousa compartida.

Con vpn.example como expectativa, tanto vpn.example.com como vpn.example.net pasarían, sempre que o resto da cadea sexa de confianza. A amplitude é a característica, e tamén é a parte que hai que xustificar por escrito. Un prefixo é razoable cando a CA e o esquema de nomes son seus, e moito máis feble cando unha CA pública emite dentro do mesmo patrón. Se o esquema necesita flexibilidade, limíteo na CA en lugar de ampliar a comprobación do cliente.

Escolla o tipo a partir do identificador e logo demóstreo

Traballar cara atrás desde a identidade que o operador pretende. Se publica un DN completo e o mantén estable, subject exprésao. Se nomea o servizo polo nome común, use name. Se posúe un esquema de nomes e acepta todo o seu espazo, name-prefix dío explicitamente.

As renovacións son onde se pon a proba a directiva. Compare a identidade aprobada co certificado novo en lugar de co ficheiro antigo, porque un novo enderezo de punto final non implica unha nova identidade de certificado. Non elimine a directiva só porque un enderezo coñecido responde: a accesibilidade e a parte prevista son feitos distintos, e o enderezo só demostra que algo respondeu. Anote o erro exacto e os datos públicos do nome nun informe depurado, porque unha discrepancia de nome pode mostrarse sen ningún material de clave privada.

Tras unha corrección admitida, volva conectar con todas as comprobacións previstas activadas e verifique o recurso que realmente necesita. O éxito significa que se aceptou o servidor previsto, non que se forzase o paso dalgún certificado. O manual oficial OpenVPN 2.6 manual documenta os tres tipos e as súas notas de confianza, e é a referencia que se cita cando unha interface de provedor non coincide co perfil.