El certificado se ve en Windows, pero OpenVPN no puede usar su clave

El certificado se ve en el visor de certificados de Windows y, aun así, el cliente no puede usarlo. Ver un certificado solo demuestra que existe un objeto público en un almacén. No demuestra que el proceso de conexión encuentre la clave privada correspondiente ni que tenga permiso para usarla.

Tres objetos tienen que alinearse. El certificado seleccionado, la clave privada que hay detrás y la cuenta con la que se ejecuta el cliente son cosas distintas, y cada una puede fallar por su cuenta.

Tres objetos, tres respuestas

La versión comunitaria de OpenVPN en Windows documenta un selector de almacén de CryptoAPI, cryptoapicert, que toma una huella digital. El valor debe identificar el certificado que realmente piensa usar, no otro con un nombre parecido. Otras aplicaciones basadas en OpenVPN pueden tener un modelo de importación completamente distinto, así que el selector solo es prueba para la compilación que lo documenta. Confirme que su cliente implementa el mecanismo antes de depurar nada más abajo.

Si la compilación no admite el selector, la solución es otro formato de perfil, no otro certificado.

El selector resuelve a la identidad correcta

Un certificado público se puede importar sin su clave privada. El visor lo muestra en ambos casos, y por eso este fallo parece que el cliente ignora un certificado que está a la vista. Compruebe la asociación de la clave, no solo la presencia de la entrada.

Un certificado renovado añade una segunda trampa. Ambas entradas pueden quedarse en el almacén mientras el perfil todavía nombra la huella antigua, y el cliente sigue seleccionando la identidad que usted quería retirar.

Compruebe a qué identidad resuelve el selector antes de mirar los permisos. Una huella equivocada falla igual que una clave ausente.

Puede esta cuenta usar la clave

El acceso a la clave es por cuenta. Un servicio, una tarea programada y una sesión de escritorio interactiva pueden tener vistas distintas del almacén y permisos distintos para usar una clave privada. Que el certificado se vea en su propia sesión no dice nada sobre la cuenta del servicio.

Una clave respaldada por hardware puede necesitar su proveedor y un paso de confirmación. Un servicio que no puede mostrar un aviso no se salva exportando la clave a un archivo plano.

Lea el error local antes de cambiar nada. Un fallo de selección, un fallo de firma y un rechazo remoto son tres resultados distintos. Solo los dos primeros son locales. El tercero significa que la clave funcionó y que el servidor decidió en contra del certificado.

El uso local no es aceptación remota

El éxito local no es autorización. Una vez que el cliente firma con su clave, el servidor sigue evaluando el emisor, la ventana de validez, el rol y su política de acceso. Un certificado distinto de la misma CA no lleva automáticamente los mismos derechos de VPN.

El servidor necesita la cadena de confianza, no una copia de la clave privada del cliente. Enviar la clave al servidor nunca es la reparación de un problema de verificación.

Trate el fallo en orden

Conserve el texto exacto del error. Una falta de permiso sobre la clave no debe convertirse en un cambio de CA, y un rechazo remoto no debe convertirse en una reparación del almacén. Cada uno tiene sus propias pruebas.

Trabaje en el orden en que aparece el fallo: selector, clave, cuenta y después política del servidor. La referencia comunitaria del cliente documenta el selector de almacén de Windows para la versión que ejecuta.