O certificado vese en Windows pero OpenVPN non pode usar a súa chave

O certificado vese no visor de certificados de Windows e, aínda así, o cliente non pode usalo. Ver un certificado só demostra que existe un obxecto público nun almacén. Non demostra que o proceso de conexión atope a chave privada correspondente nin que teña permiso para usala.

Tres obxectos teñen que aliñarse. O certificado seleccionado, a chave privada que hai detrás e a conta coa que se executa o cliente son cousas distintas, e cada unha pode fallar pola súa conta.

Tres obxectos, tres respostas

A versión comunitaria de OpenVPN en Windows documenta un selector de almacén de CryptoAPI, cryptoapicert, que toma unha pegada. O valor debe identificar o certificado que realmente pensa usar, non outro cun nome parecido. Outras aplicacións baseadas en OpenVPN poden ter un modelo de importación completamente distinto, así que o selector só é proba para a compilación que o documenta. Confirme que o seu cliente implementa o mecanismo antes de depurar nada máis abaixo.

Se a compilación non admite o selector, a solución é outro formato de perfil, non outro certificado.

O selector resolve á identidade correcta

Un certificado público pódese importar sen a súa chave privada. O visor móstrao en ambos os casos, e por iso este fallo parece que o cliente ignora un certificado que está á vista. Comprobe a asociación da chave, non só a presenza da entrada.

Un certificado renovado engade unha segunda trampa. As dúas entradas poden quedar no almacén mentres o perfil aínda nomea a pegada antiga, e o cliente segue seleccionando a identidade que quería retirar.

Comprobe a que identidade resolve o selector antes de mirar os permisos. Unha pegada equivocada falla igual que unha chave ausente.

Pode esta conta usar a chave

O acceso á chave é por conta. Un servizo, unha tarefa programada e unha sesión de escritorio interactiva poden ter vistas distintas do almacén e permisos distintos para usar unha chave privada. Que o certificado se vexa na súa propia sesión non di nada sobre a conta do servizo.

Unha chave apoiada por hardware pode necesitar o seu provedor e un paso de confirmación. Un servizo que non pode mostrar un aviso non se salva exportando a chave a un ficheiro simple.

Lea o erro local antes de cambiar nada. Un fallo de selección, un fallo de sinatura e un rexeitamento remoto son tres resultados distintos. Só os dous primeiros son locais. O terceiro significa que a chave funcionou e que o servidor decidiu contra o certificado.

O uso local non é aceptación remota

O éxito local non é autorización. Unha vez que o cliente asina coa súa chave, o servidor segue avaliando o emisor, a xanela de validez, o rol e a súa política de acceso. Un certificado distinto da mesma CA non leva automaticamente os mesmos dereitos de VPN.

O servidor necesita a cadea de confianza, non unha copia da chave privada do cliente. Enviar a chave ao servidor nunca é a reparación dun problema de verificación.

Trate o fallo por orde

Conserve o texto exacto do erro. Unha falta de permiso sobre a chave non debe converterse nun cambio de CA, e un rexeitamento remoto non debe converterse nunha reparación do almacén. Cada un ten as súas propias probas.

Traballa na orde en que aparece o fallo: selector, chave, conta e despois política do servidor. A referencia comunitaria do cliente documenta o selector de almacén de Windows para a versión que executa.