TLS interno bien hecho: certificados sin dolor

Si hoy tus servicios internos todavía hablan HTTP o dependen de certificados autofirmados que alguien renovó a mano hace seis meses, probablemente ya conoces el problema: todo funciona hasta que deja de funcionar. El día que un cliente, un job, un proxy o un sidecar empieza a validar mejor que tú, aparece el clásico combo de errores de handshake, alertas en cascada y despliegues pausados porque nadie quiere tocar la configuración.

El tema no es solo “poner TLS”. El tema es operar certificados internos de forma que tu equipo no tenga que improvisar cada vez que aparece un nuevo servicio, un entorno de staging, un clúster más o una rotación de claves. En esta guía aterrizamos una práctica que sí escala: cómo emitir, distribuir, renovar y auditar certificados TLS para servicios internos sin romper la operativa diaria.

Qué problema resuelve TLS interno de verdad

TLS interno no es un capricho de seguridad ni una casilla para auditoría. Sirve para cubrir tres cosas muy concretas: confidencialidad del tráfico entre servicios, autenticación del servidor y, si lo necesitas, autenticación mutua entre clientes y backend. En una red plana o en un VPC compartido, eso reduce el impacto de un sniffing accidental, un proxy mal configurado o una credencial expuesta en un log.

También te ayuda a ordenar el caos operativo. Cuando tienes certificados emitidos por una CA interna, puedes estandarizar nombres, caducidades y procesos de renovación. Eso evita el patrón clásico de “este servicio usa un cert manual, este otro usa uno del load balancer y este tercero se rompió porque un script viejo esperaba otro CN”.

La parte menos glamorosa es que TLS interno introduce disciplina. Si no defines bien quién emite, con qué autoridad, cómo se distribuyen las cadenas de confianza y quién rota los certificados, terminas con una mini-autoridad caótica en cada equipo. Y ahí el problema no es TLS, sino la falta de un modelo operativo.

Lo que sí y lo que no debes resolver con TLS

TLS no reemplaza autenticación a nivel de aplicación, autorización ni segmentación de red. Si un servicio interno expone datos sensibles, sigue necesitando control de acceso, logs y límites de alcance. Lo que sí hace TLS es cerrar la puerta a la inspección pasiva y darle identidad criptográfica al extremo remoto.

Tampoco necesitas meter mTLS en todo desde el día uno. Para muchos equipos, empezar con TLS servidor a servidor ya elimina un montón de deuda. mTLS tiene sentido cuando quieres verificar también al cliente, por ejemplo entre microservicios críticos, acceso a bases de datos o llamadas entre clusters.

Si tu organización todavía no tiene inventario de servicios, nombres DNS estables o una forma de distribuir trust bundles, ese es el punto de partida. Sin esos tres elementos, el problema no es el certificado: es la infraestructura alrededor.

Diseña una PKI interna que no te explote en producción

La decisión más importante no es qué herramienta usar, sino cómo separar responsabilidades. Una PKI interna simple y operable suele tener al menos dos niveles: una CA raíz offline y una o varias CA intermedias online. La raíz firma intermedias; las intermedias emiten certificados de servidor o cliente. Así reduces el riesgo de exponer la raíz en una máquina que vive conectada a producción.

En equipos pequeños, la tentación es usar una sola CA y listo. Funciona al principio, pero te deja sin margen para segmentar por entorno, región o dominio de confianza. Si luego quieres separar staging de producción, o un clúster de Kubernetes de una red legacy, vas a pagar la deuda con migraciones más dolorosas.

Una forma práctica de ordenar esto es pensar en tres capas: identidad, emisión y distribución. Identidad significa nombres DNS y SAN bien definidos. Emisión significa una CA que firme con políticas claras. Distribución significa cómo llega el trust bundle a tus servicios, contenedores, máquinas virtuales y clientes.

Jerarquía mínima recomendada

Una estructura razonable para la mayoría de equipos es esta:

1. Raíz offline guardada en un entorno seguro, sin uso diario.
2. Intermedia por entorno o dominio, por ejemplo producción y no producción.
3. Certificados de servicio con validez corta, emitidos automáticamente.
4. Bundle de confianza distribuido por configuración o gestión de secretos.

