2026-10-30 · RESEARCH · Equipe Offensive Technology

Um Certificado Wildcard Oculta Seus Subdomínios?

Um certificado wildcard oculta seus subdomínios? Em grande parte sim, mas quase ninguém realmente o utiliza dessa forma. Analisamos o certificado ativo atual de 660 grandes domínios por meio dos mesmos registros públicos de Certificate Transparency que qualquer pessoa pode consultar, e classificamos o que cada um revela. 63.8% enumeram pelo menos um subdomínio real pelo nome em entradas SAN comuns, sem nenhuma proteção por wildcard. Apenas 22.9% dependem exclusivamente de um wildcard, ocultando a estrutura de seus subdomínios da forma que a tecnologia permite. Somando os 11.1% que fazem ambos ao mesmo tempo, temos que 74.8% dos certificados atuais nos principais domínios revelam um hostname específico, quer tenham também um wildcard ou não. Um wildcard funciona exatamente como projetado. Quase ninguém opta por ele por esse motivo.

Por que isso é uma decisão, não apenas um padrão

Certificados wildcard e SAN (Subject Alternative Name) resolvem o mesmo problema, cobrir mais de um hostname com um único certificado, de maneiras opostas. Um wildcard corresponde a um padrão: *.example.com é válido para qualquer nome de nível único sob example.com, sem que esse nome apareça no certificado em si. Já um certificado SAN lista os hostnames explicitamente, um certificado pode cobrir app.example.com, api.example.com e admin.example.com inserindo os três no campo SAN. Ambos são padronizados, ambos são emitidos por qualquer CA pública, e o subject do certificado não revela se essa abordagem foi uma escolha consciente ou consequência da ferramenta usada.

A consequência da ferramenta é o caso mais comum. A emissão automatizada e gratuita, adotada por quase qualquer ambiente moderno, costuma solicitar um certificado para o hostname exato configurado no servidor. Se você subir dez subdomínios com dez solicitações automatizadas separadas, terá dez certificados SAN, cada um registrando seu próprio nome, e não um único wildcard cobrindo os dez. Optar por um wildcard exige uma etapa extra que a maioria das equipes nunca realiza, pois o caminho padrão já entrega um certificado funcional.

Os dados: o que 660 certificados atuais realmente escolhem

Para cada um dos 660 principais domínios com histórico em Certificate Transparency, pegamos o certificado mais recente já presente em nosso cache local (zero novas requisições ao crt.sh nesta execução, reutilizando o conjunto de dados de três publicações anteriores) e analisamos seus campos Subject e SAN. Classificamos cada certificado pelo que ele revela além do par básico e universal do domínio raiz e seu endereço www.: uma entrada wildcard sem mais nada, um wildcard com hostnames nomeados, hostnames nomeados sem nenhum wildcard ou nenhum dos dois.

Barras âmbar revelam um hostname específico em algum ponto do certificado; barras verde-azuladas não. Apenas a fatia de 22.9% exclusivamente wildcard e a de 2.3% apenas apex, totalizando 25.2% da amostra, mantêm a nomenclatura de seus subdomínios fora do registro público. Os outros três em cada quatro domínios estão, neste momento, entregando pelo menos um nome de subdomínio real a qualquer pessoa que consulte o Certificate Transparency.

Raramente é apenas um nome

Quando um certificado revela algo, ele tende a revelar mais do que um único hostname isolado. Entre os 494 certificados que listaram ao menos um subdomínio específico, o cenário típico traz apenas um ou dois, mas a distribuição tem uma cauda longa: o certificado individual mais carregado da amostra enumera 70 subdomínios distintos, e 20 certificados (4.0% de todos os que expõem nomes) listam dez ou mais, sendo que 9 deles listam 25 ou mais. Um certificado desse tamanho não esconde nada, ele funciona quase como um sitemap público da infraestrutura da organização, emitido em uma única requisição e registrado em um único log.

Essa última linha merece atenção. Um certificado no grupo "misto" carrega 94 entradas wildcard distintas em uma única chave, juntamente com SANs nomeados. Esse é quase certamente o caso de uma plataforma ou provedor de SaaS aplicando cobertura wildcard para muitos subdomínios regionais ou de clientes ao mesmo tempo. É prático de operar. Por outro lado, significa que uma única chave privada, se for comprometida, torna-se válida para todos os subdomínios sob esses 94 padrões simultaneamente, presentes e futuros. Usar wildcard troca a privacidade do subdomínio por outro risco: o tamanho do raio de impacto concentrado em uma chave só.

Por que nem todo mundo usa simplesmente um wildcard

Se um wildcard oculta mais, por que apenas 22.9% da amostra o utiliza de forma exclusiva? Existem alguns motivos práticos, e nenhum deles é um erro isoladamente:

• A automação prioriza a nomeação, não o wildcard. Ferramentas como o Certbot solicitam certificados para o hostname ao qual o servidor já responde. Obter um wildcard exige comprovar o controle do domínio via desafio DNS-01, uma etapa extra com ferramentas adicionais que a maioria dos deploys evita.
• Um wildcard cobre apenas um nível. *.example.com é válido para app.example.com, mas não para a.app.example.com. Qualquer hierarquia real de segundo nível exige um segundo wildcard ou entradas nominais, o que empurra as organizações de volta para a enumeração, mesmo quando já possuem um wildcard.
• O raio de impacto no comprometimento de chave é real. Uma chave privada de wildcard, se exposta, permite personificar todos os subdomínios cobertos de uma só vez. Já uma chave comprometida de um único host atinge apenas aquele host. Equipes que gerenciam subdomínios críticos ou com donos diferentes às vezes optam por certificados nomeados especificamente para manter o raio de impacto reduzido, mesmo que isso custe o sigilo dos subdomínios.
• Algumas auditorias exigem cobertura explícita. Certos processos de conformidade e inventário são mais simples de conduzir em certificados que listam cada hostname coberto nominalmente, em vez de dependerem de validação por padrão.

