Certificado de cliente autoassinado? O servidor VPN continua a rejeitá-lo

O operador envia um endereço e um nome de utilizador, e o cliente pede um ficheiro de AC, um certificado e uma chave. Gerar esses três localmente parece o passo seguinte óbvio. O resultado é um certificado em que só a sua máquina acredita. A confiança do servidor está ancorada numa AC que não controla, pelo que o handshake termina antes de começar.

A confiança vive no servidor, não no seu perfil

A autenticação por certificado é uma comparação. O cliente apresenta um certificado; a gateway verifica se foi assinado por uma das AC da sua configuração.

O seu perfil indica o ficheiro de AC que o cliente deve usar para verificar o servidor. Não pode indicar uma AC que o servidor deva usar para o verificar a si. Essa metade da configuração não é sua.

Um certificado feito por si falha esta comparação mesmo quando é tecnicamente perfeito. Tem uma assinatura válida, um sujeito e datas, mas o emissor é uma AC de que a gateway nunca ouviu falar. O erro aparece durante o handshake, depois de o servidor já ter pedido um certificado. Nada no perfil do cliente pode mudar a resposta.

Porque um certificado autoassinado não o pode substituir

Um certificado autoassinado é assinado com a sua própria chave. A assinatura verifica-se contra o mesmo ficheiro, o que o torna autoconsistente e inútil como credencial para a gateway de outra pessoa.

A gateway não pergunta se o certificado é internamente coerente. Pergunta se foi assinado por um emissor de confiança.

É por isso que as mensagens de erro confundem. O cliente pode relatar uma falha de verificação que soa a problema do servidor, enquanto o servidor registra um emissor desconhecido. Ambos descrevem a mesma incompatibilidade de extremos opostos.

O caminho do CSR preserva a sua chave privada

Ainda pode fazer a maior parte do trabalho localmente. Gere um par de chaves, construa um pedido de assinatura de certificado em torno da metade pública e envie esse pedido ao operador. Só o pedido sai da sua máquina. A metade privada fica onde a gerou.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

O operador assina o pedido com a sua AC e devolve um certificado. A sua chave privada nunca viajou, e o resultado encadeia na âncora em que a gateway confia.

Os serviços geridos saltam frequentemente o CSR e emitem o pacote completo. É uma troca razoável quando o mesmo fornecedor já termina o túnel e detém a AC. A custódia da chave não melhora por a guardar, porque o fornecedor pode cunhar outra a qualquer momento.

Os pacotes são importados, não instalados

Os pacotes de fornecedores com nomes que soam a segurança são frequentemente perfis OpenVPN. Contêm configuração e por vezes certificados, e não instalam nada. Importe o ficheiro para um cliente que fale o protocolo, e a ligação fica configurada.

A regra de manuseamento decorre do conteúdo. Se o perfil incorporar uma chave privada, é uma credencial e merece o mesmo cuidado que uma palavra-passe: nada de email, nada de repositório, nada de pasta de transferências partilhada. Quando o operador fornece ca.crt, client.crt e client.key separadamente, guarde-os juntos com permissões restritas e aponte o perfil para eles.

Acrescente as verificações que o operador pode ter omitido

Um perfil gerado pelo router às vezes não tem verificação do par. remote-cert-tls server exige que o certificado do par tenha a finalidade de autenticação de servidor, para que um certificado de cliente não possa ser reproduzido como servidor. Essa linha é uma pequena alteração com uma justificação clara.

verify-x509-name vai mais longe quando o operador pode indicar o sujeito ou o SAN esperados. Ambos são pequenos acrescentos a um perfil, e ambos são defensáveis. Inspecione o que recebeu antes de o importar.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

As definições de verificação não são uma reparação de uma cadeia quebrada. Se o emissor estiver errado, a resposta é um certificado da AC correta, não um indicador que desliga a verificação. Desligar a verificação transforma uma falha de autenticação numa falha não detectada.

Peça um único pacote: o certificado da autoridade em PEM, um certificado de cliente assinado por essa autoridade, uma chave que tenha gerado ou que tenha chegado por um canal em que confie, e o nome exato do servidor que o certificado deve apresentar. Anote a data de validade na mesma mensagem, porque um certificado expirado parece uma avaria de rede meses depois.