TLS interno seguro con proxies ACME y delegación de DNS

Los entornos autoalojados a menudo tienen dificultades para obtener certificados TLS válidos para servicios que no son directamente accesibles desde Internet. Una reciente guía técnica de Sapiolab describe una arquitectura robusta que utiliza un proxy ACME y un servidor DNS dedicado para resolver este problema de conectividad. Publicado el 15 de octubre de 2026, el artículo ofrece un método paso a paso para que los operadores de homelabs y pequeños equipos de TI automaticen la emisión de certificados de forma segura.

Qué ocurrió

El desafío central abordado es la limitación de los métodos estándar de validación ACME para servidores internos. Los desafíos HTTP-01 requieren que el servidor sea accesible desde Internet público, lo cual suele ser imposible o inseguro para infraestructuras privadas. Los desafíos DNS-01 requieren acceso API al proveedor de DNS autoritativo, lo que plantea riesgos de seguridad si las credenciales se exponen en máquinas internas. La solución propuesta implica desplegar un proxy ACME que actúa como intermediario entre clientes internos y Autoridades de Certificación (CA) públicas.

Este proxy convierte las solicitudes de validación internas en órdenes DNS-01 externas. Para evitar exponer las claves API del DNS principal, la configuración utiliza un servidor DNS ACME separado. Este servidor local gestiona los registros de desafío mediante un truco de delegación CNAME, permitiendo que las CA públicas validen la propiedad del dominio sin acceder a la zona DNS principal. La guía explica cómo instalar MariaDB, NGINX, Step CA y Unbound para crear un pipeline de certificados totalmente automatizado y seguro.

Detalles clave

• La arquitectura utiliza Step CA o Lab-CA para la gestión interna de certificados, destacando Step CA por ser más ligero y sencillo de instalar.
• Un proxy ACME traduce las solicitudes internas HTTP-01 o DNS-01 en órdenes DNS-01 externas para CA públicas como Let’s Encrypt o ZeroSSL.
• El External Account Binding (EAB) puede agrupar múltiples cuentas internas bajo una sola cuenta externa, aunque el comportamiento de verificación de dominios puede variar según el proveedor.
• ACME DNS actúa como puente, alojando localmente los registros TXT _acme-challenge mientras la CA pública sigue un registro CNAME para encontrarlos.
• La configuración requiere una estructura de split-DNS utilizando Unbound para resolver correctamente las consultas internas mientras delega los subdominios de desafío.
• Los certificados privados evitan los registros de Certificate Transparency, pero requieren la instalación manual del almacén de confianza en cada dispositivo cliente e imagen de contenedor.

Contexto

ACME es el protocolo utilizado por la mayoría de las Autoridades de Certificación modernas para automatizar la emisión de certificados TLS. Se basa en desafíos para probar la propiedad del dominio. HTTP-01 coloca un archivo en el servidor web, mientras que DNS-01 añade un registro de texto específico a la zona DNS del dominio. Para los servidores internos, ninguno de estos métodos es directo porque el servidor está oculto detrás de firewalls, y otorgar acceso API al DNS a cada servicio interno crea una superficie de ataque significativa.

Los registros de Certificate Transparency son libros públicos que registran todos los certificados públicos emitidos. Si bien esto mejora la seguridad general de Internet, también permite a los atacantes descubrir nuevos subdominios y servicios. Las Autoridades de Certificación Privadas evitan estos registros, pero introducen sobrecarga operativa, ya que cada dispositivo y aplicación debe configurarse para confiar en el certificado raíz privado. Esto es particularmente difícil en entornos heterogéneos que utilizan contenedores Docker o lenguajes como Python que mantienen sus propios almacenes de certificados.

Por qué importa

Para los equipos que ejecutan software autoalojado, mantener certificados TLS válidos es crítico para la seguridad y el cumplimiento normativo. Los certificados vencidos o inválidos rompen integraciones, causan advertencias en el navegador y erosionan la confianza del usuario. Automatizar este proceso reduce la carga administrativa para los ingenieros DevOps, que de otro modo podrían depender de scripts de renovación manuales o certificados estáticos de larga duración. El patrón de proxy ACME permite a las organizaciones utilizar certificados públicos confiables para servicios internos sin comprometer la seguridad de la red abriendo puertos de entrada.

Además, separar el mecanismo de validación DNS del proveedor de DNS principal limita el radio de explosión de una posible filtración de credenciales. Si un servicio interno se ve comprometido, el atacante solo obtiene acceso al limitado servidor DNS ACME, no la capacidad de modificar registros DNS críticos como MX o A del dominio principal. Este enfoque de defensa en profundidad es esencial para empresas pequeñas y medianas que gestionan su propia infraestructura pero carecen de grandes equipos de seguridad.

Qué puedes hacer

• Evalúa si tus servicios internos pueden tolerar la sobrecarga operativa de gestionar un almacén de confianza de CA privada en todos los clientes.
• Despliega un proxy ACME, como el descrito con Step CA, para manejar las solicitudes de certificados desde redes internas.
• Configura una instancia dedicada de ACME DNS para manejar los registros de desafío, evitando la necesidad de exponer las claves API del DNS principal.
• Configura registros CNAME en tu zona DNS pública para delegar los subdominios _acme-challenge a tu servidor local ACME DNS.
• Implementa DNS de horizonte dividido utilizando herramientas como Unbound para asegurar que los clientes internos resuelvan los servicios correctamente mientras los validadores externos pueden alcanzar los registros de desafío.
• Monitoriza activamente las fechas de vencimiento de los certificados, ya que los sistemas automatizados aún pueden fallar debido a cambios de red o desviaciones de configuración.