Certificados VPN: hazlo bien sin el sufrimiento permanente de los autofirmados

Lo que en realidad estás construyendo (y lo que realmente cuesta “autofirmado”)

Cuando la gente dice «certificados VPN», normalmente mezcla tres problemas distintos:
identidad, seguridad de transporte y ciclo de vida. El túnel VPN es el transporte; el certificado es el documento de identidad; la PKI es el motor del ciclo de vida.
Si solo resuelves el transporte (encriptar paquetes) e ignoras el ciclo de vida (emisión, rotación, revocación, auditoría), obtienes el clásico «funcionó durante años»
hasta que un lunes por la mañana una expiración deja a toda la fuerza remota rehén.

Los certificados autofirmados no son inherentemente malignos. Son solo una promesa de que tú ahora eres el operador de CA, el respondedorde incidentes y el programa de cumplimiento.
Si lo haces una vez y lo documentas, puede estar bien. Si lo haces de forma casual, acabarás en un lugar donde la mitad de la flota confía en «vpn-ca-old.crt»,
una cuarta parte confía en «vpn-ca-final2.crt» y el último cuarto ejecuta una huella digital fijada desde un mensaje de Slack.

En producción, el objetivo no es «usar una CA pública» o «usar autofirmados». El objetivo es: un ancla de confianza estable, radio de impacto mínimo, renovación automatizada
y una historia de revocación que cuadre con la realidad. La mayoría de despliegues VPN deberían usar una CA privada con un root offline y uno o más intermedios online.
Es el mismo patrón que usa la PKI web; solo que lo hacemos en privado y con menos abogados.

Una regla contundente: nunca trates los certificados como configuración estática. Son credenciales con fechas de expiración, restricciones criptográficas y consecuencias operativas.
Si tu incorporación a la VPN es «copia este archivo .ovpn desde un wiki», no tienes un programa de VPN. Tienes un programa de folklore.

Datos interesantes y contexto histórico

• X.509 data de 1988, diseñado para servicios de directorio, no para flujos de trabajo modernos de DevOps. Lo heredamos de todas formas, como un ERP legado.
• TLS reemplazó a SSL en nombre y en evolución del protocolo; «SSL VPN» se sigue usando en marketing mucho después de que SSL fuese una mala idea.
• RSA dominó durante décadas; hoy ECDSA se prefiere a menudo por rendimiento y certificados más pequeños, pero la compatibilidad aún importa en clientes empresariales.
• La deprecación de SHA-1 no fue teórica: cadenas de certificados se rompieron entre ecosistemas conforme los almacenes de confianza y las políticas se endurecieron.
• Let’s Encrypt (2015) normalizó la automatización vía ACME; incluso si no puedes usar certificados públicos para la VPN, la mentalidad de automatización es el verdadero regalo.
• El stapling OCSP se hizo común en la web para reducir latencia de revocación y carga; las VPN a menudo omiten la revocación por completo y luego se sorprenden más tarde.
• La era de «certificate transparency» de Chrome obligó a las CAs públicas a registros auditable; la PKI privada no tiene eso por defecto, así que debes registrar la emisión por tu cuenta.
• Heartbleed (2014) enseñó a los equipos de ops que «rotar todo» es fácil de decir y brutal de hacer sin automatización e inventario.
• Las VPN solían ser mayormente sitio-a-sitio; el acceso remoto a escala convirtió las credenciales por usuario/dispositivo y los tiempos de vida cortos en algo mucho más importante.

Modelos de PKI que funcionan para VPN

Modelo A: PKI privada con root offline + intermedio online (recomendado)

Este es el modelo de adultos. Mantienes un root CA offline (idealmente literalmente apagado, guardado de forma segura y usado raramente).
Emite un certificado de CA intermedio desde el root. El intermedio firma certificados de servidor y cliente.
Si la clave del intermedio se compromete, revocas y la reemplazas sin tener que volver a confiar en un nuevo root en todo el mundo.

Operativamente, este modelo soporta:
certificados de entidad final de corta duración, renovación automatizada, despliegue escalonado de nuevos intermedios y una respuesta a compromisos manejable.
Además hace que los auditores se pongan menos quisquillosos, lo cual es un objetivo legítimo de SRE.

