Comparativo: Certbot vs acme.sh para automação de Let's Encrypt em ambientes Docker com múltiplos domínios — prós e contras

Por Kevin Marcondes · Publicado em 28/10/2026 · 8 min de leitura

comparativo: Certbot vs acme.sh para automação de Let's Encrypt em ambientes Docker com múltiplos domínios. Este guia explica quando cada cliente ACME funciona melhor, como integrar atrás de um proxy reverso e como organizar volumes, hooks e renovações em Compose. Incluímos arquiteturas típicas e exemplos práticos para sua decisão técnica.

Cenário: múltiplos containers e domínios no Docker

Ambientes com vários serviços e domínios exigem renovação automática, zero downtime e storage consistente dos certificados. O cliente ACME precisa funcionar por trás de proxies, lidar com SAN (vários -d) e, muitas vezes, wildcard via DNS-01. Você pode centralizar a emissão em um container e compartilhar certificados por volume, ou emitir por serviço conforme a topologia.

Se você está começando com certificados, veja conceitos gerais em como gerar SSL grátis com Let's Encrypt.

• Alvos típicos: *.dominio.com e domínios adicionais em SAN.
• Renovação automática sem interromper Nginx/HAProxy/Traefik.
• Armazenamento seguro das chaves privadas e backup do account key.
• Compatibilidade com HTTP-01 atrás de proxy e DNS-01 no provedor.

Arquiteturas de automação no Docker

Há dois padrões comuns para integrar Certbot ou acme.sh em Docker. A escolha muda como você monta volumes, atualiza certificados e recarrega processos. Defina um único “ponto de emissão” e um plano de reload controlado para evitar janelas sem TLS.

• Emissor centralizado: um container gerencia todos os domínios, salva em volume dedicado e demais serviços montam os certificados em modo somente leitura.
• Por serviço: cada app contém o cliente ACME e emite seus próprios certificados, útil para times independentes, porém com mais credenciais e pontos de falha.
• Em HTTP-01, use webroot compartilhado com o proxy. Em DNS-01, injete tokens do provedor DNS no emissor.

Recursos lado a lado: o que muda na prática

Abaixo, uma visão comparativa dos critérios que mais pesam em ambientes Docker com muitos domínios e necessidade de automação contínua.

Automação de múltiplos domínios e wildcard

Para reduzir o número de certificados, combine domínios com SAN. Isso simplifica gestão, mas um erro afeta mais hosts. Prefira wildcard (*.dominio.com) quando subdomínios mudam com frequência e você controla o DNS-01. Em Docker, mantenha um volume exclusivo para certificados e permissões restritas.

Certbot e acme.sh lidam bem com SAN e wildcard. O acme.sh costuma ser direto ao configurar DNS-01 com tokens de provedores. Já o Certbot brilha quando você reutiliza webroot e já possui automações de reload em place.

• Consolide SAN quando a cadência de mudanças for similar entre domínios.
• Wildcard reduz reemissões em novos subdomínios.
• Separe certificados por domínio crítico para isolar falhas.
• Centralize o armazenamento e versionamento de configurações.

HTTP-01 vs DNS-01 atrás de proxy reverso

Em HTTP-01, o tráfego para /.well-known/acme-challenge deve chegar ao emissor ou a um webroot compartilhado. Isso exige configuração no proxy reverso. Em DNS-01, o desafio é validado por registros TXT, ideal para wildcard e clusters sem porta 80 exposta.

Se você usa proxies modernos com ACME embutido, compare as abordagens em Comparativo: Traefik vs Caddy. Para um exemplo com balanceador tradicional, veja o tutorial de HAProxy com Let's Encrypt. E, para escolher proxy, consulte Traefik vs Nginx como reverse proxy.

• HTTP-01: simples com webroot, depende de roteamento correto no proxy.
• DNS-01: ideal para wildcard e multi-host, requer tokens do provedor DNS.
• Em ambos, planeje o reload sem interrupção do serviço.

Operação contínua, segurança e performance

Minimize escopo de credenciais e monte certificados em modo somente leitura. Prefira ECDSA P-256 por chaves menores e handshakes mais rápidos, quando compatível com clientes. Projete o reload do proxy (SIGHUP ou endpoint de reload) para evitar reinícios completos.

Implemente modo staging ao validar automações para não atingir rate limits. Faça backup do account key e dos diretórios de certificados. Nunca exponha tokens DNS em repositórios; use secrets e controles de acesso por ambiente.

Critérios rápidos de escolha em Docker:

