Autofirmado frente a CA pública para una VPN: qué cambia en realidad

Llegas a la página de certificados de una configuración de VPN, ves una opción autofirmada gratuita junto a una CA pública de pago, y la pregunta suena a una decisión de seguridad. En realidad es una decisión de audiencia. Ambas opciones cifran el túnel con las mismas primitivas, y ambas se vuelven inútiles si la clave privada se filtra. Lo que las separa es quién hace la afirmación sobre la identidad del servidor y quién está en posición de comprobar esa afirmación.

Un certificado hace dos trabajos que se confunden

Un certificado vincula una clave pública a un nombre, y la clave hace el trabajo de cifrado y firma. La firma del certificado es una declaración aparte: alguna autoridad comprobó que el nombre pertenece a este titular de la clave. Un certificado autofirmado hace esa declaración sobre sí mismo, lo que no es en absoluto una afirmación de terceros.

Los sitios web públicos necesitan la versión con terceros, porque los visitantes llegan sin ninguna relación previa y dependen del almacén de confianza del navegador. Un cliente VPN no es un desconocido. Le entregas el certificado de la CA, o fijas el certificado del servidor, dentro del perfil que instala, así que la verificación se ejecuta contra exactamente la autoridad que elegiste. Ninguna CA comercial tiene que participar para que esa comprobación signifique algo.

La fuerza de la sesión resultante proviene del tamaño de la clave y del conjunto de cifrados, no del firmante. Por eso llamar "menos cifrado" a un certificado autofirmado es sencillamente incorrecto; está menos ampliamente avalado, que es una propiedad distinta.

Dónde una CA pública se gana su tarifa

El caso más claro es la página de administración. Si colegas, contratistas o cualquier otra persona sin un perfil preparado tienen que abrir la interfaz web del servidor VPN sin un aviso del navegador, un certificado de confianza pública elimina esa fricción. El navegador ya confía en el firmante, así que no hay nada que importar ni nada que explicar.

Esa comodidad tiene costes que merece la pena nombrar antes de comprar. La renovación tiene que automatizarse o el sitio se rompe según un calendario, los certificados públicos exponen el nombre de host en los registros de transparencia de certificados, y los límites de tasa de emisión castigan a un script que reintenta con demasiado entusiasmo. Nada de eso es motivo para evitar una CA pública, pero es trabajo operativo que una CA privada traslada a otro lugar.

Lo que un certificado público no hace es autenticar a tus usuarios. La identidad del cliente es una decisión aparte, tomada con certificados de cliente, contraseñas o un segundo factor, y la CA que firma el servidor no dice nada sobre quién puede conectarse a él.

Dónde encaja una CA privada en una VPN

Para una VPN privada con un conjunto conocido de clientes, ejecutar tu propia CA es la opción convencional. Creas la CA una vez, firmas el certificado del servidor con un nombre que los clientes usarán y distribuyes el certificado de la CA dentro de cada perfil. Cada cliente verifica entonces el servidor contra tu autoridad, y ninguna parte externa conoce el nombre de host.

Los costes son reales pero acotados. Los navegadores avisarán cuando alguien abra la página de administración directamente, porque el navegador no tiene motivo para confiar en tu CA. La distribución de perfiles pasa a formar parte del alta, y rotar la CA significa tocar a cada cliente. Son precios aceptables para un servicio con diez o cincuenta usuarios conocidos y dolorosos para un punto final público con miles.

Una condición hace válido todo el arreglo: la verificación tiene que ocurrir. Un cliente configurado para ignorar errores de certificado acepta cualquier servidor que presente cualquier certificado, así que la garantía de identidad desaparece mientras el cifrado permanece. Ese ajuste es la debilidad real en la mayoría de las historias de "autofirmado es inseguro".

La clave privada de la CA decide qué puedes hacer después

La sorpresa suele llegar meses después, cuando quieres añadir un dispositivo. Emitir un certificado de cliente requiere la clave privada de la CA, y producir una lista de revocación también. Si heredaste un servidor que tiene los archivos de certificado y clave pero no la clave de la CA, no puedes firmar nada nuevo. Tus opciones son reconstruir la PKI y entregar a cada cliente un certificado de CA nuevo, o cambiar a autenticación por contraseña, que es un modelo de seguridad distinto y no restaura lo perdido.

Dos trampas menores viven en el mismo territorio. Los scripts de easy-rsa asumen que estás en el directorio que los contiene, así que un error de archivo no encontrado suele significar la ubicación equivocada y no una instalación dañada. Y un diseño solo con certificados es perfectamente legítimo: puedes exigir certificados de cliente sin una clave precompartida, siempre que cada cliente tenga uno y el servidor verifique la cadena.

Emite un certificado por dispositivo en lugar de un certificado de cliente compartido para todo el equipo. Un portátil perdido te cuesta entonces una sola revocación en vez de una reemisión para todos.

Comprueba qué has heredado

Antes de planificar cualquier cambio, lee el certificado que ya tienes:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Si el emisor es igual al sujeto, el certificado es autofirmado, lo que es una elección de diseño y no un defecto. Las fechas te dicen cuándo la renovación se convierte en el problema de alguien, y una verificación correcta contra la CA que piensas desplegar confirma que la cadena funciona antes de que un solo cliente lo intente.

Después elige por audiencia y distribución: CA pública cuando navegadores desconocidos deben confiar en la página de administración, CA privada cuando cada cliente recibe un perfil que controlas. Ninguna de las dos respuestas está más cifrada que la otra.