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

RecursoWildcard (*.example.com)SAN (Multi-Domínio)Certificados Individuais
Cobre todos os subdomíniosSim (apenas primeiro nível)Apenas domínios listadosUm domínio por certificado
Cobertura do domínio raizPrecisa ser adicionado explicitamenteSim, se listadoSim
Subdomínios de múltiplos níveisNão (*.*.example.com não suportado)Sim, se listadosSim
Número de certificados111 por domínio
DNS challenge necessárioSimNão (HTTP-01 funciona)Não (HTTP-01 funciona)
Complexidade de renovaçãoPrecisa de plugin DNS ou passo manualPode usar HTTP-01Simples com HTTP-01
Ideal paraMuitos subdomínios, subdomínios dinâmicosConjunto fixo de domínios diferentesServidores 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