- Prefira Certbot quando você depende de webroot/HTTP-01, já possui automações com hooks do Certbot, ou quer manter alinhamento com o cliente oficial.

- Prefira acme.sh quando precisa de DNS-01/wildcard em muitos provedores, imagens leves e scripts simples de shell para integrar no CI/CD.

Exemplo Compose: Certbot com webroot compartilhado (HTTP-01)

Estrutura mínima usando webroot compartilhado com Nginx. O Certbot grava o desafio no volume, o Nginx o serve em /.well-known/acme-challenge. Após emitir, os certificados ficam em um volume dedicado. Revise permissões e planeje o reload do Nginx.

version: '3.8'
services:
  nginx:
    image: nginx:alpine
    volumes:
      - challenge:/var/www/certbot:ro
      - certs:/etc/letsencrypt:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    ports:
      - "80:80"
      - "443:443"

  certbot:
    image: certbot/certbot
    volumes:
      - challenge:/var/www/certbot
      - certs:/etc/letsencrypt
    entrypoint: ["sh","-c"]
    command: >-
      "certbot certonly --webroot -w /var/www/certbot \
      -d example.com -d www.example.com \
      --email [email protected] --agree-tos --no-eff-email --non-interactive && \
      echo 'Emissão concluída. Configure um mecanismo de reload do Nginx.'"

volumes:
  challenge:
  certs:

Exemplo Compose: acme.sh com DNS-01 e vários domínios

Fluxo típico para wildcard via DNS-01. O acme.sh escreve certificados em um volume dedicado. Os serviços consumidores montam esse volume como somente leitura. Armazene tokens DNS em Docker secrets ou variáveis protegidas e ative staging antes de ir a produção.

version: '3.8'
services:
  acme:
    image: your-acme-sh-image
    environment:
      - ACME_SERVER=letsencrypt
      # Exemplo Cloudflare (use secrets na prática):
      - CF_Token=${CF_TOKEN}
      - CF_Zone_ID=${CF_ZONE_ID}
    volumes:
      - certs:/acme
    entrypoint: ["sh","-c"]
    command: >-
      "acme.sh --issue --dns dns_cf \
      -d example.com -d *.example.com \
      --keylength ec-256 --server letsencrypt && \
      acme.sh --install-cert -d example.com \
      --fullchain-file /acme/example.com/fullchain.pem \
      --key-file /acme/example.com/privkey.pem && \
      echo 'Certificados prontos no volume. Programe renovações.'"

volumes:
  certs:

Perguntas frequentes

Qual é melhor para múltiplos domínios e wildcard em Docker?

Ambos funcionam bem. Para DNS-01 e wildcard, acme.sh costuma ser mais direto pela integração com diversos provedores via variáveis de ambiente. Para HTTP-01 com webroot já estabelecido no proxy, o Certbot é uma escolha sólida e bem documentada.

Consigo usar com Traefik, Nginx ou HAProxy atrás do Docker?

Sim. Em HTTP-01, direcione /.well-known/acme-challenge ao webroot compartilhado ou ao emissor. Em DNS-01, não há tráfego HTTP, basta ter acesso à API do DNS. Programe um reload limpo do proxy após a renovação dos certificados.

Como evitar atingir rate limits do Let's Encrypt durante testes?

Use o modo staging em ambos os clientes. Ele permite validar o fluxo de emissão e renovação sem consumir limites de produção. Ao finalizar os testes, mude para o servidor de produção e mantenha janelas de renovação com folga.

Onde armazenar certificados e como recarregar sem downtime?

Armazene em um volume dedicado, montado como somente leitura para os serviços que consomem o certificado. Realize reload por sinal ou endpoint do proxy (ex.: SIGHUP no Nginx) após a renovação. Evite reiniciar containers desnecessariamente.

É seguro guardar tokens do provedor DNS em variáveis de ambiente?

É comum, mas exige cuidado. Prefira Docker secrets ou stores de segredos do seu orquestrador. Restrinja escopo e permissões no provedor DNS, rotacione periodicamente e nunca commite segredos no repositório.

Veja também

• Comparativo: ZFS vs LVM+LUKS em VPS com bancos de dados — snapshots, desempenho e recuperação após falha
• Análise prática — comparativo: Nginx Unit vs PHP‑FPM vs RoadRunner para executar monólitos PHP em containers — latência, throughput e consumo de memória
• Comparativo: Flyway vs Liquibase vs Sqitch para versionamento de banco de dados em projetos PHP/Laravel
• nftables vs iptables no Ubuntu 22.04: qual usar e exemplos práticos