NGINX incorpora soporte nativo para el protocolo ACME

• NGINX publicó una versión preliminar con soporte nativo para el protocolo ACME, que automatiza la emisión y renovación de certificados SSL/TLS
• Mediante el nuevo módulo basado en Rust ngx_http_acme_module, ahora es posible solicitar, instalar y renovar certificados solo con la configuración de NGINX, sin herramientas externas
• Con esto, se reduce la dependencia de herramientas externas como Certbot y se mejora la seguridad y la independencia de la plataforma
• La versión inicial admite el desafío HTTP-01, y el soporte para TLS-ALPN y DNS-01 está previsto para más adelante
• Se espera que el soporte de ACME desempeñe un papel importante en la automatización de la seguridad no solo en la web, sino también en entornos de IoT y edge computing

---

Descripción general y cambios principales

• NGINX publicó una versión preliminar de su función de soporte para el protocolo ACME
• A través del nuevo módulo ngx_http_acme_module, fue diseñado para permitir manejar directamente desde la configuración de NGINX la solicitud, instalación y renovación de certificados
• Este soporte de ACME utiliza internamente el NGINX-Rust SDK y se ofrece en forma de módulo dinámico basado en Rust
• Tanto los usuarios de código abierto como los clientes empresariales de NGINX Plus pueden usar esta función
• Al reducir la dependencia de herramientas externas como Certbot, mejora la seguridad y la eficiencia de la gestión de certificados

Introducción al protocolo ACME

• El protocolo ACME (Automated Certificate Management Environment) es un protocolo de comunicación que automatiza la emisión, validación, renovación y revocación de certificados SSL/TLS
• Los clientes pueden gestionar directamente el ciclo de vida de los certificados mediante comunicación automatizada con una CA (Certificate Authority), sin intervención manual de terceros
• Fue desarrollado y publicado en 2015 por Internet Security Research Group (ISRG) como parte del proyecto Let’s Encrypt
• Antes de la aparición de ACME, el proceso de emisión de certificados era manual y tenía mayores costos y posibilidades de error
• La versión más reciente, ACMEv2, añade varias funciones, como métodos de validación y soporte para comodines, aumentando la flexibilidad y la seguridad

Flujo de automatización de certificados basado en ACME en NGINX

• En NGINX, la automatización del ciclo de vida de los certificados con el protocolo ACME se compone de las siguientes 4 etapas

• 1. Configuración del servidor ACME

  • Para activar la función ACME, es obligatorio especificar la URL del directorio del servidor ACME con acme_issuer
  • Si surge un problema con la emisión del certificado, también se pueden definir opcionalmente datos de contacto del cliente y la ruta para guardar los datos de estado

• 2. Asignación de memoria compartida (zone)

  • Con acme_shared_zone, se puede configurar adicionalmente una zona de memoria compartida para almacenar certificados, claves privadas y datos del desafío
  • El tamaño predeterminado es de 256K y puede ampliarse según sea necesario

• 3. Configuración del desafío (Challenge)

  • La versión preliminar actual solo admite el desafío HTTP-01, que se usa para verificar la propiedad del dominio
  • Para ello, se debe definir en la configuración de NGINX un listener en el puerto 80 y una configuración de respuesta 404 predeterminada
  • Más adelante se añadirá soporte para los desafíos TLS-ALPN y DNS-01

• 4. Emisión y renovación de certificados

  • Si se agrega la directiva acme_certificate al bloque del servidor, se puede automatizar la emisión y renovación de certificados TLS para ese dominio
  • Normalmente, el dominio objetivo para emitir el certificado se especifica con server_name
  • Las expresiones regulares y los comodines en server_name no son compatibles en la versión preliminar
  • Mediante las variables del módulo $acme_certificate y $acme_certificate_key, el certificado y la clave se vinculan automáticamente

Principales ventajas

• El protocolo ACME está en el centro del rápido crecimiento global del uso de HTTPS
• La gestión automatizada de certificados reduce drásticamente los costos del ciclo de vida de los certificados y los errores derivados del trabajo manual
• Al eliminar herramientas externas, se logra una reducción de la superficie de ataque y mayor portabilidad
• Impulsa la estandarización de la seguridad en distintos entornos

Planes a futuro

