Un perfil de OpenVPN tiene tres bloques de certificado: ¿cuál es secreto?

Abres un archivo .ovpn para cambiar una línea y encuentras tres bloques de base64 que parecen credenciales. Uno es seguro de publicar, otro es tan sensible como una contraseña y otro es una clave pública que no significa nada si otra cosa no se firmó con su pareja. La gente pega el archivo entero en un hilo de soporte porque los bloques parecen intercambiables, y así es como una clave de cliente acaba en un archivo público. Aclarar qué hace cada bloque explica buena parte de la confusión alrededor de estos perfiles y también te dice qué fallos te toca arreglar a ti.

Un archivo, tres bloques, trabajos distintos

Un perfil típico incrusta un bloque ca, un bloque cert y un bloque key entre los marcadores BEGIN y END, o bien apunta a los mismos tres como archivos separados. Algunos perfiles añaden un cuarto bloque para una clave tls-auth o tls-crypt, que es un secreto compartido y no un certificado. El cliente lee cada bloque según la directiva que lo nombra, así que las etiquetas importan más que el orden en que aparecen.

Trata el perfil ensamblado como sensible hasta que hayas mirado de verdad dentro. Un certificado público y una clave privada pueden estar a pocas líneas uno de otro en el mismo archivo, y una captura de pantalla que incluya la cabecera puede incluir ambos. Tapar el base64 visible a mano tampoco es fiable, porque un bloque parcial sigue filtrando los metadatos del certificado que nombran tu despliegue. Copiar las tres directivas sin sus valores suele bastar para hacer una pregunta útil.

Las directivas alrededor de los bloques deciden cómo se usan. Cambia ca y el cliente confía en otra autoridad; cambia cert sin cambiar key y el apretón de manos falla con una discrepancia que no tiene nada que ver con la confianza.

El bloque de CA es público, la clave de CA nunca

Una autoridad de certificación firma certificados que ligan una clave pública a una identidad, y su propio certificado es el ancla que usa un cliente para decidir si una cadena es fiable. Ese certificado es público por diseño: enviarlo dentro de cada perfil es normal, y es la razón por la que un despliegue autofirmado puede funcionar sin una autoridad comercial.

Lo que nunca debe aparecer en un perfil de cliente es la clave privada de firma de la autoridad. El cliente no la necesita para validar nada, y su presencia significa que quien tenga el perfil puede acuñar identidades nuevas para todo el despliegue.

Confiar en una autoridad también es más estrecho de lo que suena. Un cliente que acepta cualquier certificado firmado por la CA seguirá aceptando un certificado emitido para otro servicio en la misma CA. Las opciones que fijan el rol o el nombre esperado del servidor cierran esa brecha, y la Referencia de opciones de TLS enumera las directivas de verificación que lo hacen.

Los certificados de servidor y de cliente apuntan en direcciones opuestas

El certificado del servidor es lo que el cliente inspecciona para confirmar que llegó al punto final correcto. Tu certificado de cliente va al revés: el servidor lo usa para decidir que este dispositivo o usuario es uno que él inscribió. Mismo formato, dirección de confianza opuesta.

Una dirección no es una identidad. Llegar a la IP correcta no demuestra nada sobre quién respondió, y por eso la comprobación del nombre de host o del nombre del certificado sigue perteneciendo al perfil. Una contraseña de cuenta tampoco sustituye en silencio un certificado de cliente exigido, porque los dos se comprueban en etapas distintas y un despliegue puede exigir ambos.

La clave privada del cliente es la parte que debe permanecer privada. Si puede haberse expuesto, borrar el archivo de tu portátil no cambia nada en el servidor, que seguirá aceptando el certificado correspondiente hasta que el operador lo revoque. Pedir al operador que reemplace o revoque esa identidad es la única solución que viaja contigo.

Dos avisos que parecen idénticos y no lo son

Una clave guardada en forma cifrada pide una frase de contraseña antes de que el cliente pueda usarla. El servicio de VPN puede pedir por separado una contraseña de cuenta, y los dos avisos pueden aparecer con segundos de diferencia y casi el mismo texto. La frase de contraseña protege un archivo de tu disco; la contraseña demuestra una cuenta ante un servidor. Confundirlas manda a la gente a restablecimientos que no pueden ayudar de ninguna manera.

Lee el aviso antes de restablecer nada. Un restablecimiento de contraseña de cuenta no hace nada por una frase de contraseña olvidada de una clave, un certificado revocado o uno caducado, y restablecer la contraseña cuando el fallo es de validación del certificado convierte una solución de dos minutos en un caso de soporte. Si la queja menciona fechas de validez, comprueba primero el reloj del dispositivo y luego la ventana propia del certificado nombrado.

Cuando el certificado ha caducado de verdad, el reemplazo tiene que venir de quien lo emitió. Una clave que pertenece a otra persona no es una vía de renovación, y tomar prestado un perfil que funciona de un colega tampoco.

Qué demuestra un apretón de manos limpio y qué no

Llegar a un apretón de manos TLS completado significa que la relación de identidad configurada se mantuvo: el certificado del servidor encadenó con tu CA y tu certificado fue aceptado. No dice nada sobre la política de registros del operador, ni sobre si tus aplicaciones funcionarán una vez levantado el túnel.

Las rutas y el DNS son etapas posteriores de la conexión, así que un host de intranet inalcanzable tras un inicio de sesión correcto es un problema de conectividad y no de certificado. Trabaja esa capa en lugar de cambiar credenciales, y mantén juntos el origen del perfil, su material privado y sus comprobaciones de identidad cuando se lo pases a alguien.