O que é um certificado Wildcard

Definição

Um certificado wildcard (certificado curinga) é um certificado TLS/SSL que cobre todos os subdomínios de primeiro nível de um domínio, usando um único caractere curinga * no Common Name (CN) ou no Subject Alternative Name (SAN).

Exemplo: um certificado emitido para *.exemplo.com é válido para:

exemplo.com (em muitos emissores, o root também precisa ser incluído explicitamente)
www.exemplo.com
api.exemplo.com
app.exemplo.com
qualquer-coisa.exemplo.com

Não cobre:

sub.sub.exemplo.com (apenas um nível de wildcard)
outro-dominio.com

Sintaxe e padrão

O wildcard é representado pelo asterisco * no leftmost label do nome DNS (RFC 6125, RFC 2818). A CA emite o certificado para um FQDN como:

*.exemplo.com

Em certificados modernos, os nomes são listados em Subject Alternative Names (SAN). Um certificado wildcard típico pode ter:

*.exemplo.com
exemplo.com (domínio raiz, se a CA incluir)

O CN legado pode conter *.exemplo.com, mas navegadores e bibliotecas usam SAN para validação. Sem o domínio raiz no SAN, https://exemplo.com pode não ser considerada coberta pelo wildcard em algumas implementações.

Quando usar

Cenário	Motivo
Múltiplos subdomínios	Um único certificado para `api`, `app`, `admin`, `staging`, etc., sem emitir um cert por subdomínio.
Subdomínios dinâmicos	Ex.: SaaS onde cada cliente tem `cliente.seudominio.com`; um wildcard cobre todos.
Ambientes (dev/staging)	`dev.empresa.com`, `staging.empresa.com` com o mesmo cert.
CDN / multi-origin	Diversos hostnames sob o mesmo domínio apontando para a mesma infra.

Reduz custo operacional (menos certificados para renovar) e simplifica deploy quando há muitos hostnames.

Limitações técnicas

Apenas um nível
*.exemplo.com cobre a.exemplo.com, não a.b.exemplo.com. Para esse caso é necessário certificado multi-SAN ou outro wildcard para *.b.exemplo.com.
Não cobre o root por padrão
Muitas CAs exigem que você inclua explicitamente exemplo.com (sem wildcard) no pedido; caso contrário, https://exemplo.com pode falhar na validação.
Validação do domínio
Para wildcard, a CA normalmente exige validação DNS: você cria um registro TXT (ou CNAME) no domínio para provar controle. Validação por arquivo HTTP não funciona para *, pois a CA não sabe em qual URL colocar o arquivo.
EV (Extended Validation)
Certificados EV wildcard existem, mas são raros e caros; a maioria dos wildcards é OV (Organization Validation) ou DV (Domain Validation).

Segurança e riscos

Comprometimento: Se a chave privada do wildcard vazar, todos os subdomínios cobertos ficam comprometidos. Por isso:
- Armazenar a chave em HSM ou cofre (ex.: AWS ACM, HashiCorp Vault).
- Restringir acesso à chave e rotação.
Renovação: Wildcards costumam ter validade de até 1 ano (política das CAs). Automatize renovação (ex.: certbot, ACM, Let’s Encrypt) para evitar expiração.
Auditoria: Saber onde o wildcard está instalado é mais difícil do que com certs por hostname; mantenha inventário.

Exemplo prático: Let’s Encrypt wildcard

Com certbot e validação DNS (plugin do seu provedor DNS):

# Validação DNS (obrigatória para wildcard)
certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.exemplo.com" \
  -d "exemplo.com"

Você recebe um desafio TXT para criar em _acme-challenge.exemplo.com. Após a CA validar, o certificado é emitido para *.exemplo.com e (se pedido) exemplo.com.

Resumo

Aspecto	Detalhe
O que é	Certificado TLS que cobre todos os subdomínios de um nível (`*.dominio.com`).
Vantagem	Um cert para muitos hostnames; útil em SaaS, APIs, ambientes.
Limitação	Só um nível de wildcard; validação via DNS; cuidado com vazamento da chave.
Prática	Incluir domínio raiz no SAN quando necessário; automatizar renovação e proteger a chave privada.

Usar wildcard é uma decisão de operação e risco: facilita gestão, mas exige controles fortes sobre onde a chave é usada e como é armazenada.