NGINX introduz suporte nativo ao protocolo ACME

• O NGINX lançou uma versão preview com suporte nativo ao protocolo ACME, que automatiza a emissão e a renovação de certificados SSL/TLS
• Por meio do novo módulo baseado em Rust ngx_http_acme_module, agora é possível solicitar, instalar e renovar certificados apenas com a configuração do NGINX, sem ferramentas externas
• Com isso, reduz-se a dependência de ferramentas externas como o Certbot, aumentando a segurança e a independência de plataforma
• A versão inicial oferece suporte ao desafio HTTP-01, e o suporte a TLS-ALPN e DNS-01 está planejado para o futuro
• Espera-se que o suporte a ACME desempenhe um papel importante na automação de segurança não apenas na web, mas também em ambientes de IoT e edge computing

---

Visão geral e principais mudanças

• O NGINX lançou uma versão preview do suporte ao protocolo ACME
• Com o novo módulo ngx_http_acme_module, ele foi projetado para permitir que solicitações, instalação e renovação de certificados sejam tratadas diretamente na configuração do NGINX
• Esse suporte a ACME utiliza internamente o NGINX-Rust SDK e é fornecido na forma de um módulo dinâmico baseado em Rust
• Tanto usuários de código aberto quanto clientes corporativos do NGINX Plus podem usar esse recurso
• Ao reduzir a dependência de ferramentas externas como o Certbot, aumenta-se a segurança e a eficiência do gerenciamento de certificados

Introdução ao protocolo ACME

• O protocolo ACME (Automated Certificate Management Environment) é um protocolo de comunicação que automatiza a emissão, validação, renovação e revogação de certificados SSL/TLS
• O cliente pode gerenciar diretamente o ciclo de vida do certificado por meio de comunicação automatizada com a CA (Certificate Authority), sem intervenção manual de intermediários
• Foi desenvolvido e lançado em 2015 pelo Internet Security Research Group (ISRG) no projeto Let’s Encrypt
• Antes do surgimento do ACME, o processo de emissão de certificados era manual e tinha custos mais altos e maior probabilidade de erros
• O ACMEv2 mais recente adicionou vários recursos, como métodos de autenticação e suporte a wildcard, aumentando a flexibilidade e a segurança

Fluxo de automação de certificados baseado em ACME no NGINX

• No NGINX, a automação do ciclo de vida de certificados com o protocolo ACME ocorre nas 4 etapas abaixo

• 1. Configuração do servidor ACME

  • Para ativar o recurso ACME, é obrigatório especificar a URL de diretório do servidor ACME com acme_issuer
  • Em caso de emissão de certificado, também é possível definir opcionalmente informações de contato do cliente, caminho para armazenamento de dados de estado e outros itens

• 2. Alocação de memória compartilhada (zone)

  • Com acme_shared_zone, é possível configurar adicionalmente uma zone de memória compartilhada para armazenar certificados, chaves privadas e dados de desafio
  • O tamanho padrão é 256K, podendo ser ampliado conforme a necessidade

• 3. Configuração do desafio (Challenge)

  • A versão preview atual oferece suporte apenas ao desafio HTTP-01, usado para verificar a propriedade do domínio
  • Para isso, é necessário definir na configuração do NGINX um listener na porta 80 e uma configuração padrão de resposta 404
  • Futuramente, haverá suporte aos desafios TLS-ALPN e DNS-01

• 4. Emissão e renovação de certificados

  • Ao adicionar a diretiva acme_certificate ao bloco de servidor, é possível automatizar a emissão/renovação de certificados TLS para o domínio correspondente
  • Normalmente, o domínio alvo da emissão do certificado é especificado com server_name
  • Expressões regulares e wildcards em server_name não são suportados na versão preview
  • As variáveis do módulo $acme_certificate e $acme_certificate_key vinculam automaticamente o certificado e a chave

Principais vantagens

• O protocolo ACME está no centro do rápido crescimento do uso de HTTPS no mundo
• Com o gerenciamento automatizado de certificados, os custos de gestão do ciclo de vida dos certificados e os erros causados por trabalho manual são reduzidos de forma significativa
• A remoção de ferramentas externas reduz a superfície de ataque e garante portabilidade
• Promove a padronização da segurança em diversos ambientes

Planos futuros

