Certificado VPN autofirmado: qué significa y en qué confía

Aquí hacen más daño dos creencias: que un certificado VPN autofirmado significa que el túnel no está cifrado, y que instalar lo que pidiera el cliente VPN solo afecta a la VPN. Ninguna sobrevive al contacto con un despliegue real. Un certificado autofirmado describe una relación de firma, no un veredicto de seguridad, y el alcance de la confianza que añade depende de en qué almacén aterrice. He visto a un servicio de asistencia importar una raíz de proveedor en una máquina Windows para silenciar una advertencia y luego pasar una tarde explicando por qué el navegador había dejado de quejarse de un portal sin relación. Las dos mitades de esta pregunta van juntas, así que trátelas como una sola.

Un certificado no es un almacén de confianza

El archivo que presenta el servidor lleva una clave pública, un nombre de sujeto, un nombre de emisor, fechas de validez y extensiones. Autofirmado significa que el sujeto y el emisor son la misma entidad y que la firma se verifica con la propia clave del certificado. Nada en esa definición dice que la conexión sea débil, ni nada dice que el cliente vaya a aceptarla.

La aceptación viene de otro sitio: un archivo CA al que apunta el cliente, una huella que compara a mano o una raíz que ya está en un almacén que el cliente lee. Un despliegue puede ser perfectamente sólido mientras su certificado suspendería todos los exámenes públicos. openssl verify contra el paquete del sistema informará de un emisor desconocido, y ese informe es correcto, no una falla.

La opción ca de OpenVPN es el caso más claro de confianza limitada a la aplicación. Ese archivo nombra los anclajes que el cliente aceptará, y puede contener una CA privada o, en un despliegue pequeño, el propio certificado autofirmado del servidor. La versión 2.6 también acepta --peer-fingerprint para fijar una huella SHA-256 en lugar de distribuir un archivo CA. WireGuard queda aún más lejos: no tiene ningún certificado, solo una clave pública estática por par, así que la pregunta autofirmada no se le aplica.

Dónde instala la confianza decide quién la hereda

Ponga el mismo certificado en tres lugares y obtendrá tres radios de explosión distintos. Un paquete que solo lee el cliente VPN afecta a ese cliente. Una raíz en el almacén del sistema operativo afecta a todos los programas que consultan ese almacén. Un navegador con su propia base de datos de confianza puede ignorar ambos, y por eso una advertencia puede sobrevivir a una importación que parecía funcionar.

En Debian o Ubuntu, dejar un archivo en /usr/local/share/ca-certificates/ y ejecutar update-ca-certificates altera el paquete de todo el sistema. En Windows, certutil -addstore -f Root escribe en el almacén de la máquina y necesita un símbolo del sistema elevado, mientras que añadir -user apunta al almacén del usuario actual; los dos no son intercambiables. Firefox mantiene su propia base de datos NSS, así que una importación a nivel del sistema operativo puede que nunca aparezca allí.

El alcance importa por lo que puede hacer una autoridad. Una CA emisora puede firmar nombres con los que no tiene ninguna relación, así que todo lo que confíe en ese almacén aceptará esas firmas. Una sola hoja fijada no puede hacerlo; autentica exactamente una identidad de par. Si el objetivo es hacer que una VPN conecte, una CA limitada a la aplicación o una hoja fijada lo consiguen, mientras que una raíz para toda la máquina es una concesión mucho mayor de lo que exige el síntoma.

Sigue cifrando sin una CA pública

El apretón de manos TLS deriva claves de sesión tanto si el certificado del par encadena a algo en lo que ya confía como si no. Autofirmado no significa texto plano, ni significa que el tráfico sea legible en vuelo. Significa que el cliente no tiene ninguna razón a priori para creer que la clave pertenece al servidor que pidió.

En esa brecha viven los ataques reales. Un cliente configurado para aceptar cualquier certificado, ya sea mediante un ajuste de verificación desactivado o un botón de confiar-aun-así pulsado una vez y olvidado, cifrará contento a quien responda. La interceptación ocurre en el paso de autenticación, antes de que se muevan los datos de la aplicación. El cifrado sin comprobación de identidad mantiene fuera a un observador pasivo y hace poco más.

Confiar en el emisor no se salta la comprobación del nombre

La validación de la cadena, la coincidencia del nombre y el propósito del certificado son decisiones separadas. Una cadena puede ser válida mientras el nombre es incorrecto, y un nombre puede coincidir mientras el certificado se emitió para otro papel. RFC 5280 define los campos que llevan esas restricciones, y hasta qué punto un cliente las aplica es cuestión de cada aplicación.

OpenVPN hace visible la separación. verify-x509-name fija el sujeto esperado mediante la coincidencia de name, name-prefix o subject. remote-cert-tls server exige que el certificado del par pueda usarse como certificado de servidor, lo que rechaza un certificado solo de cliente incluso cuando el emisor es de confianza. Ninguno de los dos ajustes se sustituye enviando un archivo CA.

Inspeccione el certificado antes de decidir nada:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName muestra quién lo emitió, para qué nombres y hasta cuándo.
• openssl verify -CAfile ca.crt server.crt comprueba si la cadena que piensa enviar valida realmente la hoja.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error funciona para puntos finales TLS como un portal web; el protocolo OpenVPN en el 1194 no es un flujo TLS simple, así que esa prueba no se aplica allí.

Un certificado con fecha caducada, sin subjectAltName para el nombre al que se conecta o sin el uso serverAuth falla sin importar con cuánto cuidado se instaló el anclaje.

Cinco comprobaciones antes de aceptar uno

Compare la huella por un canal que no sea la conexión que intenta reparar: una consola, un instalador que ya tenga, un archivo de configuración firmado. openssl x509 -in server.crt -noout -fingerprint -sha256 en el servidor y el mismo valor en el registro del cliente bastan para saber que está mirando un solo objeto.

Después, decida qué está instalando: una hoja o una autoridad que puede acuñar más. Luego decida adónde va y nombre las aplicaciones que leen ese almacén. Anote la ruta de retirada mientras aún la recuerda, porque confiar-y-seguir es como una importación temporal se vuelve permanente.

Por último, planifique el cambio. Un certificado o una huella fijados deben actualizarse por el mismo canal de confianza cuando el certificado rote, y una CA privada tiene su propio ciclo de vida de emisión y revocación. Si la clave privada se filtra, volver a confiar en una copia del mismo certificado no repara nada; hay que sustituir la identidad.

Si una advertencia sobrevive a las cinco comprobaciones, la pregunta útil no es qué botón la silencia sino qué almacén lee realmente el cliente y de dónde vino esa raíz. Responda eso, y la importación que está a punto de hacer se convierte en una decisión en lugar de un reflejo.