Un contrasinal VPN correcto non pode substituír un certificado ausente

As credenciais son correctas, o perfil impórtase sen problemas e a conexión segue fallando antes de que se complete a autenticación. En Windows a mensaxe pode ser o erro 798, sobre un certificado que non se atopou para o método EAP. En OpenVPN o rexistro do cliente mostra un handshake TLS que nunca satisfai o servidor. Ambos describen o mesmo obxecto ausente: un certificado de cliente que o cliente debía presentar.

Un contrasinal demostra o coñecemento dun segredo; un certificado demostra a posesión dunha clave, e un non substitúe o outro.

O contrasinal nunca foi o problema

O erro 798 é un fallo de busca de certificado. Pediuse ao cliente un certificado que coincidise co método de autenticación configurado, rexistrou o seu almacén e non atopou nada utilizábel. Iso pode significar que o certificado falta, que está presente sen a súa clave privada, que caducou ou que está gardado onde a busca non chega. Volver tentar o contrasinal non pode cambiar ningunha desas condicións, por iso o erro reaparece aínda con credenciais correctas.

Lea a mensaxe antes de actuar en consecuencia. Un rexeitamento de credenciais, un fallo de busca de certificado e un fallo de handshake TLS son tres achados distintos, e só un afecta o contrasinal.

Que debe conter o almacén do cliente

Interveñen dous obxectos. O certificado de cliente debe estar instalado para o usuario que executa o cliente VPN, xunto coa súa clave privada, e a raíz emisora debe ser de confianza. Un ficheiro .cer só contén o certificado público, así que por si só non pode autenticar nada. No administrador de certificados de Windows, a identidade do cliente pertence ao almacén persoal do usuario actual, e a raíz ao almacén de raíces de confianza.

Instalar a identidade no almacén do equipo, ou só no almacén de raíces, non satisfai unha busca dirixida ao almacén persoal do usuario. Comprobe o almacén, o indicador de clave privada e as datas de validez en conxunto, e despois reinicie o cliente para que volva ler o almacén.

Dous produtos, a mesma credencial ausente

Os servidores OpenVPN esixen un certificado de cliente por defecto. Engadir auth-user-pass a un cliente envía un nome de usuario e un contrasinal, e o handshake TLS segue pedindo un certificado, así que un contrasinal só non pode completar a conexión baixo verify-client-cert require. O servidor pódese configurar para non esixir ningún, o que converte o contrasinal na única credencial do cliente e supón unha redución real da seguridade. Un script de shell detrás de auth-user-pass-verify pode validar credenciais, e require que a execución de scripts estea habilitada, o que o converte nun deseño máis arriscado que un backend de autenticación axeitado.

Un perfil só con contrasinal tamén depende de opcións empurradas, que á súa vez dependen de que o mecanismo de extracción estea habilitado.

Non arranxe un certificado ausente desactivando as comprobacións

A tentación é relaxar a verificación para que a mensaxe desapareza. Iso elimina o control que estaba facendo o seu traballo e deixa unha conexión que xa non demostra o que afirma. Se a pasarela cambiou recentemente a súa raíz, volva descargar o paquete do cliente en lugar de editar o perfil, porque o paquete antigo pode seguir levando a raíz anterior. Se a opción de autenticación por certificado falta no editor de perfís, pode que a versión de Windows instalada non expoña ese método; actualice o sistema en lugar de editar o XML a man.

Anote que almacén contiña o certificado, que usuario executou o cliente e se a clave privada estaba presente. Eses tres puntos explican case todos os casos deste fallo.

O contrasinal era correcto. A credencial que o método necesitaba de verdade estaba noutro sitio.