DNS-01 Challenge

O DNS-01 Challenge valida o controle do domínio através de um registro TXT no DNS, sem necessidade de servidor web acessível.

Este é o único método que permite gerar certificados wildcard (*.domain.com), que funcionam automaticamente para todos os subdomínios do seu domínio - seja api.domain.com, blog.domain.com, admin.domain.com ou qualquer outro que você criar no futuro.

Como funciona?

Entendendo o fluxo:

O diagrama acima mostra a comunicação entre três componentes: o Cliente ACME (como Certbot ou acme.sh), o servidor da Let's Encrypt, e o Servidor DNS do seu domínio.

Solicitação inicial: O cliente ACME (rodando em qualquer máquina com acesso à internet) solicita um certificado para o domínio desejado
Desafio DNS: Let's Encrypt responde com um token único e instrui: "prove que você controla este domínio criando um registro TXT específico"
Criação do registro: O cliente ACME usa a API do seu provedor DNS (Cloudflare, Route53, etc.) para criar automaticamente o registro TXT _acme-challenge.domain.com com o token recebido
Verificação: Let's Encrypt consulta os servidores DNS públicos para verificar se o registro TXT existe e contém o token correto
Emissão: Após validação bem-sucedida, Let's Encrypt emite o certificado e o envia ao cliente ACME
Limpeza: O registro TXT pode ser removido após a emissão (o cliente ACME geralmente faz isso automaticamente)

Certbot roda separadamente

O cliente ACME (Certbot) não precisa rodar no mesmo servidor das suas aplicações. Ele apenas precisa de:

Acesso à internet para comunicar com Let's Encrypt
Credenciais da API do seu provedor DNS para criar/remover registros TXT
Um local para salvar os certificados gerados

Após a emissão, você distribui os certificados para os servidores que precisam deles (via rsync, NFS, Kubernetes Secrets, etc.).

Exemplo de registro DNS

# Registro TXT que precisa ser criado
_acme-challenge.domain.com. 300 IN TXT "gfj9Xq...Rg85nM"

Quando usar DNS-01?

Cenário	Por que usar DNS-01?
Certificados Wildcard	Único método que suporta `*.domain.com`
Servidores internos	Não requer exposição pública na porta 80
Múltiplos servidores	Um certificado para vários servidores
Porta 80 bloqueada	Firewall ou ISP bloqueia HTTP

Automação com DNS Providers

O maior desafio do DNS-01 é a automação. Criar registros TXT manualmente não escala. A solução é usar plugins que integram com a API do seu provedor DNS.

Certbot com plugins DNS

# Cloudflare
sudo apt install python3-certbot-dns-cloudflare
certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d "*.domain.com" -d domain.com

# Route53 (AWS)
sudo apt install python3-certbot-dns-route53
certbot certonly --dns-route53 -d "*.domain.com"

# Google Cloud DNS
sudo apt install python3-certbot-dns-google
certbot certonly --dns-google \
  --dns-google-credentials ~/.secrets/google.json \
  -d "*.domain.com"

Arquivo de credenciais (exemplo Cloudflare)

# ~/.secrets/cloudflare.ini
dns_cloudflare_api_token = seu_token_aqui

# Permissões seguras
chmod 600 ~/.secrets/cloudflare.ini

acme.sh (alternativa leve)

O acme.sh é um cliente ACME em shell script puro, mais leve que o Certbot.

# Exemplo: Certificado wildcard com Cloudflare
export CF_Token="seu_token"
acme.sh --issue --dns dns_cf -d "*.domain.com" -d domain.com

# Exemplo: Certificado wildcard com AWS Route53
export AWS_ACCESS_KEY_ID="xxx"
export AWS_SECRET_ACCESS_KEY="xxx"
acme.sh --issue --dns dns_aws -d "*.domain.com"

Segurança de Wildcards

Um certificado wildcard comprometido afeta todos os subdomínios. Considere certificados específicos para subdomínios críticos (api, admin, etc).

Propagação de DNS

O DNS-01 depende da propagação do registro TXT:

# Verificar se o registro propagou
dig TXT _acme-challenge.domain.com

# Tempo de propagação típico
# - Cloudflare: segundos
# - Route53: 60 segundos
# - Registradores tradicionais: até 48 horas

Problema comum: validação falha por propagação

Cenário: Certbot cria o registro TXT e imediatamente pede ao Let's Encrypt para verificar. Mas o Let's Encrypt consulta servidores DNS que ainda não receberam a atualização → validação falha.

Solução: Use --dns-cloudflare-propagation-seconds 60 para forçar o Certbot a esperar 60 segundos após criar o registro antes de solicitar verificação. Ajuste o valor conforme seu provedor DNS.

Vantagens e Desvantagens

Vantagens:

Suporta certificados wildcard
Funciona com servidores internos (não expostos à internet)
Não requer porta 80 aberta
Um certificado pode servir múltiplos servidores

Desvantagens:

Requer acesso à API do DNS provider
Propagação de DNS pode demorar
Mais complexo de configurar inicialmente
Credenciais de DNS são sensíveis

Distribuição para múltiplos servidores

Quando você tem várias máquinas em ambientes separados, existem diferentes estratégias para distribuir os certificados:

Por complexidade crescente

Cenário	Solução recomendada
Poucos servidores, mesma rede	rsync/scp com cron
Multi-cloud ou redes isoladas	HashiCorp Vault ou AWS Secrets Manager
Kubernetes	cert-manager (emite direto no cluster)
CDN/Load Balancer	Terminação TLS centralizada

1. rsync/scp (simples)

# No servidor com Certbot, após renovação
certbot renew --deploy-hook "rsync -avz /etc/letsencrypt/ user@server2:/etc/letsencrypt/"

2. HashiCorp Vault (multi-ambiente)

# Armazena certificado no Vault
vault kv put secret/certs/wildcard \
  cert=@/etc/letsencrypt/live/domain.com/fullchain.pem \
  key=@/etc/letsencrypt/live/domain.com/privkey.pem

# Cada servidor busca do Vault
vault kv get -field=cert secret/certs/wildcard > /etc/ssl/cert.pem

3. Kubernetes cert-manager

Para Kubernetes, o cert-manager é a solução padrão - ele emite certificados diretamente no cluster:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - dns01:
        cloudflare:
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token

4. Terminação TLS centralizada

A abordagem mais simples para múltiplos servidores: centralizar o TLS no load balancer.

Os servidores backend não precisam do certificado - a comunicação interna pode ser HTTP (em rede privada) ou mTLS.

Provedores DNS suportados

O Certbot e acme.sh suportam diversos provedores:

Populares: Cloudflare, AWS Route53, Google Cloud DNS, DigitalOcean
Registradores: GoDaddy, Namecheap, OVH, Gandi
Outros: Azure DNS, Linode, Vultr, DNSimple

Consulte a documentação do cliente ACME para a lista completa de plugins disponíveis.

Como funciona?​

Exemplo de registro DNS​

Quando usar DNS-01?​

Automação com DNS Providers​

Certbot com plugins DNS​

Arquivo de credenciais (exemplo Cloudflare)​

acme.sh (alternativa leve)​

Propagação de DNS​

Vantagens e Desvantagens​

Distribuição para múltiplos servidores​

Por complexidade crescente​

1. rsync/scp (simples)​

2. HashiCorp Vault (multi-ambiente)​

3. Kubernetes cert-manager​

4. Terminação TLS centralizada​

Provedores DNS suportados​