Modelo B: CA autofirmada única usada para todo (aceptable solo a pequeña escala)

Una clave CA firma todos los certificados de servidor y cliente. Fácil. También: la compromisión de una sola clave significa «quemarlo todo y volver a inscribir al planeta».
Algunos equipos viven aquí durante años porque «funciona», hasta que un portátil con la clave CA en la carpeta Downloads es robado.

Modelo C: CA pública para identidad del servidor + CA privada para identidad del cliente (a veces útil)

Si tu endpoint VPN está expuesto a Internet y quieres evitar distribuir almacenes de confianza para el certificado del servidor, usar una CA pública para el certificado del servidor
puede tener sentido. Pero los certificados de cliente siguen siendo un sistema de identidad privado; las CAs públicas no emitirán certificados tipo «employee-laptop-3421» para tu mTLS.
Seguirás ejecutando una CA privada para la autenticación de clientes.

Ten cuidado: este modelo dividido crea dos ciclos de vida paralelos. Si no puedes operar bien un ciclo, no podrás operar dos.

Modelo D: sin certificados (claves al estilo WireGuard)

WireGuard no usa X.509. Usa claves públicas/privadas estáticas con un modelo de confianza distinto: aprovisionas claves de pares y allowed IPs.
Eso puede ser más simple y fiable—hasta que necesites funciones empresariales de ciclo de vida como emisión centralizada, atestación, vidas cortas
o metadatos de identidad coherentes entre sistemas.

Si ya estás totalmente con WireGuard, aún estás haciendo «ciclo de vida de credenciales». Solo lo moviste fuera de PKI y dentro de la gestión de claves e inventario.
La disciplina operativa sigue siendo requerida.

Decisiones de diseño que cambian resultados

Elige tu estrategia de ancla de confianza: un root, múltiples intermedios

Las anclas de confianza son costosas de cambiar. Trata al root CA como una dependencia de plataforma: estable, aburrida y rara vez tocada.
Rota los intermedios con más frecuencia. Rota los certificados leaf con frecuencia. Esa es la pirámide.

Usa certificados leaf de corta duración (y automatiza la renovación)

Los certificados cliente de larga duración parecen convenientes. No lo son. Convierten la baja de usuarios en teatro de revocación y hacen que la compromisión de claves valga más.
Un buen objetivo para certificados leaf de cliente es días hasta unos pocos meses, según la madurez del manejo de dispositivos y la rapidez con la que puedas reinscribir.

Decide qué significa “identidad”: usuario, dispositivo o ambos

Si la identidad del certificado mapea solo a un usuario, cualquier dispositivo que tenga la clave puede suplantarlo. Si mapea solo a un dispositivo, el control de acceso a nivel de usuario es más difícil.
Muchas organizaciones hacen ambas cosas: certificado de dispositivo para enrollamiento y comprobaciones de postura, más autenticación de usuario (SSO/OIDC) para identidad a nivel de sesión.
No dejes que el CN del certificado se convierta en tu base de datos de RRHH. Pon identificadores estables en SAN/URI o extensiones personalizadas, y mantiene la autorización en otro lugar.

Revocación: hazla bien o no finjas

CRL y OCSP existen por una razón. Pero la revocación es operativamente complicada en VPN porque los clientes pueden estar offline, y los servidores VPN deben buscar y cachear el estado.
Si no puedes garantizar información de revocación fresca, tu control de seguridad real se convierte en la vida del certificado. Vidas cortas reducen la necesidad de revocación.

Elección de algoritmos: ECDSA vs RSA, y lo que realmente soportan tus clientes

ECDSA es rápido y compacto. RSA es ubicuo y aburrido. La respuesta correcta suele ser «RSA para máxima compatibilidad» a menos que hayas probado que tu parque de clientes
soporta ECDSA sin problemas. Mezclar algoritmos en elementos de la cadena también puede sorprender a stacks antiguos. Prueba con los dispositivos más antiguos que aún soportes.

Una cita que deberías tatuar en tus runbooks

La esperanza no es una estrategia. (idea parafraseada frecuentemente usada en círculos de ingeniería y operaciones)

Si tu plan de certificados implica esperar que la gente renueve antes de la expiración, esperar a que las revocaciones se propaguen o esperar que nadie copie la clave CA,
no estás haciendo PKI. Estás haciendo vibes.

