Por qué OpenVPN sigue pidiendo un archivo de clave privada aunque haya un token

Usted conecta el token, la propia herramienta del proveedor lo ve, y el cliente VPN sigue pidiendo un archivo de clave privada. Ese aviso no es prueba de que el token no sea compatible. Normalmente significa que el perfil nunca le dijo al cliente que usara el token, así que volvió a las entradas de certificado y clave que espera por defecto.

Dos valores distintos deben ser correctos antes de que ese retroceso se detenga: el proveedor que expone el token y la identidad del certificado que hay dentro. Se suministran con opciones diferentes y es fácil confundirlos.

El cliente pide un archivo porque el perfil se lo indica

Un perfil predeterminado espera un archivo de certificado y un archivo de clave privada, o un único paquete PKCS#12. Cuando faltan esas entradas, el cliente no tiene nada que cargar y se comporta casi como lo haría ante un archivo ausente, por lo que el síntoma se lee como una ruta rota y no como un mecanismo ausente. La ruta PKCS#11 sustituye esas entradas en lugar de complementarlas, así que un perfil que todavía nombra un archivo de clave seguirá usando el archivo. Elimine las entradas de archivo a propósito y deje que el token aporte ambas mitades.

La opción del proveedor nombra una biblioteca de middleware, no un dispositivo ni un certificado. Que un cliente empaquetado pueda cargar esa biblioteca depende de cómo se compiló, incluido el soporte opcional de p11-kit que algunas compilaciones activan y otras omiten. Un tutorial genérico no puede decirle qué disposición tiene su paquete.

La identidad serializada es un valor distinto

La identidad del certificado es una cadena serializada larga que produce el proceso de descubrimiento, y no es la ruta de la biblioteca, ni el PIN del token, ni el nombre de la cuenta VPN. A menudo contiene caracteres que necesitan comillas, y un valor sin comillas puede truncarse o leerse mal sin un error claro. Use la propia opción descubrimiento de identidad del cliente para listar lo que expone el token y luego copie exactamente la entrada deseada. Elegir el primer objeto de la lista es la forma en que un dispositivo acaba presentando el certificado equivocado.

La salida del descubrimiento también responde una pregunta previa: si el token es visible a través de ese proveedor. Si no lista nada, el problema está aguas arriba del cliente VPN y pertenece al middleware.

El proceso que conecta debe alcanzar el token

Una operación con el token que funciona en su sesión de escritorio no demuestra nada sobre un servicio del sistema. El servicio puede ejecutarse como otro usuario, en un espacio de nombres de montaje distinto, con una ruta de módulos que omite la biblioteca del proveedor o sin permiso para abrir el nodo del dispositivo. Identifique qué proceso sostiene realmente la conexión y pruebe desde ese contexto.

El manejo del PIN merece su propia decisión. La implementación de referencia ofrece una caché de PIN y una ruta de autenticación protegida, y ambas existen para que un operador elija un flujo de trabajo en lugar de inventarlo. No convierta un requisito sin supervisión en un PIN en texto plano dentro de un perfil compartido, porque eso cambia la protección del token por comodidad. Donde el token prohíbe la exportación de claves, la firma ocurre en el dispositivo y el PIN es el único secreto local. Trátelo con el cuidado que eso implica.

Lo que el token no reemplaza

El token autentica al cliente según la política desplegada y no reemplaza las comprobaciones del cliente sobre el servidor. Un certificado seleccionado con éxito no es permiso para aceptar un certificado de puerta de enlace inesperado, y las dos verificaciones protegen direcciones opuestas.

La inscripción todavía tiene que ocurrir en el emisor, y la puerta de enlace todavía tiene que autorizar la identidad.

Para la aceptación, separe las etapas: el proveedor carga, se encuentra el certificado previsto, la clave privada se usa con autorización local, el VPN se autentica y la operación sobre el recurso tiene éxito. Deténgase en la primera etapa que falle en lugar de recorrer contraseñas y reinstalar la pila criptográfica.

Registre las versiones, la propiedad de los módulos, el identificador público elegido y los errores saneados, y deje los PIN y los paquetes de credenciales fuera de ese registro.