OpenVPN sem certificado de cliente: política do servidor, não do perfil

Elimina as linhas de certificado e chave, entrega o perfil, e a ligação continua a falhar com um erro de certificado. O perfil nunca foi o que impunha esse requisito. É o servidor que decide se um certificado de cliente é obrigatório, e nenhuma edição do lado do cliente o negoceia. Portanto, a correção é uma alteração da política do servidor, feita deliberadamente, com tudo o que depende dela atualizado na mesma passagem.

O perfil não é a política

O Community OpenVPN 2.6 vem com certificados de cliente obrigatórios, porque verify-client-cert tem por predefinição o valor require. Defini-lo para none é o que para a exigência de um certificado e entrega a autenticação do cliente ao esquema de nome de utilizador e palavra-passe que o servidor já executa. Os guias mais antigos recorrem a client-cert-not-required, a grafia herdada da mesma ideia, por isso use a diretiva que a sua versão instalada documenta. Em qualquer caso, a alteração acontece no servidor, e nenhum perfil de cliente a pode executar.

O fragmento abaixo é toda a alteração do lado do servidor, e por si só não é uma configuração de autenticação funcional. verify-client-cert none remove o requisito de certificado, enquanto username-as-common-name torna o nome da conta a identidade que as chamadas de retorno posteriores e os ficheiros de cada cliente veem. Nenhuma das linhas verifica uma palavra-passe, por isso ainda tem de existir um verificador.

verify-client-cert none
username-as-common-name

Esse verificador é um plugin ou um script controlado por auth-user-pass-verify, e tem de estar no lugar antes de qualquer das linhas acima significar algo. Inverter a ordem dá-lhe uma janela em que o servidor não pede certificado e não verifica conta alguma.

O que ainda verifica o servidor

Dispensar o certificado de cliente não significa dispensar o TLS. O servidor mantém o seu certificado e a sua chave, e o cliente mantém a confiança na CA e as verificações de nome de anfitrião que o impedem de falar com um impostor. Remover remote-cert-tls server ou o pacote de CA porque o cliente já não tem certificado é uma leitura errada comum e grave, e a referência da 2.6 é explícita ao dizer que as duas direções são independentes. Uma prova o servidor ao cliente; a outra prova o cliente ao servidor.

Um perfil também pode transportar um bloco tls-auth ou tls-crypt. Trata-se de uma chave partilhada do canal de controlo com o seu próprio ciclo de distribuição e rotação, por isso um ficheiro sem linhas de certificado ou chave não é automaticamente seguro para publicar. Trate-o como um segredo até o ter lido.

Um ficheiro de certificado copiado de um perfil funcional não prova nada por si só; a posse significa deter a chave privada que lhe corresponde, o que uma implementação autenticada por certificado verifica. Um ficheiro que contém um certificado não é um ficheiro com que se possa autenticar.

O que o verificador tem de fazer

Removido o requisito de certificado, tudo assenta no verificador: um plugin, ou um script controlado por auth-user-pass-verify. Tem de rejeitar credenciais inválidas, rejeitar contas desativadas ou inelegíveis e falhar fechado quando não consegue alcançar o seu backend. username-as-common-name é frequentemente ativado ao lado, e altera a identidade que as chamadas de retorno posteriores e os ficheiros de configuração de cada cliente veem. Não verifica uma palavra-passe e não torna elegível uma conta que não o é. São tarefas separadas, e misturá-las é como uma migração passa o teste do caminho feliz e falha no seu primeiro incidente real.

Teste os casos negativos com tanto cuidado como o positivo. Um perfil que mostra um pedido de palavra-passe só prova que o cliente consegue desenhar um pedido, enquanto um servidor que aceita a palavra-passe errada prova algo muito pior. Acrescente uma conta desativada e uma credencial expirada ao conjunto de testes, não apenas uma palavra-passe má.

Altere a política, o perfil e o mapeamento em conjunto

Coordene três coisas: a diretiva do servidor, o perfil do cliente e o mapeamento de identidade por cliente. Altere-os em separado e os clientes falham antes da verificação, ou ligam-se com um nome que o administrador não esperava, o que é pior porque parece um sucesso. Uma ligação que tem sucesso com a identidade errada é mais difícil de notar do que uma que falha.

Mantenha duas contas de teste para este caminho, uma válida e uma conhecida como má, e use ambas após qualquer alteração ao verificador. A conta válida prova o caminho feliz e o mapeamento de identidade; a má prova que a rejeição continua a funcionar. Nenhum dos testes lhe diz nada sobre regras de elegibilidade, por isso acrescente uma conta que deveria ser recusada por razões de política se a implementação as tiver. Execute os três após cada alteração, porque um verificador que começa a aceitar tudo parece exatamente um início de sessão funcional.

Registe que métodos de autenticação o servidor aceita realmente, não os que o perfil sugere. Esse registo responde à pergunta que as pessoas continuam a fazer, que é quem se pode ligar a este serviço. Também sobrevive ao administrador seguinte, que de outra forma o redescobriria a partir de uma captura de pacotes.