TL;DR — Resumo Rápido

Configuração de certificado SSL wildcard Let's Encrypt com Certbot DNS challenge e Nginx para renovação automática de certificados *.dominio.com.

Gerenciar certificados SSL individuais para cada subdomínio se torna cansativo rapidamente. Um certificado SSL wildcard do Let’s Encrypt cobre todos os subdomínios sob um único domínio — *.example.com — com um único certificado. Este guia mostra como obter um certificado wildcard gratuito usando o Certbot com o DNS-01 challenge e configurar o Nginx para servir HTTPS em todos os seus subdomínios.

Pré-requisitos

  • Um servidor Linux (Ubuntu 22.04/24.04 ou Debian 12) com acesso root ou sudo
  • Nginx instalado e em execução
  • Um nome de domínio registrado com acesso ao DNS (capacidade de criar registros TXT ou acesso via API)
  • Porta 443 aberta no seu firewall
  • Familiaridade básica com comandos de terminal e configuração do Nginx

Entendendo Certificados Wildcard

Um certificado wildcard protege todos os subdomínios de primeiro nível de um domínio. Um certificado para *.example.com cobre www.example.com, api.example.com, staging.example.com e qualquer outro subdomínio — mas não o domínio raiz example.com em si, e não subdomínios de múltiplos níveis como dev.api.example.com.

O Let’s Encrypt exige o DNS-01 challenge para certificados wildcard. Diferente do HTTP-01 challenge (que coloca um arquivo no seu servidor web), o DNS-01 exige que você crie um registro TXT em _acme-challenge.example.com para comprovar a propriedade do domínio. Isso faz sentido: um wildcard cobre o domínio inteiro, então você precisa comprovar controle sobre o DNS do domínio, não apenas de um servidor específico.

Instalando o Certbot e Plugins DNS

Instale o Certbot e o plugin DNS correspondente ao seu provedor DNS. Para Cloudflare:

sudo apt update
sudo apt install certbot python3-certbot-nginx python3-certbot-dns-cloudflare

Para outros provedores, substitua o pacote do plugin:

# AWS Route 53
sudo apt install python3-certbot-dns-route53

# DigitalOcean
sudo apt install python3-certbot-dns-digitalocean

# Google Cloud DNS
sudo apt install python3-certbot-dns-google

Se a versão empacotada estiver desatualizada, instale via pip:

sudo pip3 install certbot certbot-nginx certbot-dns-cloudflare

Em seguida, crie o arquivo de credenciais para seu provedor DNS. Para Cloudflare, crie /etc/letsencrypt/cloudflare.ini:

# Cloudflare API token (recommended over Global API key)
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN

Restrinja as permissões — este arquivo contém suas credenciais de API:

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

O token API do Cloudflare precisa da permissão Zone:DNS:Edit com escopo para seu domínio. Crie um em Cloudflare Dashboard → My Profile → API Tokens.

Solicitando o Certificado Wildcard

Solicite um certificado que cubra tanto o wildcard quanto o domínio raiz:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.example.com" \
  -d "example.com" \
  --preferred-challenges dns-01 \
  --agree-tos \
  -m admin@example.com

O Certbot cria um registro DNS TXT, aguarda a propagação, valida e depois o remove. Os arquivos do certificado ficam em /etc/letsencrypt/live/example.com/:

  • fullchain.pem — o certificado mais a cadeia intermediária
  • privkey.pem — a chave privada
  • chain.pem — apenas o certificado intermediário

Para DNS manual (sem plugin), use --manual --preferred-challenges dns-01. O Certbot exibirá o valor do registro TXT para você adicionar manualmente. Isso funciona para solicitações pontuais, mas não permite renovação automática.

Configurando o Nginx

Crie ou atualize seu bloco de servidor Nginx para usar o certificado wildcard. Esta configuração gerencia HTTPS para qualquer subdomínio e redireciona HTTP para HTTPS:

# Redirect all HTTP to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com *.example.com;
    return 301 https://$host$request_uri;
}

# HTTPS server block for all subdomains
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com *.example.com;

    # Let's Encrypt wildcard certificate
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # SSL hardening
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # HSTS (optional, enable once confirmed working)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    root /var/www/example.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Teste e recarregue o Nginx:

sudo nginx -t
sudo systemctl reload nginx

Para roteamento específico por subdomínio, use blocos server separados que compartilham os mesmos caminhos de certificado, mas possuem diferentes diretivas server_name e root / proxy_pass.