Con eso ya puedes separar riesgos. Si una intermedia se compromete, revocas o reemplazas ese tramo sin tocar la raíz. Si un certificado de servicio expira, lo rotas sin rehacer toda la PKI.

No hace falta sobredimensionar desde el inicio. Si tu equipo tiene menos de 20 servicios internos, una raíz y una intermedia por entorno suele ser suficiente. Si operas varios clusters o regiones, conviene separar por dominio de fallo para no mezclar todo en una sola cadena de confianza.

Nombres, SAN y DNS: donde se rompen más cosas

El error más común es seguir pensando en Common Name como si fuera suficiente. Hoy la validación real depende de Subject Alternative Name. Eso significa que debes emitir certificados con los DNS exactos que usan tus clientes, no con nombres “bonitos” inventados para documentación.

Si un servicio responde como api.internal.svc.cluster.local, ese nombre debe estar en el SAN. Si además se accede por api.prod.example.internal, también debe figurar. No asumas que el cliente tolerará redirecciones o aliases mágicos; en TLS, el nombre importa.

Una buena práctica es definir convenciones antes de emitir nada. Por ejemplo, separar nombres por entorno y por función, y evitar comodines innecesarios. Los wildcard certificates simplifican algo de operación, pero también amplían el radio de impacto si alguien reutiliza una clave donde no debe.

Herramientas y patrones que sí valen la pena

No necesitas construir tu propia CA desde cero para empezar. Hoy hay varias rutas maduras. Si trabajas en Kubernetes, cert-manager es una pieza muy útil para automatizar emisión y renovación. Si estás en infraestructura más tradicional, puedes usar step-ca, HashiCorp Vault o incluso ACME interno si tu diseño lo permite.

La referencia oficial de cert-manager está aquí: https://cert-manager.io/docs/ . Si usas Vault para PKI, la documentación oficial está aquí: https://developer.hashicorp.com/vault/docs/secrets/pki . Y si quieres una CA ligera para entornos controlados, step-ca documenta bien su flujo en https://smallstep.com/docs/step-ca/ .

La elección depende menos de la moda y más de tu topología. En Kubernetes, cert-manager te ahorra trabajo porque integra emisión con recursos del cluster. En VMs o bare metal, Vault o step-ca suelen encajar mejor si ya tienes un plano de secretos o un servicio centralizado de identidad.

Comparativa práctica

El patrón que más se repite en equipos sanos es este: la emisión debe ser automática, pero la política no. Es decir, la herramienta firma sola, pero tú defines duración, nombres permitidos, usos de clave y quién puede pedir certificados.

Cómo operar emisión y renovación sin interrumpir servicios

Aquí está el punto que más postergan los equipos: emitir certificados es fácil; operarlos sin cortar tráfico es lo difícil. La clave está en reducir la duración de los certificados y automatizar la renovación antes de que el reloj llegue al límite. Un certificado de 90 días, por ejemplo, obliga a tener rotación probada. Uno de 365 días suele esconder procesos manuales hasta que un día falla.

La estrategia que mejor funciona es renovar con margen y recargar sin reiniciar cuando sea posible. Muchos proxies y servidores soportan reload de certificados o hot reload de configuración. Si tu aplicación no lo soporta, conviene poner un terminador TLS delante, como un ingress, un reverse proxy o un sidecar, y dejar que la app hable en claro dentro del tramo controlado.

También necesitas observabilidad. No basta con emitir. Debes alertar cuando un certificado vence en 30 días, 14 días y 7 días, y cuando una renovación falla. Si esperas al día del vencimiento, ya llegaste tarde.

Flujo operativo recomendado

1. Define una política de validez corta, por ejemplo 30, 60 o 90 días según tu madurez.
2. Automatiza la solicitud con un agente, controlador o job programado.
3. Publica el certificado nuevo en una ruta atómica, no sobrescribas archivos en caliente de forma insegura.
4. Recarga el servicio o el proxy sin reinicio completo cuando sea posible.
5. Verifica el nuevo certificado con un chequeo sintético.
6. Registra el evento y alerta si la renovación falla.

Ese flujo parece simple, pero evita dos problemas comunes: ventanas de caída por expiración y despliegues manuales fuera de horario. Si además separas la clave privada del contenedor de aplicación, reduces el riesgo de que un redeploy accidental borre todo.

