Por qué cryptoapicert falla en OpenVPN 3 y Connect en Windows

Copie un perfil de OpenVPN 2 que funciona en un cliente de Windows más reciente, y el certificado que el cliente antiguo encontraba por sí solo ya no se ofrece. La línea que lo hacía posible es un selector exclusivo de Windows que pertenece al cliente Community 2, y la aplicación más reciente es otro programa con otra ruta de credenciales. El perfil no ha cambiado salvo por esa línea, y eso es justo lo que hace difícil ver la diferencia.

En ese informe se confunden tres capas: el cliente Community, la biblioteca central y la interfaz que alguien instaló. Solo una de ellas entendió nunca la directiva.

Qué significa la opción donde existe

En el cliente Community OpenVPN 2 para Windows, cryptoapicert nombra un certificado que el cliente debe localizar en el almacén de certificados de Windows en lugar de en un archivo. Es una comodidad específica de Windows, y funciona porque ese cliente sabe enumerar el almacén y entregar la clave resultante a su propia pila TLS. La directiva forma parte, por tanto, del lenguaje de configuración de ese cliente, no de una propiedad del protocolo OpenVPN. Nada en el formato de transmisión la transporta.

Copie la misma línea en otra aplicación y habrá copiado una palabra que el nuevo programa puede analizar, ignorar o rechazar. Una directiva no es una característica del protocolo, y esta no es siquiera una característica de todos los clientes que hablan OpenVPN.

Qué expone en cambio la biblioteca central

OpenVPN 3 Core es una biblioteca que otras aplicaciones incrustan, y trata las credenciales externas mediante una API en lugar de una búsqueda en el almacén. La aplicación que la incrusta aporta una cadena de certificados y, más tarde, pide a la biblioteca que firme con una clave externa, y la biblioteca vuelve a llamar a la aplicación para hacerlo. Es un diseño más general, y significa que la interfaz decide qué proveedores existen. En el tratamiento de opciones de la propia biblioteca, cryptoapicert aparece entre las directivas que no están implementadas, lo que concuerda con ese reparto de responsabilidades.

La existencia de esas devoluciones de llamada no significa que una aplicación empaquetada concreta enumere el almacén personal del usuario actual, admita un proveedor de claves determinado o pueda completar una solicitud de tarjeta inteligente. Son propiedades de la interfaz, y cada una debe documentarla la interfaz.

Qué hace en cambio la interfaz de Windows

OpenVPN Connect sigue otra vía: el operador importa un archivo PKCS#12 que contiene el certificado y su clave privada en un OpenVPN Certificate Store creado para ese fin, y después asigna el certificado externo al perfil. Es un paso de importación deliberado, no un descubrimiento automático de lo que haya en el almacén personal. La distinción importa cuando alguien supone que un certificado instalado para otro propósito aparecerá sin más en la lista del cliente.

La importación también tiene una consecuencia para la política de claves, porque exportar una clave a un archivo P12 es exactamente lo que una clave no exportable está diseñada para impedir. Es una cuestión de política y no de configuración, y merece una respuesta antes de que alguien intente la importación.

Elija una vía que encaje con la política de la clave

Si la credencial es exportable y la política permite la importación documentada, use el proceso de inscripción protegido de la organización y mantenga el P12 temporal y su contraseña fuera de los registros y los scripts. Si la clave no debe salir nunca de una tarjeta inteligente o de un proveedor protegido, elija una combinación de cliente y proveedor que admita explícitamente ese requisito, u obtenga la confirmación del proveedor para la versión que instaló. Ninguna de las dos ramas es una solución alternativa para la otra.

Volver a añadir la directiva al perfil no puede aportar una integración que la aplicación no tiene. Tampoco la añade necesariamente una versión más reciente del cliente, porque la capacidad pertenece al diseño propio de la interfaz.

Una vez que la clave local funciona, el servidor sigue comprobando la identidad del certificado, la cadena y la autorización. Una clave local utilizable y una identidad de VPN aceptada son resultados separados, y mantenerlos separados es lo que evita que una limitación de la interfaz se convierta en una política de certificados debilitada.