Wildcard vs SAN vs Certificados Individuais

Recurso Wildcard (*.example.com) SAN (Multi-Domínio) Certificados Individuais
Cobre todos os subdomínios Sim (apenas primeiro nível) Apenas domínios listados Um domínio por certificado
Cobertura do domínio raiz Precisa ser adicionado explicitamente Sim, se listado Sim
Subdomínios de múltiplos níveis Não (*.*.example.com não suportado) Sim, se listados Sim
Número de certificados 1 1 1 por domínio
DNS challenge necessário Sim Não (HTTP-01 funciona) Não (HTTP-01 funciona)
Complexidade de renovação Precisa de plugin DNS ou passo manual Pode usar HTTP-01 Simples com HTTP-01
Ideal para Muitos subdomínios, subdomínios dinâmicos Conjunto fixo de domínios diferentes Servidores de domínio único

Renovação Automática

O Certbot configura um timer systemd automaticamente na maioria das distribuições. Verifique se está ativo:

sudo systemctl status certbot.timer

Se mostrar active (waiting), a renovação está agendada. Você também pode verificar:

sudo certbot renew --dry-run

Adicione um hook pós-renovação para recarregar o Nginx após cada renovação. Crie /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh:

#!/bin/bash
systemctl reload nginx

Torne-o executável:

sudo chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh

Se preferir cron em vez de systemd, adicione ao crontab do root:

# Renew certificates twice daily (Certbot skips if not due)
0 3,15 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Cenário do Mundo Real

Você está implantando uma plataforma de microsserviços com api.example.com para o backend, app.example.com para o frontend, staging.example.com para testes e docs.example.com para documentação. Sem um certificado wildcard, você precisaria executar o Certbot para cada subdomínio, gerenciar quatro certificados separados e adicionar novos comandos Certbot toda vez que um novo serviço é lançado. Com um certificado wildcard, você emite um único comando certbot certonly, aponta todos os blocos de servidor Nginx para os mesmos arquivos de certificado, e novos subdomínios funcionam imediatamente — sem necessidade de alterações no certificado. Quando a equipe criar monitoring.example.com no mês seguinte, simplesmente funciona.

Armadilhas e Casos Especiais

  • Domínio raiz não coberto: *.example.com NÃO corresponde a example.com. Sempre inclua ambos -d "*.example.com" -d "example.com" no seu comando Certbot.
  • Atrasos na propagação DNS: Alguns provedores DNS levam minutos para propagar registros TXT. O Certbot espera 10 segundos por padrão. Aumente com --dns-cloudflare-propagation-seconds 60 se a validação falhar.
  • Limites de taxa: O Let’s Encrypt permite 50 certificados por domínio registrado por semana e 5 certificados duplicados por semana. O wildcard conta como um certificado, então dificilmente você atingirá esses limites em uso normal. Use --staging para testes.
  • Subdomínios de múltiplos níveis: *.example.com NÃO cobre dev.api.example.com. Você precisa de um certificado separado ou um certificado SAN para subdomínios aninhados.
  • Logs de transparência de certificados: Todos os certificados do Let’s Encrypt são registrados publicamente. Os nomes dos seus subdomínios serão visíveis nos logs de CT. Isso é inevitável com qualquer certificado publicamente confiável.
  • Segurança das credenciais do plugin: Suas credenciais de API DNS concedem a capacidade de modificar registros DNS. Armazene-as em /etc/letsencrypt/ com permissões 600 e considere limitar o escopo dos tokens de API apenas ao domínio e permissões necessários.

Resumo

  • O Let’s Encrypt emite certificados wildcard gratuitos cobrindo *.seudominio.com, válidos por 90 dias
  • Certificados wildcard exigem DNS-01 challenge — use um plugin DNS do Certbot para seu provedor
  • Sempre solicite ambos *.example.com e example.com no mesmo certificado
  • Armazene as credenciais do plugin DNS com segurança usando chmod 600
  • Configure o Nginx com ssl_certificate apontando para o fullchain do Let’s Encrypt
  • Fortaleça o SSL com TLSv1.2+, OCSP stapling e cabeçalhos HSTS
  • Configure a renovação automática via timer systemd ou cron com um hook pós-renovação para recarregar o Nginx
  • Use a flag --staging durante testes para evitar limites de taxa

Artigos Relacionados