• Está previsto adicionar suporte aos desafios TLS-ALPN e DNS-01
• Expansão de recursos com base no feedback dos usuários
• Com a ampliação da adoção de IoT, APIs e edge computing, espera-se que o ACME passe a desempenhar um papel central em uma gama ainda maior de infraestruturas automatizadas de segurança no futuro
• O suporte nativo a ACME no NGINX deve servir de base para transformar segurança web, automação e escalabilidade em um padrão do futuro

Primeiros passos

• Usuários de código aberto podem usar o módulo pré-compilado em NGINX Linux packages
• Clientes corporativos do NGINX Plus recebem o recurso na forma de módulo dinâmico com suporte da F5
• Consulte a documentação do módulo em NGINX Docs

[GN⁺]

Comentários no Hacker News

• Na versão preview atual, só há suporte ao desafio HTTP-01 para verificar a propriedade do domínio do cliente.
  O método DNS-01 é uma funcionalidade bem mais relevante para usuários de nginx que não ficam publicamente expostos (por exemplo, ao usar Nginx Proxy Manager). Sempre achei o DNS-01 a solução mais limpa, já que basta atualizar os registros. Estou realmente esperando por esse recurso.
  • Mas é preciso necessariamente ter uma chave de API do DNS, e muitos provedores de DNS não oferecem chaves separadas por zona. Pessoalmente gosto do DNS-01, mas na prática pode ser necessário algum meio-termo menos ideal.
  • Não precisa esperar: o Angie também oferece suporte (o Angie é um fork do nginx criado pelos desenvolvedores originais do nginx depois que saíram da F5).
  • O ponto fraco do ACME no Traefik é que só dá para usar uma chave de API por provedor DNS. Isso limita bastante quando você quer restringir a chave por domínio ou usa domínios de várias contas. Espero que o nginx venha sem essa limitação.
  • No meu homelab, uso DNS-01 com step-ca e caddy. A experiência tem sido muito satisfatória.
  • Como o suporte a DNS-01 é muito bom, também recomendo migrar para o Angie.
• Isso é uma mudança bem grande. O Caddy já oferece isso há bastante tempo, mas nem todo mundo prefere o caddy. Esse upgrade pode acabar tirando participação de softwares como o Traefik.
  • Gosto especialmente da sintaxe limpa do Caddy. Hoje uso nginx (via nginx proxy manager) e Traefik, mas recentemente fiz alguns projetos com Caddy e foi uma experiência muito agradável. Quando tiver tempo, quero migrar meu ambiente self-hosted para Caddy. Ou talvez usar algo como pangolin. O pangolin também oferece uma alternativa ao Cloudflare Tunnels.
  • Recentemente migrei de vez para o caddy. O fator decisivo foi a postura pouco proativa do nginx em relação ao problema de desync no HTTP/1. Não gosto da ideia de esperar até surgir um problema, ou de ter auditores fazendo perguntas sem o nginx dar uma resposta clara.
    O Caddy é claramente mais fácil que o nginx. Ele oferece templates que cobrem vários serviços, testes e até serviços especiais para instituições de ensino, além de logs melhores, um gerenciamento de certificados perfeito para mim e métricas superiores.
    Ainda estou estudando a parte de plugins, mas o caddy não tem rate limiting, e por causa de um bug no Power BI, um determinado usuário acaba requisitando imagens 300 mil vezes por dia, o que é bem inconveniente.
  • Também acho isso. Em casa uso um pouco de traefik, mas agora acho que vou substituí-lo imediatamente.
