Una contraseña de VPN correcta no puede sustituir un certificado ausente

Las credenciales son correctas, el perfil se importa sin problemas y la conexión sigue fallando antes de que se complete la autenticación. En Windows el mensaje puede ser el error 798, sobre un certificado que no se encontró para el método EAP. En OpenVPN el registro del cliente muestra un handshake TLS que nunca satisface al servidor. Ambos describen el mismo objeto ausente: un certificado de cliente que el cliente debía presentar.

Una contraseña demuestra el conocimiento de un secreto; un certificado demuestra la posesión de una clave, y uno no sustituye al otro.

La contraseña nunca fue el problema

El error 798 es un fallo de búsqueda de certificado. Al cliente se le pidió un certificado que coincidiera con el método de autenticación configurado, registró su almacén y no encontró nada utilizable. Eso puede significar que el certificado falta, que está presente sin su clave privada, que ha caducado o que está guardado donde la búsqueda no llega. Volver a intentar la contraseña no puede cambiar ninguna de esas condiciones, por eso el error reaparece aun con credenciales correctas.

Lea el mensaje antes de actuar en consecuencia. Un rechazo de credenciales, un fallo de búsqueda de certificado y un fallo de handshake TLS son tres hallazgos distintos, y solo uno afecta a la contraseña.

Qué debe contener el almacén del cliente

Intervienen dos objetos. El certificado de cliente debe estar instalado para el usuario que ejecuta el cliente VPN, junto con su clave privada, y la raíz emisora debe ser de confianza. Un archivo .cer contiene solo el certificado público, así que por sí solo no puede autenticar nada. En el administrador de certificados de Windows, la identidad del cliente pertenece al almacén personal del usuario actual, y la raíz al almacén de raíces de confianza.

Instalar la identidad en el almacén del equipo, o solo en el almacén de raíces, no satisface una búsqueda dirigida al almacén personal del usuario. Compruebe el almacén, el indicador de clave privada y las fechas de validez en conjunto, y luego reinicie el cliente para que vuelva a leer el almacén.

Dos productos, la misma credencial ausente

Los servidores OpenVPN exigen un certificado de cliente de forma predeterminada. Añadir auth-user-pass a un cliente envía un nombre de usuario y una contraseña, y el handshake TLS sigue pidiendo un certificado, así que una contraseña sola no puede completar la conexión bajo verify-client-cert require. El servidor puede configurarse para no exigir ninguno, lo que convierte la contraseña en la única credencial del cliente y supone una reducción real de la seguridad. Un script de shell detrás de auth-user-pass-verify puede validar credenciales, y requiere que la ejecución de scripts esté habilitada, lo que lo convierte en un diseño más arriesgado que un backend de autenticación adecuado.

Un perfil solo con contraseña también depende de opciones empujadas, que a su vez dependen de que el mecanismo de extracción esté habilitado.

No arregle un certificado ausente desactivando las comprobaciones

La tentación es relajar la verificación para que el mensaje desaparezca. Eso elimina el control que estaba haciendo su trabajo y deja una conexión que ya no demuestra lo que afirma. Si la puerta de enlace cambió recientemente su raíz, vuelva a descargar el paquete del cliente en lugar de editar el perfil, porque el paquete antiguo puede seguir llevando la raíz anterior. Si la opción de autenticación por certificado falta en el editor de perfiles, puede que la versión de Windows instalada no exponga ese método; actualice el sistema en lugar de editar el XML a mano.

Anote qué almacén contenía el certificado, qué usuario ejecutó el cliente y si la clave privada estaba presente. Esos tres puntos explican casi todos los casos de este fallo.

La contraseña era correcta. La credencial que el método necesitaba de verdad estaba en otro sitio.