Tareas prácticas: comandos, salidas, decisiones

Estas son tareas reales que puedes ejecutar hoy. Cada una incluye: el comando, qué significa la salida y qué decisión tomar según ella.
Úsalas durante incidentes, auditorías y conversaciones de «¿por qué a este cliente le falla mientras a otros les funciona?».

Task 1: Check when a VPN server certificate expires (leaf cert)

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/issued/vpn-server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.internal
issuer=CN = vpn-intermediate-01
notBefore=Sep 10 00:00:00 2025 GMT
notAfter=Dec  9 00:00:00 2025 GMT

Significado: Este es el certificado leaf del servidor, emitido por tu intermedio. Expira el 9 de dic.
Decisión: Si “notAfter” está dentro de tu ventana de rotación (digamos 14–30 días), renueva ahora y planifica el despliegue.
Si ya expiró, tu incidente probablemente sea “clientes no pueden conectar” con errores TLS.

Task 2: Verify a certificate chain against the CA bundle the client uses

cr0x@server:~$ openssl verify -CAfile /etc/openvpn/pki/ca-bundle.pem /etc/openvpn/pki/issued/vpn-server.crt
/etc/openvpn/pki/issued/vpn-server.crt: OK

Significado: El certificado del servidor encadena limpiamente hasta el bundle CA que proporcionaste (root + intermedio(s)).
Decisión: Si obtienes “unable to get local issuer certificate”, tu bundle está mal o incompleto; arregla el empaquetado antes de tocar la criptografía.

Task 3: Inspect SAN and Extended Key Usage (EKU) for server auth

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/issued/vpn-server.crt -noout -text | sed -n '/Subject Alternative Name/,+2p;/Extended Key Usage/,+1p'
            X509v3 Subject Alternative Name:
                DNS:vpn.example.internal, DNS:vpn
            X509v3 Extended Key Usage:
                TLS Web Server Authentication

Significado: Los clientes que validan hostname usarán SAN, no CN. EKU incluye autenticación de servidor.
Decisión: Si falta el SAN con el nombre al que se conectan los clientes, arregla las plantillas de emisión. Si EKU es incorrecto, algunos clientes rechazarán el certificado totalmente.

Task 4: Confirm the private key matches the certificate

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/issued/vpn-server.crt -noout -modulus | openssl md5
MD5(stdin)= 4c3c9c0d27a8e8b6d1a6c5f4e0a1b2c3

cr0x@server:~$ openssl rsa -in /etc/openvpn/pki/private/vpn-server.key -noout -modulus | openssl md5
MD5(stdin)= 4c3c9c0d27a8e8b6d1a6c5f4e0a1b2c3

Significado: Hashes coincidentes significan que la clave y el certificado corresponden.
Decisión: Si difieren, desplegaste un par clave/certificado desajustado. Arregla eso antes de depurar cualquier otra cosa.

Task 5: Test the TLS handshake from a client network vantage point

cr0x@server:~$ openssl s_client -connect vpn.example.internal:443 -servername vpn.example.internal -showcerts -verify 5
depth=2 CN = vpn-root
verify return:1
depth=1 CN = vpn-intermediate-01
verify return:1
depth=0 CN = vpn.example.internal
verify return:1
Verify return code: 0 (ok)

Significado: El handshake tiene éxito, la cadena verifica y SNI es correcta.
Decisión: Si la verificación falla aquí pero funciona en el servidor, probablemente tengas un middlebox, endpoint equivocado o un certificado servido por el balanceador distinto.

Task 6: See what certificate your VPN endpoint is actually serving (load balancer check)

cr0x@server:~$ echo | openssl s_client -connect 203.0.113.10:443 -servername vpn.example.internal 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = vpn-old.example.internal
issuer=CN = vpn-intermediate-00
notBefore=Jun  1 00:00:00 2025 GMT
notAfter=Sep  1 00:00:00 2025 GMT

Significado: Tu IP pública sirve un certificado viejo de un intermedio antiguo y está expirado.
Decisión: Deja de rotar certificados en el host backend y olvidar la puerta de entrada. Actualiza el certificado del balanceador/ingress de inmediato.

