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

Leia primeiro o tipo de correspondência e depois o texto: uma verify-x509-name diretiva pode parecer correta e ainda assim aceitar um certificado em que não pretendia confiar. Duas linhas com o mesmo texto esperado mas tipos diferentes são requisitos diferentes. Leia primeiro o tipo e depois o texto. Trate a diretiva como mais uma condição na ligação, não como toda a verificação.

O que a opção realmente afirma

A diretiva nomeia uma identidade que o certificado da outra parte deve transportar. Quando a comparação falha, OpenVPN aborta o handshake e nenhum túnel sobe. Tudo o resto no perfil continua a aplicar-se: o certificado tem de encadear numa AC de confiança e a verificação de função tem de passar, pelo que é uma condição adicional e não um substituto. Um perfil que satisfaz a expectativa do nome e falha a verificação de função continua avariado, e o registo costuma dizê-lo.

Também difere da validação do nome de anfitrião que um navegador faz. O navegador compara nomes com os nomes alternativos do subject segundo as regras da sua pilha TLS, enquanto o OpenVPN compara um único campo do certificado com o tipo que escolheu. É por isso que colar um nome de anfitrião ao estilo do navegador na diretiva pode produzir uma discrepância mesmo quando o certificado cobre realmente o serviço.

subject: o nome distinto completo, caractere a caractere

Com subject, o valor padrão quando nenhum tipo é escrito, o valor esperado tem de reproduzir todo o DN do subject do certificado. A ordem dos campos, os separadores, os espaços e o escaping contam todos, porque a comparação corre sobre a cadeia tal como está codificada. Se omitir o tipo, escolheu a mais estrita das três comparações. Não há qualquer passo de normalização que salve uma diferença cosmética. Vale a pena saber isto antes da primeira renovação, não depois.

Essa rigidez é frágil entre renovações. Uma AC que reordena atributos, insere um campo extra ou muda a forma como faz o escaping de um valor produz uma cadeia nova para a mesma máquina, e uma diretiva que funcionou durante anos começa a falhar na emissão seguinte. Guardar o DN aceite no registo de alterações transforma a renovação seguinte numa diferença. Onde o operador publica um DN completo e garante a forma, subject é uma escolha razoável; noutros casos, um campo mais estreito é mais fácil de manter verdadeiro.

name: um único campo, normalmente o nome comum

O tipo name compara um único campo do subject. A menos que o perfil diga o contrário, esse campo é o nome comum, e o valor esperado é exatamente esse campo, não o DN que o rodeia.

A armadilha é que os certificados modernos não põem sempre o nome do serviço no CN. Muitos transportam-no num nome alternativo do subject e deixam o CN vazio ou genérico, pelo que um certificado que um navegador aceita pode ainda falhar esta comparação. Inspecione o certificado que lhe foi realmente emitido antes de escrever a expectativa e confirme qual campo o perfil seleciona. Um CN vazio comparado com um nome é uma discrepância, não um acidente de configuração.

name-prefix: amplo por desenho, portanto delimite-o

Uma expectativa do tipo name-prefix corresponde ao início do campo selecionado. Isso é prático para um esquema de nomes e perigoso para tudo o que é partilhado.

Com vpn.example como expectativa, tanto vpn.example.com como vpn.example.net passariam, desde que o resto da cadeia seja de confiança. A amplitude é a funcionalidade, e é também a parte que tem de ser justificada por escrito. Um prefixo é razoável quando a AC e o esquema de nomes são seus, e muito mais fraco quando uma AC pública emite no mesmo padrão. Se o esquema precisa de flexibilidade, limite-o na AC em vez de alargar a verificação do cliente.

Escolha o tipo a partir do identificador e depois prove-o

Trabalhe de trás para a frente a partir da identidade que o operador pretende. Se publica um DN completo e o mantém estável, subject isso exprime. Se nomeia o serviço pelo nome comum, use name. Se possui um esquema de nomes e aceita todo o seu espaço, name-prefix di-lo explicitamente.

As renovações são onde a diretiva é posta à prova. Compare a identidade aprovada com o certificado novo em vez de com o ficheiro antigo, porque um novo endereço de ponto final não implica uma nova identidade de certificado. Não elimine a diretiva só porque um endereço familiar responde: a acessibilidade e a contraparte pretendida são factos diferentes, e o endereço só prova que algo respondeu. Registe o erro exato e os detalhes públicos do nome num relatório limpo, porque uma discrepância de nome pode ser mostrada sem qualquer material de chave privada.

Após uma correção suportada, volte a ligar com todas as verificações pretendidas ativas e verifique o recurso de que realmente precisa. O sucesso significa que o servidor pretendido foi aceite, não que algum certificado tenha sido forçado a passar. O manual oficial OpenVPN 2.6 manual documenta os três tipos e as suas notas de confiança, e é a referência a citar quando uma interface de fornecedor discorda do perfil.