O certificado aparece no Windows mas o OpenVPN não consegue usar a chave

O certificado aparece no visualizador de certificados do Windows e, mesmo assim, o cliente não consegue usá-lo. Ver um certificado prova apenas que existe um objeto público num armazenamento. Não prova que o processo de ligação encontre a chave privada correspondente nem que tenha permissão para a usar.

Três objetos têm de estar alinhados. O certificado selecionado, a chave privada por detrás dele e a conta em que o cliente é executado são coisas distintas, e cada uma pode falhar por si.

Três objetos, três respostas

A versão comunitária do OpenVPN no Windows documenta um seletor de armazenamento CryptoAPI, cryptoapicert, que recebe uma impressão digital. O valor tem de identificar o certificado que realmente pretende usar, não outro com um nome parecido. Outras aplicações baseadas no OpenVPN podem ter um modelo de importação completamente diferente, por isso o seletor só é prova para a compilação que o documenta. Confirme que o seu cliente implementa o mecanismo antes de depurar qualquer coisa a jusante.

Se a compilação não suportar o seletor, a solução é outro formato de perfil, não outro certificado.

O seletor resolve para a identidade correta

Um certificado público pode ser importado sem a sua chave privada. O visualizador mostra-o de qualquer forma, e é por isso que esta falha parece um cliente a ignorar um certificado que está claramente presente. Verifique a associação da chave, não apenas a presença da entrada.

Um certificado renovado acrescenta uma segunda armadilha. As duas entradas podem ficar no armazenamento enquanto o perfil ainda indica a impressão digital mais antiga, e o cliente continua a selecionar a identidade que queria retirar.

Verifique para que identidade o seletor resolve antes de olhar para as permissões. Uma impressão digital errada falha da mesma forma que uma chave em falta.

Esta conta pode usar a chave

O acesso à chave é por conta. Um serviço, uma tarefa agendada e uma sessão de ambiente de trabalho interativa podem ter vistas diferentes do armazenamento e permissões diferentes para usar uma chave privada. O facto de o certificado ser visível na sua própria sessão não diz nada sobre a conta de serviço.

Uma chave suportada por hardware pode precisar do seu fornecedor e de um passo de confirmação. Um serviço que não consegue mostrar um pedido não é salvo ao exportar a chave para um ficheiro simples.

Leia o erro local antes de mudar seja o que for. Uma falha de seleção, uma falha de assinatura e uma rejeição remota são três resultados diferentes. Apenas os dois primeiros são locais. O terceiro significa que a chave funcionou e que o servidor decidiu contra o certificado.

O uso local não é aceitação remota

Um sucesso local não é uma autorização. Depois de o cliente assinar com a sua chave, o servidor continua a avaliar o emissor, a janela de validade, o papel e a sua política de acesso. Um certificado diferente da mesma AC não traz automaticamente os mesmos direitos de VPN.

O servidor precisa da cadeia de confiança, não de uma cópia da chave privada do cliente. Enviar a chave para o servidor nunca é a reparação de um problema de verificação.

Trate a falha por ordem

Guarde o texto exato do erro. Uma permissão em falta sobre a chave não deve tornar-se uma alteração de AC, e uma rejeição remota não deve tornar-se uma reparação do armazenamento. Cada uma tem as suas provas.

Trabalhe na ordem em que a falha aparece: seletor, chave, conta e depois política do servidor. A referência comunitária do cliente documenta o seletor de armazenamento do Windows para a versão que executa.