Task 7: Check OpenVPN server logs for TLS-auth and cert verification errors

cr0x@server:~$ sudo tail -n 30 /var/log/openvpn/server.log
VERIFY ERROR: depth=0, error=certificate has expired: CN=alice-laptop-17
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error

Significado: El certificado del cliente expiró; el servidor lo rechaza.
Decisión: Reemite el certificado del cliente (o reinscribe vía tu gestión de dispositivos). Si muchos usuarios llegan a esto, tu programa de rotación está roto.

Task 8: Inspect a client certificate for expiration and EKU (client auth)

cr0x@server:~$ openssl x509 -in /tmp/alice.crt -noout -subject -dates -ext extendedKeyUsage
subject=CN = alice-laptop-17
notBefore=Oct  1 00:00:00 2025 GMT
notAfter=Oct 31 00:00:00 2025 GMT
X509v3 Extended Key Usage:
    TLS Web Client Authentication

Significado: Certificado cliente de corta duración con EKU correcto.
Decisión: Si EKU carece de “client authentication”, algunos servidores lo rechazarán. Si la expiración es demasiado corta para tu pipeline de inscripción, aumenta la vida o arregla la automatización.

Task 9: Validate the CRL you’re distributing (and its freshness)

cr0x@server:~$ openssl crl -in /etc/openvpn/pki/crl.pem -noout -lastupdate -nextupdate -issuer
lastUpdate=Dec 27 00:00:00 2025 GMT
nextUpdate=Jan  3 00:00:00 2026 GMT
issuer=CN = vpn-intermediate-01

Significado: Tu CRL está actual y tiene nextUpdate dentro de una semana.
Decisión: Si nextUpdate está en el pasado, muchos servidores tratarán la CRL como obsoleta y o bien fallarán cerrando (buena seguridad, mal lunes) o bien fallarán abierta (mala seguridad, menos tickets).

Task 10: Confirm your VPN server is actually using the CRL

cr0x@server:~$ sudo grep -R "crl-verify" -n /etc/openvpn/server.conf
42:crl-verify /etc/openvpn/pki/crl.pem

Significado: OpenVPN está configurado para verificar revocaciones.
Decisión: Si falta, tu offboarding depende enteramente de la expiración. Eso puede ser aceptable con certificados leaf muy cortos; de lo contrario es una brecha de seguridad que deberías admitir en voz alta.

Task 11: Check the system trust store for the right root/intermediate (Linux client/server)

cr0x@server:~$ sudo openssl x509 -in /usr/local/share/ca-certificates/vpn-root.crt -noout -subject -fingerprint -sha256
subject=CN = vpn-root
sha256 Fingerprint=7A:3B:1E:2C:9F:11:5D:AA:0B:1C:44:3D:9E:8F:2A:67:0E:91:2B:7C:7B:77:64:93:2F:10:9C:54:48:99:AA:01

Significado: Puedes obtener la huella digital del root esperado.
Decisión: Si la huella no coincide con lo que pretendes, para. Podrías estar confiando en la CA equivocada. Arregla la distribución y luego revalida las cadenas.

Task 12: Enumerate soon-to-expire certs on the VPN server

cr0x@server:~$ find /etc/openvpn/pki/issued -name "*.crt" -print0 | xargs -0 -n1 -I{} sh -c 'printf "%s " "{}"; openssl x509 -in "{}" -noout -enddate | cut -d= -f2' | sort -k2
/etc/openvpn/pki/issued/vpn-server.crt Dec  9 00:00:00 2025 GMT
/etc/openvpn/pki/issued/metrics-exporter.crt Jan 15 00:00:00 2026 GMT

Significado: Un inventario rápido de fechas de expiración de certificados leaf.
Decisión: Si no puedes producir esta salida a demanda, no tienes gestión de certificados—solo sorpresas de certificados.

Task 13: Detect “wrong time” failures on clients (NTP sanity)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:42:11 UTC
           Universal time: Sun 2025-12-28 10:42:11 UTC
                 RTC time: Sun 2025-12-28 10:42:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: El tiempo está sincronizado. Los certificados son sensibles al tiempo; «aún no válido» suele ser solo un reloj roto.
