Uma palavra-passe VPN correta não substitui um certificado em falta

As credenciais estão corretas, o perfil é importado sem problemas e a ligação continua a falhar antes de a autenticação terminar. No Windows, a mensagem pode ser o erro 798, sobre um certificado que não foi encontrado para o método EAP. No OpenVPN, o registo do cliente mostra um handshake TLS que nunca satisfaz o servidor. Ambos descrevem o mesmo objeto em falta: um certificado de cliente que o cliente devia apresentar.

Uma palavra-passe prova o conhecimento de um segredo; um certificado prova a posse de uma chave, e um não substitui o outro.

A palavra-passe nunca foi o problema

O erro 798 é uma falha de pesquisa de certificado. Foi pedido ao cliente um certificado que correspondesse ao método de autenticação configurado, ele procurou no seu arquivo e não encontrou nada utilizável. Isso pode significar que o certificado está ausente, presente sem a chave privada, expirado ou guardado onde a pesquisa não chega. Voltar a tentar a palavra-passe não pode alterar nenhuma dessas condições, por isso o erro regressa mesmo com credenciais corretas.

Leia a mensagem antes de agir. Uma rejeição de credenciais, uma falha de pesquisa de certificado e uma falha de handshake TLS são três constatações diferentes, e só uma envolve a palavra-passe.

O que o arquivo do cliente tem de conter

Estão envolvidos dois objetos. O certificado de cliente tem de estar instalado para o utilizador que executa o cliente VPN, com a sua chave privada, e a raiz emissora tem de ser de confiança. Um ficheiro .cer contém apenas o certificado público, pelo que sozinho não pode autenticar nada. No gestor de certificados do Windows, a identidade do cliente pertence ao arquivo pessoal do utilizador atual, e a raiz ao arquivo de raízes de confiança.

Instalar a identidade no arquivo da máquina, ou apenas no arquivo de raízes, não satisfaz uma pesquisa dirigida ao arquivo pessoal do utilizador. Verifique o arquivo, o indicador de chave privada e as datas de validade em conjunto, e depois reinicie o cliente para que volte a ler o arquivo.

Dois produtos, a mesma credencial em falta

Os servidores OpenVPN exigem um certificado de cliente por predefinição. Adicionar auth-user-pass a um cliente envia um nome de utilizador e uma palavra-passe, e o handshake TLS continua a pedir um certificado, pelo que uma palavra-passe sozinha não consegue concluir a ligação em verify-client-cert require. O servidor pode ser configurado para não exigir nenhum, o que torna a palavra-passe a única credencial do cliente e representa uma redução real da segurança. Um script shell por trás de auth-user-pass-verify pode validar credenciais, e exige que a execução de scripts esteja ativada, o que o torna um desenho mais arriscado do que um backend de autenticação adequado.

Um perfil apenas com palavra-passe também depende de opções empurradas, que por sua vez dependem de o mecanismo de extração estar ativado.

Não corrija um certificado em falta desativando as verificações

A tentação é relaxar a verificação para que a mensagem desapareça. Isso remove o controlo que estava a fazer o seu trabalho e deixa uma ligação que já não prova o que afirma. Se o gateway mudou recentemente a sua raiz, transfira novamente o pacote do cliente em vez de editar o perfil, porque o pacote antigo pode ainda conter a raiz anterior. Se a opção de autenticação por certificado faltar no editor de perfis, talvez a versão do Windows instalada não exponha esse método; atualize o sistema em vez de editar o XML à mão.

Registe qual arquivo continha o certificado, que utilizador executou o cliente e se a chave privada estava presente. Estes três explicam quase todos os casos desta falha.

A palavra-passe estava bem. A credencial de que o método realmente precisava estava noutro sítio.