Um Certificado Wildcard é um certificado SSL/TLS que, com uma única emissão, protege o domínio principal e todos os subdomínios de primeiro nível por meio de um curinga no formato *.dominio.com. Em arquiteturas modernas com SaaS multi-tenant, ambientes de staging dinâmico e APIs versionadas, essa abordagem elimina a necessidade de gerenciar dezenas de certificados individuais. Segundo a Cloudflare (2024), equipes de infraestrutura reduzem o esforço operacional em até 80% ao migrar para Wildcard em domínios com muitos subdomínios ativos.
TL;DR
- O que é: certificado SSL/TLS com curinga que cobre o domínio principal e todos os subdomínios de primeiro nível.
- Por que importa: consolida a gestão de certificados em um único arquivo, reduz custo operacional e simplifica renovações.
- Quando usar: SaaS multi-tenant, APIs com múltiplas versões, staging dinâmico e qualquer infraestrutura com criação frequente de subdomínios.
Como funciona um Certificado Wildcard?
Certificado Wildcard é emitido com o campo Common Name (CN) ou Subject Alternative Name (SAN) no formato *.dominio.com, onde o asterisco atua como curinga para qualquer subdomínio de primeiro nível. Durante o handshake TLS, o navegador compara o hostname acessado com o padrão do certificado. Segundo a RFC 6125 (2011), o curinga só é válido no label mais à esquerda. Isso significa que *.shiftmind.com.br cobre app.shiftmind.com.br e api.shiftmind.com.br, mas NÃO cobre deep.sub.shiftmind.com.br nem o próprio apex shiftmind.com.br (sem o domínio raiz incluído explicitamente no SAN durante a emissão).
Quando usar um Wildcard
O Wildcard faz sentido em cenários específicos. Em SaaS multi-tenant, cada cliente recebe um subdomínio dedicado (cliente1.saas.com.br, cliente2.saas.com.br) e o provisionamento precisa ser automático. Em ambientes de staging e dev, times criam subdomínios temporários para testes de pull request (pr-123.staging.app.com) sem esperar emissão manual. APIs com versionamento (v1.api.com, v2.api.com) também se beneficiam. Segundo a Let’s Encrypt (2024), aproximadamente 15% dos certificados ativos emitidos pela CA já utilizam curinga.
Wildcard vs SAN/UCC vs Single Domain
| Tipo | Cobre | Limite | Custo típico | Caso de uso |
|---|---|---|---|---|
| Single Domain | 1 hostname específico | 1 nome | Grátis a US$ 50/ano | Site institucional simples |
| SAN/UCC | Múltiplos domínios distintos | Até 100 SANs | US$ 100 a US$ 500/ano | Exchange, múltiplas marcas |
| Wildcard | *.dominio.com (1 nível) | Subdomínios ilimitados | Grátis a US$ 300/ano | SaaS, staging, APIs |
| Multi-Domain Wildcard | Vários wildcards em 1 certificado | Combina SAN + curinga | US$ 500 a US$ 1.500/ano | Grupos com várias marcas |
Validação DNS-01: a única opção
Wildcard não aceita validação HTTP-01 nem TLS-ALPN-01 — apenas o desafio DNS-01 do protocolo ACME. Segundo a RFC 8555 (2019), que define o ACME v2, o DNS-01 exige a criação de um registro TXT em _acme-challenge.dominio.com com um token fornecido pela CA. A regra existe porque validar HTTP-01 em um subdomínio arbitrário não prova controle sobre todos os subdomínios cobertos pelo curinga. Na prática, isso significa que o processo exige acesso programático ao DNS do domínio, geralmente via API do provedor.
Emissão com Let’s Encrypt grátis
Desde março de 2018, a Let’s Encrypt emite Wildcard gratuitamente via ACME v2. Segundo a própria Let’s Encrypt (2024), mais de 400 milhões de domínios ativos usam a CA. As ferramentas mais comuns são:
- Certbot com plugins DNS (Cloudflare, Route53, Google Cloud DNS, DigitalOcean, GoDaddy, Linode).
- acme.sh, um shell script leve que suporta mais de 50 provedores DNS.
- Caddy, servidor web com emissão automática integrada.
- ZeroSSL, alternativa com interface web amigável e também compatível com ACME.
Exemplos práticos B2B brasileiros
A seguir, três cenários reais do mercado brasileiro:
- SaaS de ERP: uma plataforma com 300 clientes PJ usa *.cliente.erp.com.br para provisionar subdomínios automaticamente no onboarding. Antes do Wildcard, cada cliente demorava 15 minutos para ter SSL ativo; depois, o provisionamento virou instantâneo.
- Agência digital: *.staging.agencia.com.br cobre todos os ambientes de homologação. Um único Certbot roda em container Docker e renova mais de 50 ambientes semanalmente sem intervenção humana.
- App mobile B2B: *.api.app.com.br protege endpoints versionados (v1, v2, v3) e serviços auxiliares (auth, cdn, uploads), com rotação automática via Traefik em cluster Kubernetes.
Automação de renovação do Wildcard
Certificados Let’s Encrypt duram 90 dias, portanto a automação é obrigatória. Em servidores Linux, o padrão é um cron rodando certbot renew --quiet duas vezes ao dia, combinado com hooks de restart (--deploy-hook 'systemctl reload nginx'). Em infraestruturas conteinerizadas, Traefik e Caddy fazem a renovação sem intervenção, armazenando certificados em volume persistente. Segundo a Mozilla (2024), 92% das falhas de SSL em produção acontecem por certificados expirados — a automação elimina esse risco e é considerada obrigatória pelo CA/B Forum Baseline Requirements.
Riscos de segurança do Wildcard
Se a chave privada de um Wildcard vazar, TODOS os subdomínios cobertos ficam comprometidos simultaneamente. O blast radius é maior que o de certificados individuais. Segundo o CA/B Forum Baseline Requirements (2024), CAs recomendam não usar Wildcard em domínios públicos de alto valor sem controles compensatórios. Mitigações recomendadas: separar certificados por sensibilidade (*.cliente.com separado de *.interno.com), armazenar chaves privadas em HSM ou cofres como HashiCorp Vault e monitorar o Certificate Transparency Log para detectar emissões não autorizadas em tempo real.
Wildcard vs certificados individuais
O trade-off principal é operacional vs blast radius. Com Wildcard, você renova um certificado e protege N subdomínios. Com certificados individuais, cada subdomínio tem chave privada isolada — se um vazar, apenas aquele hostname é afetado. Para 5 ou menos subdomínios estáticos, certificados individuais com Let’s Encrypt são mais seguros. Acima de 10 subdomínios ou com criação dinâmica, Wildcard compensa pela eficiência operacional e menor chance de certificado expirado por falta de automação.
CAs populares que emitem Wildcard
Opções no mercado em 2026:
- Let’s Encrypt: grátis, DV (Domain Validation), 90 dias, ACME v2.
- ZeroSSL: grátis para uso pessoal, DV, interface web, compatível com ACME.
- DigiCert: paga, OV e EV disponíveis, suporte enterprise 24/7.
- Sectigo (ex-Comodo): paga, OV e EV, preços competitivos no segmento mid-market.
- GlobalSign: paga, foco em compliance regulatório e enterprise.
Segundo a SSL Labs da Qualys (2024), Let’s Encrypt é a CA que mais emite certificados DV no mundo, respondendo por mais da metade de todas as emissões ativas.
Erros comuns em Wildcard
Cinco armadilhas frequentes:
- Achar que cobre deep subdomains: *.dominio.com NÃO cobre a.b.dominio.com. Para múltiplos níveis, use SAN com *.dominio.com e *.sub.dominio.com juntos no mesmo certificado.
- Tentar validação HTTP-01: wildcards exigem DNS-01 — a emissão vai falhar com erro de challenge inválido.
- Ignorar propagação DNS lenta: alguns provedores demoram minutos para propagar TXT; configure o parâmetro propagation-seconds no Certbot adequadamente.
- Sem automação de renovação: expiração silenciosa derruba produção; configure cron ou use Caddy/Traefik com renovação automática.
- Wildcard em cenário SAN: para 3 ou 4 domínios distintos (dominio1.com, dominio2.com.br), SAN é mais barato e reduz o blast radius.
Como emitir Wildcard — passo a passo
Usando Certbot com plugin Cloudflare DNS:
- Instale o Certbot e o plugin:
apt install certbot python3-certbot-dns-cloudflare. - Crie o arquivo de credenciais em
~/.secrets/cloudflare.inicom um token da Cloudflare (permissão Zone:DNS:Edit no escopo mínimo necessário). - Ajuste permissão:
chmod 600 ~/.secrets/cloudflare.inipara evitar leitura por outros usuários. - Execute:
certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/cloudflare.ini -d '*.shiftmind.com.br' -d 'shiftmind.com.br'. - Aguarde a validação DNS-01 (Certbot cria o TXT, espera propagação e remove automaticamente).
- Configure o NGINX apontando para
/etc/letsencrypt/live/shiftmind.com.br/fullchain.peme privkey.pem. - Teste a renovação com
certbot renew --dry-rune deixe o cron ativo rodando duas vezes ao dia.
Certificado Wildcard e a Shiftmind
A Shiftmind implementa certificados Wildcard em projetos corporativos há mais de 12 anos. Nossos serviços de hospedagem WordPress e servidor dedicado já incluem emissão automatizada e renovação monitorada. Em suporte e manutenção WordPress cuidamos de ambientes multi-site complexos, e nossa equipe de criação de sites entrega projetos com SSL enterprise desde o launch. Para empresas com requisitos de compliance, nossa proteção antivírus para websites integra WAF, Certificate Transparency Log monitoring e rotação de chaves.
Perguntas frequentes sobre Certificado Wildcard
Wildcard cobre o domínio raiz também?
Não automaticamente. Um certificado emitido apenas com *.dominio.com cobre subdomínios de primeiro nível, mas não o apex (dominio.com puro). Para proteger ambos, inclua os dois no comando de emissão passando -d '*.dominio.com' -d 'dominio.com'. Essa é uma das confusões mais comuns entre quem está migrando de certificados single-domain para Wildcard, e explica muitos tickets de suporte sobre erro de certificado no acesso ao domínio raiz após uma emissão incompleta.
Posso usar Wildcard com HTTP-01?
Não. Segundo a RFC 8555 (2019), o protocolo ACME exige validação DNS-01 para qualquer emissão com curinga. Isso ocorre porque validar um subdomínio específico via HTTP não prova controle sobre todos os possíveis subdomínios cobertos pelo curinga. Se o seu provedor DNS não tem API, considere migrar para Cloudflare, Route53 ou DigitalOcean, que oferecem plugins oficiais para Certbot e acme.sh.
Qual a diferença entre Wildcard e SAN?
Wildcard cobre subdomínios ilimitados de UM domínio (*.saas.com.br). SAN (Subject Alternative Name) ou UCC cobre múltiplos domínios distintos (saas.com.br, saas.com, saas.net), geralmente até 100 nomes por certificado. Para arquiteturas com muitos subdomínios do mesmo domínio, Wildcard é mais barato e simples de operar. Para marcas distintas ou domínios TLD diferentes, SAN é a escolha correta.
Wildcard é seguro para bancos ou e-commerce?
Depende do modelo de ameaça. Para e-commerce e bancos com múltiplas aplicações (app.banco.com, api.banco.com, portal.banco.com), Wildcard reduz atrito operacional, mas o blast radius em caso de vazamento é alto. A recomendação do CA/B Forum (2024) é separar certificados por nível de sensibilidade, usar HSM para armazenar chaves privadas e monitorar emissões não autorizadas via Certificate Transparency.
Posso usar Wildcard em CDN?
Sim. Cloudflare, AWS CloudFront e Fastly aceitam Wildcard. Em Cloudflare, o Universal SSL já entrega Wildcard automaticamente para contas gratuitas. Para origem personalizada (BYOC), você pode subir o seu próprio certificado via API do provedor de CDN. Verifique sempre se o SNI suportado pela CDN é compatível com os clientes que acessam a aplicação.
Termos relacionados
Conclusão
Certificado Wildcard é a escolha certa para arquiteturas com muitos subdomínios dinâmicos — SaaS multi-tenant, APIs versionadas e ambientes de staging. O trade-off entre eficiência operacional e blast radius exige planejamento, mas Let’s Encrypt tornou a emissão trivial e gratuita. Com Certbot ou Caddy, o processo de emissão e renovação cabe em uma linha de cron, e o monitoramento de Certificate Transparency Log fecha o ciclo de segurança. Última atualização: Outubro/2026.