Decisión: Si synchronized es “no”, arregla NTP antes de culpar a la PKI. Un portátil con el reloj desviado no puede ser razonado.

Task 14: Confirm intermediate CA constraints (basicConstraints, keyCertSign)

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/ca/vpn-intermediate-01.crt -noout -text | sed -n '/Basic Constraints/,+3p;/Key Usage/,+2p'
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

Significado: Este certificado está realmente autorizado a ser CA y firmar certificados leaf y CRLs. pathlen 0 significa que no puede crear otro intermedio debajo.
Decisión: Si CA:FALSE o falta key usage, verás fallos de cadena desconcertantes. Reemite el intermedio correctamente; no hagas hacks alrededor.

Chiste #1: Los certificados son como la leche—están bien hasta que no, y entonces tu mañana se vuelve rara muy rápido.

Guía rápida de diagnóstico

Cuando las conexiones VPN fallan, la gente recurre a invocaciones aleatorias de OpenSSL y empieza a rotar claves como si fuera un ritual. No lo hagas. Diagnostica como un SRE:
confirma el dominio de la falla, aisla la capa y luego cambia lo más pequeño que pueda arreglarlo.

Primero: ¿es alcanzabilidad o TLS?

• Comprueba la alcanzabilidad de puerto (security group, firewall, ruta, DNS). Si los clientes no pueden alcanzar el socket, los certificados son irrelevantes.
• Luego comprueba el handshake con openssl s_client o los logs detallados del cliente VPN.

Segundo: identifica qué certificado se presenta realmente

• Golpea el endpoint/IP público directamente con SNI y vuelca el certificado leaf servido.
• Si estás detrás de un balanceador o controlador de ingress, asume que el LB sirve el certificado hasta que se demuestre lo contrario.

Tercero: valida la cadena y las restricciones de nombre

• ¿El cliente confía en el root e intermedio correctos?
• ¿El certificado del servidor tiene el SAN que coincide con el nombre que usan los clientes?
• ¿Son EKU y key usages correctos para autenticación de servidor?

Cuarto: comprueba tiempo y revocación

• Relojes de clientes: «aún no válido» casi siempre significa tiempo malo.
• CRL/OCSP: CRL obsoleta u OCSP inaccesible puede causar fallos intermitentes según el comportamiento del cliente.

Quinto: decide si fallas abierto o cerrado

Algunos stacks VPN tratan fallos de revocación como fallos duros; otros permiten las conexiones. Ninguno es universalmente correcto.
Lo inaceptable es no saber qué comportamiento estás ejecutando en producción.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “certificate verify failed” solo en algunos clientes

Causa raíz: Intermedio faltante en la cadena servida, o un almacén de confianza del cliente que no incluye el intermedio/root.

Solución: Sirve la cadena completa desde el endpoint VPN (leaf + intermedio). Distribuye un bundle CA estable a los clientes y versionalo.

2) Síntoma: todos rompen a la vez, justo después de un fin de semana tranquilo

Causa raíz: Certificado de servidor expirado o intermedio CA expirado.

Solución: Monitorea fechas de expiración; rota antes de la ventana. Mantén solapamiento: despliega nuevos certificados mientras los antiguos siguen siendo válidos y prueba el endpoint servido real.

3) Síntoma: “not yet valid” o fallos intermitentes raros en un solo portátil

Causa raíz: Desfase de reloj del cliente o NTP roto.

Solución: Impone NTP vía gestión de dispositivos. Para dispositivos no gestionados, pon un paso de «revisa tu hora» en los scripts de soporte y no te cortes.

4) Síntoma: handshake falla después de que «mejoraste seguridad» a ECDSA

Causa raíz: Clientes legacy o librerías TLS que no soportan tus curvas/cifras elegidas de forma consistente.

Solución: Valida contra tu cliente peor soportado. Si debes usar ECDSA, mantén RSA como opción de compatibilidad o actualiza los clientes.

5) Síntoma: usuarios revocados aún pueden conectar por días

Causa raíz: Sin verificación de revocación, CRL obsoleta o servidor VPN que no recarga la CRL.

Solución: Habilita verificación CRL, refresca la CRL en un horario y recarga el servicio VPN (o confirma que se recarga automáticamente). O cambia a certificados de corta duración y acepta la expiración como tu control.

