TLS certificates para servicios internos bien hechos

Artículo original ↗ Discusión en Hacker News ↗

DNS de horizonte dividido frente a alternativas

  • Muchos critican el DNS de horizonte dividido por ser frágil y costoso de mantener, especialmente a gran escala (registros duplicados, rarezas de caché, problemas de enrutamiento VPN).
  • Otros dicen que está bien para laboratorios pequeños o domésticos y que puede combinarse con hairpin NAT; el verdadero dolor está en las grandes configuraciones corporativas donde las zonas internas y públicas comparten el mismo nombre.
  • Algunos rechazan explícitamente usar DNS dividido, y prefieren zonas públicas únicas con IP internas o redes superpuestas.

ACME, DNS-01 y patrones de automatización

  • Fuerte preferencia por la validación DNS-01 frente a HTTP-01 para servicios internos.
  • Patrones comunes:
    • Usar un dominio público con APIs DNS para obtener certificados (a menudo wildcard), y luego apuntar los nombres a IPs internas.
    • Usar alias CNAME “_acme-challenge” para delegar DNS-01 a una zona/proveedor separado o a herramientas como acme-dns.
    • Servicios auxiliares ACME centrales o GitHub Actions que poseen las credenciales DNS y emiten certificados para hosts internos.
  • Interés en el próximo desafío DNS-PERSIST-01 para reducir la necesidad de actualizaciones DNS dinámicas, aunque la compatibilidad sigue siendo limitada.

CAs públicas vs CAs internas

  • Un bando: “Simplemente ejecuta una CA interna, firma certificados internos y confía en esa CA en tus dispositivos.” Se ve como la solución criptográfica limpia.
  • Contrapuntos:
    • Distribuir y gestionar anclas de confianza en sistemas operativos heterogéneos, lenguajes, contenedores y navegadores es una molestia.
    • Algunos argumentan que las CAs públicas (p. ej., Let’s Encrypt mediante DNS-01) son más simples operativamente, especialmente cuando no controlas por completo los dispositivos cliente.
    • Preocupaciones sobre límites de frecuencia y semántica de confianza (un certificado público solo prueba el control del dominio, no la identidad organizacional).

Certificados wildcard, registros CT y preocupaciones sobre hostnames/privacidad

  • A algunos les preocupa que los certificados públicos no wildcard expongan hostnames internos a través de los registros de Certificate Transparency; los certificados wildcard mitigan esto, pero centralizan el riesgo de la clave.
  • Otros no se preocupan por filtrar nombres genéricos de hosts domésticos, o dicen que la superficie de ataque importa más que la oscuridad.
  • Debate sobre si poner IPs internas y hostnames en DNS público es aceptable; algunos lo ven como inofensivo, otros lo rechazan por completo.

Almacenes de confianza del cliente y fragmentación de herramientas

  • Varios comentarios lamentan que configurar clientes para confiar en CAs internas es más difícil de lo que debería.
  • Diferentes ecosistemas usan distintos almacenes de confianza (SO, Java, navegadores, Node, Python/certifi, contenedores, snaps), lo que obliga a instalar la CA repetidamente.
  • Esta complejidad es una razón importante por la que algunos prefieren certificados ACME públicos incluso para servicios puramente internos.

Modelos de seguridad y patrones de acceso

  • Algunos defienden un estilo “BeyondCorp/zero trust”: mTLS, certificados de dispositivo y proxies inversos autenticados en lugar de VPN más DNS dividido.
  • Otros dependen de VPNs (WireGuard, Tailscale) más DNS interno, o de proxies inversos/balanceadores de carga centrales que terminan TLS y enrutan hacia servicios internos.
  • Sigue dividida la opinión sobre si usar certificados públicos para servicios internos de alto valor es apropiado; algunos lo llaman “bogus”, otros preguntan por qué sería perjudicial.