Como verificar o seu próprio domínio

Isso leva menos de um minuto e não exige nada além de um navegador, pois consulta o mesmo registro público que analisamos.

• Consulte o crt.sh para ver seu certificado atual. Acesse https://crt.sh/?q=yourdomain.com&output=json e veja o campo name_value da entrada mais recente, ou verifique o certificado do seu servidor diretamente com openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Conte o que ele realmente revela. Uma única entrada *.yourdomain.com sem mais nada indica apenas wildcard. Qualquer outra coisa, qualquer host nomeado além do domínio raiz e www., já é público via CT, independentemente de você ter também um wildcard em outro lugar.
• Decida o tradeoff conscientemente. Se o sigilo dos subdomínios for mais crítico para sua arquitetura do que o raio de impacto de um comprometimento de chave, migre para wildcard e um fluxo de emissão com DNS-01. Se não for, trate no mínimo cada SAN nomeado como público permanentemente e pare de confiar em subdomínios ocultos como mecanismo de segurança.

O que isso não prova

Limitações reais, porque métricas sem ressalvas são apenas marketing.

• Analisamos o certificado mais recente por domínio, não o histórico completo. Um domínio pode ter usado wildcard por anos e só recentemente adicionado um SAN nomeado, ou vice-versa. Este é um retrato da exposição atual, não um padrão histórico definitivo.
• Um SAN nomeado não prova que o serviço associado está ativo ou acessível. Apenas classificamos os hostnames presentes no certificado. Alguns subdomínios listados podem apontar para infraestruturas desativadas.
• Trata-se de uma amostra de 660 domínios de sites grandes e estabelecidos. O ranking Tranco tende a priorizar organizações com infraestrutura suficiente para exigir mais de um hostname. Um recorte diferente traria proporções distintas.
• Isso mede exposição, não explorabilidade. Descobrir o nome de um subdomínio é reconhecimento. O que um invasor faz com esse nome depende totalmente do que está realmente em execução por trás dele.

Perguntas frequentes

Um certificado wildcard oculta subdomínios?

Parcialmente. Um wildcard para *.example.com registra apenas o padrão no log, não os nomes específicos. Contudo, em nossa amostra, 63.8% dos certificados atuais nomeiam um subdomínio real de qualquer forma, e apenas 22.9% dependem exclusivamente de um wildcard sem expor nenhum host nomeado.

Subdomínios cobertos por um wildcard ainda podem aparecer nos logs de Certificate Transparency?

A entrada wildcard em si aparece apenas como o padrão, sem nomes específicos. Mas no instante em que um certificado à parte nomeia um host explicitamente, esse nome é registrado integralmente, mesmo que já exista um wildcard. 11.1% dos certificados analisados fazem ambos.

Qual é a diferença entre um certificado wildcard e um SAN?

Um wildcard cobre um padrão, *.example.com, sem nomear nenhum subdomínio. Um certificado SAN lista hostnames específicos de forma explícita. A emissão automatizada adota por padrão certificados SAN com o hostname exato configurado no servidor, razão pela qual a enumeração, e não o wildcard, é o caso mais frequente.

Um certificado wildcard é mais seguro do que listar cada subdomínio explicitamente?

Do ponto de vista do sigilo de nomes de subdomínio, sim. Pela ótica do raio de impacto no comprometimento de chave, nem sempre: uma única chave privada wildcard roubada é válida para todos os subdomínios cobertos de uma vez, enquanto uma chave por host comprometida atinge apenas aquele host.

O que acontece se a chave privada de um certificado wildcard for comprometida?

Um invasor pode personificar qualquer subdomínio sob aquele padrão até que o certificado seja revogado e reemitido em todos os locais em que foi instalado. Um certificado da nossa amostra continha 94 entradas wildcard distintas sob uma única chave, gerando um raio de impacto expressivo caso essa chave seja exposta.

Um wildcard cobre subdomínios de subdomínios?

Não. *.example.com é válido para a.example.com, mas não para a.b.example.com. Nomes de segundo nível exigem um wildcard próprio ou uma entrada SAN explícita, o que leva muitas organizações a enumerar hostnames mesmo quando já utilizam um wildcard.

Como invasores usam logs de Certificate Transparency para enumerar subdomínios a partir de listas SAN?

Todo certificado emitido por uma CA pública é registrado conforme a RFC 6962 e pode ser consultado gratuitamente pelo crt.sh. Um certificado que enumera hostnames entrega ao invasor um mapa pronto da infraestrutura, sem a necessidade de escaneamento ativo.

Você deve escolher wildcard ou SAN por segurança, e não apenas por conveniência?

Se a privacidade dos nomes de subdomínio for relevante, o wildcard é o padrão mais forte, embora a maioria das organizações desta amostra não faça essa escolha. Caso opte por enumerar, considere cada SAN nomeado como público permanentemente e avalie o tradeoff do comprometimento de chave antes de migrar.

Leituras complementares

• Como os logs de Certificate Transparency vazam subdomínios internos O mesmo cache, sob o prisma do conteúdo: quais categorias de hostnames internos realmente aparecem quando um certificado decide listá-los.
• Quanto tempo leva para um certificado aparecer no CT? A mesma base do crt.sh, focando no tempo de publicação em vez da exposição.
• A regra de certificados de 200 dias já entrou em vigor? Um terceiro ângulo sobre o mesmo cache de 660 domínios: o tempo de validade permitido para os certificados, e não o que eles expõem.