• Está previsto añadir soporte para los desafíos TLS-ALPN y DNS-01
• Se ampliarán las funciones con base en la retroalimentación de los usuarios
• A medida que se expanda la adopción de IoT, API y edge computing, se espera que ACME desempeñe un papel central en una infraestructura de seguridad automatizada cada vez más amplia
• El soporte nativo de ACME en NGINX servirá como base para convertir la seguridad web, la automatización y la escalabilidad en el estándar del futuro

Primeros pasos

• Los usuarios de código abierto pueden usar el módulo precompilado desde NGINX Linux packages
• Para los clientes empresariales de NGINX Plus, se ofrece como módulo dinámico con soporte de F5
• Consulta la documentación del módulo en NGINX Docs

[GN⁺]

Opiniones en Hacker News

• En la versión preview actual solo se soporta el desafío HTTP-01 para verificar la propiedad del dominio del cliente.
  El método DNS-01 sería mucho más útil para usuarios de nginx que no están expuestos públicamente (por ejemplo, al usar Nginx Proxy Manager). DNS-01 solo actualiza registros, así que siempre me ha parecido la opción más limpia. De verdad he estado esperando que agreguen esta función.
  • Pero necesitas tener sí o sí una API key de DNS, y muchos proveedores de DNS no ofrecen una API key separada por zona. Personalmente me gusta DNS-01, pero en la práctica puede requerir un compromiso poco ideal.
  • No hace falta esperar: Angie también lo soporta (Angie es un fork de nginx creado por desarrolladores originales de nginx que salieron de F5).
  • Lo frustrante del soporte ACME de Traefik es que solo puedes usar una API key por proveedor de DNS. Eso limita bastante cuando quieres restringir API keys por dominio o usas dominios de varias cuentas. Espero que nginx salga sin esa limitación.
  • En lo personal, en mi homelab uso dns01 con step-ca y Caddy. La experiencia ha sido muy satisfactoria.
  • Como soporta DNS-01 muy bien, también recomendaría cambiarse a Angie.
• Este es un cambio bastante grande. Caddy lo ha soportado desde hace tiempo, pero no todo el mundo prefiere Caddy. Esta actualización podría quitarle cuota a software como Traefik.
  • Me gusta especialmente lo limpia que es la sintaxis de Caddy. Ahora uso nginx (a través de nginx proxy manager) y Traefik, pero hace poco hice un proyecto con Caddy y fue muy agradable. Cuando tenga tiempo, me gustaría migrar mi entorno self-hosted a Caddy. O quizá usar algo como pangolin. Pangolin incluso ofrece una alternativa a Cloudflare Tunnels.
  • Hace poco me cambié por completo a Caddy. El detonante fue la respuesta poco activa de nginx frente al problema de desync en HTTP/1. No me gusta tener que esperar a que ocurra un problema, ni que nginx no dé una respuesta clara cuando un auditor pregunta al respecto.
    Caddy definitivamente es más fácil que nginx. Ofrece templates que cubren distintos servicios, pruebas e incluso servicios especiales para instituciones educativas, mejor logging, un manejo de certificados perfecto para mí y mejores métricas.
    Aun así, todavía estoy aprendiendo la parte de plugins. Caddy no tiene rate limiting, y por un bug de Power BI cierto usuario termina pidiendo imágenes 300 mil veces al día, así que eso sí me resulta incómodo.
  • Sí, definitivamente lo creo. En casa uso algo de Traefik, pero ahora parece que lo voy a reemplazar de inmediato.