• É uma mudança bem-vinda. O Dokku (do qual sou mantenedor) usa um plugin do letsencrypt como gambiarra temporária, e os usuários acabam enfrentando vários problemas aleatórios. Às vezes o nginx também “trava” durante o reload e não encontra os endpoints. Quanto menos variáveis complexas houver, melhor.
  Mas vai levar um bom tempo até esse recurso aparecer nos repositórios stable do Ubuntu ou Debian.
  Além disso, ainda não há suporte a desafio DNS (certificados wildcard), então no curto prazo isso provavelmente não ajuda muito o Dokku.
  • Olá! Que legal encontrar você por aqui.
    Estou experimentando o dokku (ainda estou), mas senti que a barreira de entrada é relativamente alta.
    Por exemplo, no Coolify foi possível integrar o deploy imediatamente só criando um GitHub App, e também já tive experiência construindo e implantando containers com GH Actions.
    A documentação oficial do dokku parece mais uma referência, dá até a sensação de estar lendo uma enciclopédia: documentação oficial sobre inicialização do git no dokku
    Senti falta de um guia inicial mais direto, no estilo “comece por aqui”, como o do Coolify: ajuda de integração com GitHub no Coolify
    Seria ótimo se o Dokku tivesse um guia de introdução com metas e conclusão por etapas, instalação de apps OSS populares e um tutorial que cobrisse de uma vez proxy reverso e vários aplicativos populares em ambiente bare metal.
    No fim das contas, o objetivo de usar o Dokku não é o Dokku em si, mas chegar de forma fácil e rápida ao “estado desejado” com a ajuda dele.
    No final, eu quero um processo sem dor em que eu possa “clicar em um repositório de que gosto e implantá-lo direto na minha máquina”. Depois disso, aí sim quero explorar os detalhes internos.
• Boa notícia. Para quem não conhece, já existia uma solução simples chamada dehydrated. Bastava adicionar algumas linhas na configuração do vhost:

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

  O dehydrated é uma ferramenta leve usada há muito tempo para automatizar renovações via HTTP-01.
  • A funcionalidade em si é realmente ótima, mas é uma pena que um projeto do qual milhares de pessoas dependem continue sem lançar uma versão Stable.
    Software sem lançamento oficial v1.0.0 pode mudar a interface a qualquer momento e sem aviso. Versão major 0 acaba virando armadilha em algum momento.
    Recomendo cobrar dos mantenedores um lançamento estável.
    O dehydrated está na major version 0 há 7 anos.
    Vale a pena ver também o 0ver.org:
    é uma filosofia de versionamento na linha de “se está em produção, já deveria ser 1.0.0”.
    Mais detalhes aqui.
• Houve um pequeno deslize nesta release: o ngx_http_acme_module foi incluído em pacotes de várias distribuições Linux, mas o Debian stable ficou de fora.
  De acordo com a lista oficial de pacotes do nginx, há pacotes para oldstable/oldoldstable, mas não para o Debian 13 Trixie, lançado há 4 dias.
  • Neste momento estamos trabalhando no upload do pacote para o Trixie. Deve entrar ainda esta semana. Como o Debian 13 foi lançado há apenas 4 dias, precisávamos de tempo para configurar a infraestrutura para o novo sistema operacional. (Trabalho na F5.)
  • Acho que isso provavelmente foi um erro do lado do Debian.
• Desde que conheci o Caddy, não uso mais nginx. A experiência de desenvolvimento é muito melhor.
• O problema das grandes potências do open source é que elas sempre demoram para entender e implementar “inovação básica”.
  O nginx só agora está passando a oferecer algo que o Caddy e o Traefik já faziam há 5 anos.
  Claro, ainda acho que é uma mudança positiva. Pelo menos agora fica mais cômodo, sem precisar rodar o certbot manualmente.
  • Na prática, o Caddy já oferecia algum nível de HTTPS automático do Let’s Encrypt quase 10 anos atrás, em 2016.
    O nginx está introduzindo isso com quase 9 ou 10 anos de atraso.
• Pessoalmente, nunca senti que havia problema em deixar o nginx apenas servindo conteúdo web e o certbot cuidando da renovação.
  Sempre achei melhor a filosofia Unix de fazer uma coisa bem e compor ferramentas.
  Ferramentas que tentam fazer tudo inevitavelmente acabam ficando aquém em alguma área.
  • Configurar com certbot é uma experiência bem trabalhosa.
    Mesmo quando o certbot tenta configurar tudo automaticamente, ele costuma não funcionar bem fora dos ambientes mais padrão.
    Fazer tudo diretamente dentro do nginx parece até uma solução melhor.
• Então entendo que, com esse recurso, bastaria adicionar algumas linhas ao arquivo de configuração do nginx para não precisar mais instalar/operar o certbot.
  Também fiquei curioso se isso abre caminho para usar facilmente alternativas ao Let's Encrypt.
• É uma mudança animadora.
  O Caddy é realmente útil porque já traz muitas conveniências prontas para uso.
  Pessoalmente, o motivo de eu ainda não ter migrado completamente para o Caddy é a necessidade dos módulos de rate limiting e geo do nginx.