Ejemplo de configuración con emisión automática

Si usas Kubernetes con cert-manager, una política básica puede verse así:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-api-cert
  namespace: payments
spec:
  secretName: internal-api-tls
  dnsNames:
    - api.payments.svc.cluster.local
    - api.payments.internal.example
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer
  duration: 2160h
  renewBefore: 360h

La idea no es copiar y pegar sin pensar. duration y renewBefore deben alinearse con tu política. Si el certificado dura 90 días, renovar 15 días antes suele darte margen suficiente para detectar errores sin llegar al borde.

Si no estás en Kubernetes, el principio sigue siendo el mismo: un agente o pipeline pide el certificado, lo guarda en una ruta estable, valida la firma y recarga el proceso. Lo importante es que el paso manual desaparezca del camino normal.

Blindaje operativo: seguridad, revocación y auditoría

Emitir certificados internos no termina cuando la cadena valida. También necesitas pensar en revocación, control de acceso y trazabilidad. Si alguien obtiene una clave privada, debes poder reemplazarla rápido y entender qué servicios confiaron en ella.

La revocación en entornos internos a veces se subestima porque muchos clientes no consultan CRL u OCSP de forma consistente. Por eso, en la práctica, la estrategia más fiable suele ser certificados de vida corta. Si un cert dura 30 o 60 días, el daño potencial baja bastante aunque la revocación no sea perfecta en todos los clientes.

Auditar también importa. Debes saber quién emitió qué, cuándo, para qué nombre y con qué política. En herramientas como Vault o cert-manager puedes registrar eventos y métricas. Si no tienes eso, al menos guarda logs de emisión y renovación en un sistema centralizado.

Controles mínimos que deberías tener

• Acceso restringido a la CA raíz y a las claves de firma.
• Separación entre entornos de producción y no producción.
• Duración corta de certificados de servicio.
• Renovación automática con alertas.
• Inventario de nombres DNS válidos por servicio.
• Procedimiento de reemplazo de claves comprometidas.

Si además trabajas con mTLS, define políticas por rol o por identidad de servicio. No dejes que cualquier cliente pueda pedir un certificado válido para cualquier backend. El control de emisión debe ser tan serio como el control de acceso a secretos.

Un plan de adopción realista para tu equipo

No necesitas migrar todo en una semana. De hecho, intentar hacerlo suele generar más fricción que valor. Lo más razonable es empezar por los servicios que más se benefician: APIs internas críticas, bases de datos, colas, paneles administrativos y tráfico entre clusters.

Un plan simple puede dividirse en tres fases. La primera fase cubre visibilidad: inventario de servicios, nombres DNS y vencimientos actuales. La segunda fase cubre emisión automática para un conjunto pequeño de servicios. La tercera fase cubre estandarización y alertas para todo el parque.

Si tu equipo opera en LatAm y comparte infraestructura entre varias sedes o nubes, conviene documentar quién es dueño de cada CA, qué servicios dependen de cada cadena y cómo se recupera operación si una intermedia falla. La distancia entre “tenemos certificados” y “podemos recuperarnos de un incidente” es enorme, y ahí es donde se juega la madurez real.

Checklist de arranque

• Inventaria servicios internos y sus nombres reales.
• Define una CA raíz offline y una intermedia por entorno.
• Elige una herramienta de emisión que ya encaje con tu stack.
• Automatiza renovación antes de tocar producción.
• Configura alertas de vencimiento y fallos de firma.
• Prueba rotación en staging con tráfico real.
• Documenta el rollback y la recuperación.

Si haces solo una cosa esta semana, que sea probar la renovación automática en un servicio no crítico. Ese ejercicio te dirá si tu problema es de PKI, de despliegue, de permisos o de observabilidad. Mejor descubrirlo en staging que a las 9 de la mañana con tráfico real.

Tabla resumen

Si quieres que TLS interno te ayude de verdad, piensa menos en el certificado como archivo y más en el sistema completo: quién lo emite, cómo lo valida, cómo se renueva y cómo se recupera cuando algo falla. Esa es la diferencia entre una implementación que solo cumple y una que se puede operar todos los días.