6) Síntoma: después de la renovación, los clientes obtienen “hostname mismatch”

Causa raíz: SAN no incluye el DNS que usan los clientes; CN es ignorado por validación moderna.

Solución: Emite certificados de servidor con SANs correctos. Estandariza el nombre de conexión (una entrada DNS canónica) y deja de permitir que la gente se conecte a alias aleatorios.

7) Síntoma: “private key does not match certificate” durante el despliegue

Causa raíz: La automatización tiró la clave de una ejecución y el certificado de otra; o alguien copió archivos manualmente.

Solución: Despliega clave+certificado como un par atómico, con verificaciones en CI/CD (modulus o hash de la clave pública). Deja de usar SCP para la PKI.

8) Síntoma: fallos de confianza repentinos tras «limpiar CAs antiguas»

Causa raíz: Eliminaste un intermedio/root que aún era necesario de los almacenes de confianza de clientes mientras los leaf aún encadenaban a él.

Solución: Planea transiciones de CA como migraciones: solapa intermedios, re-emite leafs, valida la adopción de la flota y luego elimina anclas de confianza antiguas.

Tres microhistorias corporativas desde el frente

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana ejecutaba OpenVPN detrás de un balanceador de carga. Renovaron el certificado VPN en los hosts OpenVPN, probaron desde dentro del VPC,
vieron handshakes verdes y cerraron el ticket. Luego llegó el lunes y los usuarios remotos no pudieron conectar.

La suposición errónea fue sutil: «el servidor presenta el certificado». En realidad el balanceador terminaba TLS y presentaba su propio certificado.
Los servidores OpenVPN backend nunca importaron para la presentación del certificado, así que su renovación no tuvo efecto en la experiencia del usuario.

Soporte pasó horas recopilando logs de cliente. Ingenieros rotaron configs de cliente, reiniciaron OpenVPN e incluso revertieron una actualización de kernel aparentemente no relacionada.
Nada cambió el hecho de que la IP pública seguía sirviendo un certificado expirado del trimestre anterior.

La solución tomó minutos: subir la cadena renovada al balanceador, confirmar con openssl s_client desde un portátil fuera de la red,
y luego programar un postmortem donde «probar el endpoint real» pasó a ser una regla, no un consejo.

Microhistoria 2: La optimización que salió mal

Otra organización decidió que la validación de certificados era «lenta». Tenían alto churn de conexiones VPN por clientes móviles, y alguien notó picos de CPU
durante ventanas de reconexión. La optimización propuesta: deshabilitar chequeos de revocación y aumentar la vida de certificados cliente de 30 días a dos años.

El rendimiento mejoró. Los tickets cayeron. El equipo se felicitó por «eliminar complejidad». Luego un portátil de un contratista desapareció.
La baja de personal se hizo en RRHH, las cuentas fueron deshabilitadas en SSO y todos asumieron que el acceso VPN también había desaparecido.

No fue así. La VPN dependía del certificado cliente, no del SSO. Sin verificaciones de revocación y con una vida de dos años, la clave del portátil robado siguió
siendo un token válido. La organización tuvo suerte: detectaron patrones de tráfico inusuales y lo contuvieron antes de que fuera un titular.

La respuesta eventual al compromiso fue dolorosa: re-emisión de CA de emergencia, reinscripción forzada y muchas reuniones de «por qué hicimos esto».
La lección fue aburrida: si «optimizas» eliminando controles de ciclo de vida, no optimizaste—solo trasladaste el coste a la respuesta a incidentes.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una compañía global ejecutaba una PKI privada con un root offline y dos intermedios: «current» y «next». Cada trimestre emitían nuevos certificados de servidor
y desplegaban el intermedio «next» a los clientes antes de usarlo para nada.

Esto parecía burocracia. Requería mantener un bundle CA, escribir código de distribución para endpoints y llevar inventario.
A nadie le encantaba, pero era predecible.

Un día se sospechó exposición de la clave de un intermedio debido a un proceso de backup mal configurado. No hubo compromiso confirmado, pero suficiente humo para actuar.
Revocaron el intermedio, promovieron el intermedio «next» a «current» y re-emitieron certificados de servidor y cliente en un cronograma ajustado.

