remote-cert-tls server: o que ele verifica em um perfil OpenVPN

Três perguntas diferentes são respondidas por três partes diferentes de um perfil OpenVPN, e é ao fundi-las que as pessoas acabam desligando uma verificação que funcionava. O certificado do par está assinado pela autoridade em que confio? Esse certificado declara a função de servidor TLS? É o servidor exato que eu queria alcançar? remote-cert-tls server responde apenas à pergunta do meio, e faz isso lendo extensões dentro do certificado.

Três verificações fáceis de fundir na cabeça

A âncora de confiança vive na diretiva ca. A verificação da função pertence a remote-cert-tls. A verificação de identidade pertence a verify-x509-name, quando um perfil a usa, ou a qualquer verificação de nome que a implantação acrescente.

Elas cobrem falhas diferentes:

Um perfil pode ter as três e continuar fraco se a CA for compartilhada de forma ampla demais, o que é uma questão de gestão de chaves e não de diretiva.

O que a verificação da função lê

A diretiva é uma macro. Ela se expande em um requisito de uso de chave e um requisito de uso estendido de chave que nomeia a função de servidor web TLS, então o certificado do par precisa realmente declarar esse propósito. Um certificado emitido para autenticação de cliente não o satisfaz, mesmo quando a mesma autoridade assinou ambos.

Isso importa porque uma CA compartilhada é comum em implantações pequenas. Uma autoridade assina cada cliente e o servidor, e sem uma verificação de função qualquer um desses certificados poderia completar o lado servidor do handshake. A verificação não torna esse cenário impossível, mas remove a versão trivial dele.

A diretiva é assimétrica por design: clientes carregam remote-cert-tls server, e servidores carregam remote-cert-tls client. Troque-os e cada conexão falha com um erro de função que parece um certificado quebrado.

Perfis antigos às vezes usam ns-cert-type para o mesmo propósito. As páginas de manual atuais tratam essa opção como substituída, então um perfil que ainda depende dela merece migração em vez de depuração.

Por que desativar parece uma solução

Quando a verificação da função falha, a conexão para com um erro de verificação e o movimento óbvio é apagar a linha. A conexão então sobe, o que parece progresso e é na verdade o modo de falha que a diretiva existe para impedir. Agora você aceita um par cujo certificado nunca foi destinado a essa função.

Leia o erro em vez disso. Ele nomeia a verificação que falhou, e o certificado do outro lado pode ser inspecionado para ver quais extensões ele realmente carrega. Dois minutos de leitura decidem se a falha está na emissão ou na configuração. Adivinhar custa uma tarde e costuma terminar em um perfil enfraquecido. Um certificado de servidor renovado que perdeu o uso estendido de chave é uma falha real na renovação, não um motivo para relaxar o cliente.

A verificação do nome é uma diretiva separada

Satisfazer a verificação da função diz que o par é algum servidor assinado pela sua autoridade. Não diz qual, o que importa quando a mesma CA emite certificados para vários gateways e um deles está comprometido ou reaproveitado.

verify-x509-name compara o sujeito do certificado com um valor que você configura, com modos de correspondência para um sujeito exato, um prefixo ou um único campo. Use o campo que realmente identifica o gateway, e espere atualizá-lo deliberadamente quando o nome mudar.

Nenhuma das duas diretivas substitui um bom tratamento de chaves. Se o arquivo de chave do cliente for copiado por aí junto com o perfil, a identidade do par é tão forte quanto a lista de distribuição.

Inspecione o certificado antes de editar o perfil

Leia o certificado do par e o log do cliente, nessa ordem. O certificado informa quais funções ele declara; o log informa qual verificação o rejeitou.

Estes comandos imprimem as extensões de uso e as linhas de verificação de uma conexão detalhada:

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

Se as extensões mostrarem a função de servidor e o log ainda relatar uma falha de função, o perfil provavelmente aponta para o arquivo de certificado errado e não para um certificado ruim. Se as extensões mostrarem apenas autenticação de cliente, pare de olhar o cliente e corrija a emissão. De qualquer forma, restaure a verificação antes de chamar a conexão de saudável, porque um handshake bem-sucedido depois de remover a verificação prova menos do que o erro que ele substituiu.