• Es un cambio bienvenido. Dokku (yo soy maintainer) está usando un parche temporal con el plugin de letsencrypt, y los usuarios suelen encontrarse con problemas aleatorios. También pasa que nginx a veces se “queda colgado” durante un reload y no encuentra endpoints. Cuantas menos variables complejas haya, mejor.
  Pero va a pasar bastante tiempo antes de que esta función llegue a los repositorios estables de Ubuntu o Debian.
  Además, como todavía no soporta desafíos DNS (certificados wildcard), no parece que vaya a ayudar mucho a Dokku en el corto plazo.
  • ¡Hola! Qué gusto encontrarte por aquí.
    Probé Dokku (y de hecho lo sigo intentando), pero sentí que la barrera de entrada era bastante alta.
    Por ejemplo, en Coolify pude crear una GitHub App y conectar despliegues de inmediato, y también he tenido la experiencia de construir/desplegar contenedores con GitHub Actions.
    La documentación oficial de Dokku se siente más como una referencia; es como leer una enciclopedia: documentación oficial de inicialización de git en Dokku
    Siento que sería más útil una guía inmediata y clara para empezar a desplegar, como la de Coolify: ayuda de integración de GitHub en Coolify
    Me gustaría que Dokku tuviera una guía de entrada con apps OSS populares, objetivos paso a paso con hitos claros, y un tutorial que cubra de una sola vez el reverse proxy y varias apps populares en bare metal.
    Al final, el objetivo de usar Dokku no es Dokku en sí, sino llegar fácil y rápido al “estado que quiero” con Dokku.
    Lo ideal para mí sería un proceso sin fricción en el que puedas “hacer clic en un repo que te gusta y desplegarlo directamente en tu máquina”. Después de eso ya me metería a los detalles del backend.
• Buenas noticias. Para quien no lo conozca, ya existía una solución sencilla llamada dehydrated. Solo había que agregar unas líneas a la configuración de vhost:

    location ^~ /.well-known/acme-challenge/ {  
      alias ;  
    }  
  

  dehydrated ha sido desde hace mucho una herramienta ligera para automatizar renovaciones HTTP-01.
  • La función en sí es muy buena, pero es una pena que un proyecto del que dependen miles de personas siga sin sacar releases estables.
    Un software sin un release formal v1.0.0 puede cambiar su interfaz en cualquier momento y sin aviso. Una versión mayor 0 tarde o temprano se vuelve una trampa.
    Recomiendo exigir a los maintainers que publiquen una versión estable.
    dehydrated lleva 7 años en major version 0.
    También vale la pena ver 0ver.org:
    es una filosofía de versionado del tipo “si ya se usa en producción, ya debería ser 1.0.0”.
    Más detalles aquí.
• Hubo un pequeño descuido en este release: ngx_http_acme_module se incluyó en paquetes para varias distribuciones Linux, pero Debian stable quedó fuera.
  Según la lista oficial de paquetes de nginx, aparecen oldstable/oldoldstable, pero no Debian 13 Trixie, que salió hace 4 días.
  • Ahora mismo estamos trabajando en la subida del paquete para Trixie. Debería estar disponible esta semana. Como Debian 13 salió hace solo 4 días, hizo falta tiempo para preparar la infraestructura para el nuevo OS. (Trabajo en F5).
  • Supongo que probablemente fue un error del lado de Debian.
• Desde que conocí Caddy, ya no uso nginx. La experiencia de desarrollo es mucho mejor.
• El problema con las grandes corporaciones del open source es que siempre llegan tarde a entender e implementar la “innovación básica”.
  nginx recién ahora soporta algo que Caddy y Traefik ya hacían hace 5 años.
  Aun así, me parece un buen cambio. Ahora será más cómodo porque ya no hará falta ejecutar certbot manualmente.
  • De hecho, Caddy ya soportaba HTTPS automático de Let’s Encrypt en cierta medida en 2016, hace casi 10 años.
    Eso significa que nginx está incorporando esta función con unos 9 o 10 años de retraso.
• Personalmente, nunca sentí que fuera un problema que nginx solo sirviera contenido web y que certbot se encargara de las renovaciones.
  Siempre me ha parecido mejor la filosofía Unix de que cada cosa haga bien una sola tarea y se pueda combinar.
  Una “herramienta” que quiere hacerlo todo inevitablemente va a quedarse corta en alguna parte.
  • Configurarlo con certbot es una experiencia bastante engorrosa.
    Aunque certbot intente hacer la configuración automáticamente, fuera de los entornos básicos casi nunca funciona bien.
    Me da la impresión de que manejarlo todo directamente dentro de nginx termina siendo una mejor solución.
• Entonces entiendo que, con esta función, ya no hará falta instalar ni operar certbot, sino solo añadir unas líneas al archivo de configuración de nginx.
  También me pregunto si esto abre la puerta a usar fácilmente alternativas además de Let's Encrypt.
• Es un cambio prometedor.
  Caddy es realmente útil porque trae muchas funciones convenientes listas para usar.
  En lo personal, la razón por la que no he podido cambiarme por completo a Caddy es que necesito los módulos de rate limiting y geo de nginx.