El negocio apenas lo notó. El acceso VPN continuó porque los clientes ya confiaban en el nuevo intermedio, y los certificados leaf eran cortos de todos modos.
La práctica «aburrida» trimestral convirtió una situación temible en un mantenimiento controlado. Así se siente la buena operación: tranquila.

Chiste #2: La PKI es el único lugar donde «confía en mí» se implementa como un archivo que debes distribuir a cada dispositivo en la Tierra.

Listas de verificación / plan paso a paso

Plan paso a paso: construye una PKI VPN que no te devuelva odio

1. Define el alcance.
   Decide si los certificados identifican usuarios, dispositivos o ambos. Escríbelo. Si no puedes explicarlo en dos frases, acabarás codificando confusión en los certificados.
2. Crea un root CA offline.
   Genera una clave root en una máquina segura. Mantenla offline. Úsala solo para emitir intermedios. Guarda copias de seguridad con controles de acceso.
3. Crea un intermedio CA online para emisión VPN.
   Úsalo para firmar certificados leaf de servidor y cliente. Ajusta pathlen:0 para evitar proliferación accidental de intermedios.
4. Estandariza tus nombres.
   Elige un nombre DNS canónico para el endpoint VPN. Ponlo en SAN. Deja de permitir que la gente se conecte a hostnames e IPs aleatorios.
5. Fija duraciones deliberadamente.
   Root: largo (años). Intermedio: medio (1–3 años). Leaf servidor: más corto (meses). Leaf cliente: corto (días a pocos meses).
6. Automatiza emisión y renovación.
   La emisión manual está bien para un laboratorio. En producción se convierte en una cola. Integra con tu gestión de dispositivos o portal de inscripción.
7. Decide la estrategia de revocación.
   Si puedes mantener CRLs frescas y aplicadas, hazlo. Si no, apóyate en certificados de corta duración y acepta que la revocación es limitada.
8. Instrumenta monitoreo de expiración.
   Alertas para: expiración de leaf servidor, expiración de intermedio, nextUpdate de CRL. No alertes a 180 días; alerta en ventanas accionables.
9. Prueba el borde real.
   Valida qué certificado sirve realmente el endpoint público (LB, ingress). Haz que esto sea una puerta de liberación.
10. Practica la rotación.
    Programa rotaciones rutinarias de certificados. Si la rotación solo ocurre en emergencias, siempre será una emergencia.
11. Registra emisión e inscripción.
    Mantén una pista de auditoría: quién solicitó un certificado, qué identidad representa, cuándo se emitió, cuándo se revocó o expiró.
12. Documenta el camino de “romper vidrio”.
    Quién puede firmar un nuevo intermedio, dónde vive el root, cómo distribuir nuevos bundles de confianza y qué clientes necesitan reinscribirse.

Lista de despliegue: renovar el certificado del servidor VPN sin downtime

• Confirma el certificado servido actual desde fuera de la red (LB vs backend).
• Emite nuevo certificado leaf de servidor con SANs y EKU correctos.
• Despliega la cadena completa (leaf + intermedio) donde se termina TLS.
• Recarga/reinicia el servicio de forma segura; confirma que el nuevo certificado se sirve.
• Ejecuta comprobaciones de handshake desde al menos dos redes (corp + externa).
• Monitorea la tasa de éxito de conexiones y los logs de error durante 30–60 minutos.

Lista de offboarding: eliminar acceso VPN cuando alguien se va

• Deshabilita la autenticación de usuario (SSO) si se usa.
• Revoca el certificado cliente (si la revocación está aplicada) y publica la CRL actualizada.
• Si la revocación no es fiable, asegura que la vida del certificado cliente sea corta y fuerza reinscripción en el siguiente uso.
• Invalida la postura del dispositivo o el enrollment MDM si aplica.
• Audita: confirma que la identidad no pueda establecer una sesión VPN tras las acciones de offboarding.

Preguntas frecuentes

1) ¿Debo usar un certificado de CA pública para mi servidor VPN?

A veces. Si tienes muchos clientes no gestionados y quieres que confíen en el servidor sin distribuir un root privado, la CA pública puede ayudar para el lado del servidor.
Pero los certificados cliente (mTLS) aún requieren emisión privada y ciclo de vida, así que no confundas «certificado de servidor público» con «PKI resuelta».

