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

Primer llegiu el tipus de coincidència i després el text: una verify-x509-name directiva pot semblar correcta i, tot i així, acceptar un certificat en què no volíeu confiar. Dues línies amb el mateix text esperat però tipus diferents són requisits diferents. Llegiu primer el tipus i després el text. Tracteu la directiva com una condició més de la connexió, no com la comprovació sencera.

Què afirma realment l’opció

La directiva anomena una identitat que el certificat de l’altra part ha de portar. Quan la comparació falla, OpenVPN avorta l’establiment de connexió i no s’aixeca cap túnel. Tota la resta del perfil continua aplicant-se: el certificat s’ha d’enllaçar amb una CA de confiança i la comprovació del rol ha de passar, així que és una condició addicional i no un substitut. Un perfil que compleix l’expectativa del nom i falla la comprovació del rol continua trencat, i el registre normalment ho diu.

També és diferent de la validació del nom d’amfitrió que fa un navegador. El navegador compara noms amb els noms alternatius del subject segons les regles de la seva pila TLS, mentre que OpenVPN compara un sol camp del certificat amb el tipus que heu triat. Per això enganxar un nom d’amfitrió a l’estil del navegador a la directiva pot produir una discrepància fins i tot quan el certificat cobreix realment el servei.

subject: el nom distingit complet, caràcter a caràcter

Amb subject, el valor per defecte quan no s’escriu cap tipus, el valor esperat ha de reproduir tot el DN del subject del certificat. L’ordre dels camps, els separadors, els espais i l’escapament compten, perquè la comparació es fa sobre la cadena tal com està codificada. Si ometeu el tipus, heu triat la més estricta de les tres comparacions. No hi ha cap pas de normalització que rescati una diferència cosmètica. Val la pena saber-ho abans de la primera renovació, no després.

Aquesta estricteza és fràgil entre renovacions. Una CA que reordena atributs, insereix un camp extra o canvia com escapa un valor produeix una cadena nova per a la mateixa màquina, i una directiva que va funcionar durant anys comença a fallar a la propera emissió. Conservar el DN acceptat al registre de canvis converteix la propera renovació en una diferència. On l’operador publica un DN complet i en garanteix la forma, subject és una opció raonable; en altres llocs, un camp més estret és més fàcil de mantenir cert.

name: un sol camp, normalment el nom comú

El tipus name compara un sol camp del subject. Tret que el perfil digui el contrari, aquest camp és el nom comú, i el valor esperat és exactament aquest camp, no el DN que l’envolta.

La trampa és que els certificats moderns no sempre posen el nom del servei al CN. Molts el porten en un nom alternatiu del subject i deixen el CN buit o genèric, així que un certificat que un navegador accepta encara pot fallar aquesta comparació. Inspeccioneu el certificat que realment us han emès abans d’escriure l’expectativa i confirmeu quin camp selecciona el perfil. Un CN buit comparat amb un nom és una discrepància, no un accident de configuració.

name-prefix: ampli per disseny, així que limiteu-ne l’abast

Una expectativa de tipus name-prefix coincideix amb l’inici del camp seleccionat. Això és convenient per a un esquema de noms i perillós per a qualsevol cosa compartida.

Amb vpn.example com a expectativa, tant vpn.example.com com vpn.example.net passarien, sempre que la resta de la cadena sigui de confiança. L’amplada és la característica, i també és la part que cal justificar per escrit. Un prefix és raonable quan la CA i l’esquema de noms són vostres, i molt més feble quan una CA pública emet dins del mateix patró. Si l’esquema necessita flexibilitat, limiteu-lo a la CA en lloc d’ampliar la comprovació del client.

Trieu el tipus a partir de l’identificador i després demostreu-ho

Treballeu enrere des de la identitat que l’operador pretén. Si publica un DN complet i el manté estable, subject ho expressa. Si anomena el servei pel nom comú, useu name. Si posseeix un esquema de noms i n’accepta tot l’espai, name-prefix ho diu explícitament.

Les renovacions són on es posa a prova la directiva. Compareu la identitat aprovada amb el certificat nou i no amb el fitxer vell, perquè una adreça nova de punt final no implica una identitat nova del certificat. No suprimiu la directiva només perquè una adreça coneguda respon: la connectivitat i l’altra part prevista són fets diferents, i l’adreça només demostra que alguna cosa ha respost. Anoteu l’error exacte i les dades públiques del nom en un informe depurat, perquè una discrepància de nom es pot mostrar sense cap material de clau privada.

Després d’una correcció suportada, torneu a connectar amb totes les comprovacions previstes activades i verifiqueu el recurs que realment necessiteu. Èxit significa que s’ha acceptat el servidor previst, no que s’hagi forçat el pas d’algun certificat. El manual oficial OpenVPN 2.6 manual documenta els tres tipus i les seves notes de confiança, i és la referència a citar quan una interfície de proveïdor no coincideix amb el perfil.