¿Qué archivo CA va en un perfil de OpenVPN solo con contraseña?

Recorra cuatro preguntas en orden y el diálogo de CA deja de ser ambiguo. ¿Qué material emitió realmente el operador, qué contiene ya el perfil, qué campo pregunta y qué ocurre después de que se cargue el archivo? Deténgase en la primera pregunta que no pueda responder con las instrucciones del propio operador, porque adivinar más allá es cómo un certificado CA público acaba emparejado con una clave privada que nunca debió salir del servidor.

El orden importa: las dos últimas preguntas solo tienen sentido cuando sabe qué material debería existir.

Empiece por lo que el perfil ya lleva

Abra el perfil en un editor de texto y busque un bloque ca antes de buscar un archivo. Un bloque ca incrustado que contiene el CA público del operador significa que el perfil es autosuficiente, y un cliente que aún pide un archivo CA puede estar leyendo otro perfil o una importación incompleta. Si el perfil tiene en cambio una línea ca que apunta a una ruta, esa ruta es relativa al directorio de trabajo del cliente en algunas integraciones y absoluta en otras. Anote qué forma tiene antes de cambiar nada.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Revise el paquete entregado por los archivos a los que hace referencia el perfil: un certificado CA, a veces un certificado de cliente y una clave separados, y posiblemente un archivo tls-auth o tls-crypt. Un perfil que hace referencia a cuatro archivos y llega con dos está incompleto, y ninguna cantidad de señalar campos lo arregla. Pida al operador la pieza que falta en lugar de sustituirla por un certificado que tenga por casualidad.

Separe cuatro tipos de material

El certificado CA es material público que se usa para verificar la identidad del servidor. Un certificado de cliente identifica al usuario o al dispositivo ante el servidor. Una clave privada es la mitad secreta de ese certificado de cliente, y nunca debe ser la clave de firma del CA ni una clave de servidor. El material tls-auth o tls-crypt es un secreto compartido aparte que protege el canal de control. Estos cuatro no son intercambiables, y apuntar el campo CA a un certificado de cliente produce un fallo de verificación que parece un problema de confianza.

Autenticación solo con contraseña cambia cuál de los cuatro necesita, no qué significan. Con auth-user-pass y remote-cert-tls server el cliente sigue verificando el servidor contra un CA, por eso el campo CA aparece incluso cuando no existe ningún certificado de cliente. La política del operador decide si también se exige un certificado de cliente, y ningún diálogo puede decírselo.

Apunte el cliente al archivo de confianza

Seleccione el archivo de certificado CA en sí, no la carpeta que lo contiene ni un paquete .p12 que lleva una identidad de cliente. En Windows la sintaxis de rutas y el selector de archivos se comportan de forma distinta a los ejemplos de Linux de la mayoría de las guías, así que use lo que acepte el cliente instalado y confirme que la cuenta que lo ejecuta puede leer el archivo. Un problema de permisos y un archivo ausente se ven igual en el diálogo pero producen líneas de registro distintas. Después de seleccionar, vuelva a abrir la configuración del perfil para confirmar que el cliente conservó la elección.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Si el cliente admite bloques incrustados, prefiera el perfil incrustado del operador a uno montado a mano. El material incrustado viaja con el perfil y sobrevive a la reimportación, mientras que una ruta absoluta se rompe en el momento en que el perfil se mueve a otra máquina.

Lea el siguiente error, no el mismo

El objetivo de proporcionar el CA correcto es cambiar el error, no hacerlo desaparecer. Un fallo de identidad del servidor después de cargar el CA significa que el certificado no coincidía con el nombre esperado o con la expectativa remote-cert-tls, lo que es una reparación distinta de un rechazo de contraseña. Un rechazo de contraseña significa que la capa TLS tuvo éxito y que la credencial es incorrecta. Quédese con el primer mensaje nuevo; es el útil.

Un cliente que se conecta pero no llega a nada ha pasado del todo la confianza y ahora se enfrenta a una cuestión de enrutamiento o DNS.

Nunca desactive la verificación para pasar ese diálogo. Un cliente que acepta cualquier certificado no tiene motivo para pedir un CA, y el túnel que construye no es el que el operador pretendía.