2) ¿“Autofirmado” es lo mismo que “CA privada”?

No exactamente. Un leaf autofirmado es un callejón sin salida que fijas manualmente. Una CA privada es un ancla de confianza gestionada que firma otros certificados y puede soportar rotación y política.
La gente usa «autofirmado» para decir «no es una CA pública», pero operativamente la diferencia es enorme.

3) ¿Realmente necesito un root CA offline?

Si te importa el radio de impacto, sí. Un root offline es un seguro barato: rara vez lo tocas, y convierte la “compromiso de intermedio” de apocalipsis a migración.
Si eres muy pequeño y totalmente gestionado, puedes empezar sin él—solo no finjas que esa es la arquitectura final.

4) ¿Qué tan cortas deben ser las vidas de los certificados cliente?

Lo bastante cortas como para que las claves robadas queden obsoletas rápido, lo bastante largas como para que tu pipeline de inscripción no colapse. Muchos equipos se sitúan entre 7 y 90 días.
Si puedes auto-renovar silenciosamente vía gestión de dispositivos, puedes ir más corto.

5) Si uso certificados de corta duración, ¿puedo omitir la revocación?

Puedes, pero asume el trade-off. Las vidas cortas reducen el valor de la revocación pero no la eliminan—especialmente para roles de alto riesgo.
Si omites la revocación, acorta vidas y ten un camino para forzar reinscripción cuando sea necesario.

6) ¿Por qué algunos clientes fallan después de una rotación de CA mientras otros funcionan?

Porque la distribución de confianza es desigual. Algunos dispositivos recibieron el nuevo bundle CA; otros no. O caché de una cadena vieja.
Por eso versionas bundles CA, rastreas estado de inscripción y despliegas anclas de confianza antes de cambiar la emisión.

7) ¿Cuál es la causa más común de “hostname mismatch”?

Entradas SAN faltantes. La validación TLS moderna usa SAN; CN no es usado de forma fiable.
Arregla tus plantillas de emisión y estandariza el nombre DNS del endpoint VPN.

8) ¿Puedo almacenar claves cliente VPN en el perfil de usuario en portátiles?

Puedes, pero es más débil que almacenamiento con respaldo hardware. Si la clave privada puede copiarse, puede reutilizarse en otro lugar.
Prefiere keychains del SO, claves respaldadas por TPM o certificados gestionados en dispositivos cuando sea posible.

9) ¿Por qué habilitar la comprobación CRL causó un outage?

Usualmente porque la CRL expiró o se volvió inaccesible y tu servidor/cliente falla cerrando. Esa no es una razón para deshabilitar revocación;
es una razón para automatizar la publicación de CRL, monitorear nextUpdate y probar el comportamiento de recarga.

10) ¿Necesito OCSP para VPNs?

No siempre. Las CRL son más simples operativamente en muchos entornos privados. OCSP añade piezas móviles y dependencias de disponibilidad.
Si no puedes mantener OCSP altamente disponible, puede convertirse en una negación de servicio autoinfligida.

Conclusión: próximos pasos que puedes hacer esta semana

Hacer los certificados VPN correctamente no se trata de comprar un producto o memorizar flags de OpenSSL. Se trata de elegir un modelo de confianza que puedas operar bajo estrés,
y luego construir un ciclo de vida alrededor: emisión, rotación, revocación (o vidas cortas) y verificación en el borde real.

Pasos prácticos:

1. Ejecuta el comando de inventario de expiración en tus servidores VPN y anota qué expira en los próximos 60 días.
2. Desde fuera de tu red, confirma qué certificado sirve realmente tu endpoint público.
3. Decide por root offline + intermedio online y programa la migración si aún no lo estás.
4. Fija vidas de certificados cliente a algo que puedas rotar sin heroísmos y luego automatiza la renovación.
5. Elige un enfoque de revocación y pruébalo en horario laboral, no durante un incidente.
6. Convierte la “Guía rápida de diagnóstico” en una página de runbook y haz que el on-call la siga antes de cambiar cualquier cosa.

Si haces estas cosas, el “problema de certificados VPN” deja de ser un género recurrente de outage y pasa a ser mantenimiento rutinario. Ese es todo el punto.