Busca nos logs de certificados
Toda vez que um certificado é emitido para um dos seus nomes de host, ele entra num registro público que qualquer um pode ler. Esta busca lê esse registro para um domínio, lista os nomes que ele expõe e testa os mais recentes no DNS.
Um registro que qualquer um pode ler
Um certificado TLS é emitido por uma autoridade certificadora (CA), e o navegador confia em qualquer certificado assinado por qualquer uma das cerca de cem autoridades da lista dele. Durante anos, isso quis dizer que uma única autoridade descuidada ou comprometida podia emitir um certificado válido para o domínio do seu banco sem que ninguém percebesse.
O Certificate Transparency (CT) fecha essa brecha. As autoridades precisam enviar cada certificado a logs públicos em que só se pode acrescentar, e desde abril de 2018 o Chrome rejeita certificados sem prova de registro. O Safari aplica a mesma regra. Os logs são mantidos por empresas como Google, Cloudflare, DigiCert, Sectigo e Let’s Encrypt, e qualquer pessoa pode pesquisar neles.
Para você, isso vale para os dois lados. Você pode ver todos os certificados já emitidos para o seu domínio, inclusive os que nunca pediu. Todo mundo também pode, junto com cada nome de host escrito nesses certificados.
O que a busca faz com o log
Consultamos o crt.sh, um índice público dos logs de CT, para o domínio registrado e tudo o que está abaixo dele. Os resultados ficam guardados por uma hora. Depois nós os percorremos assim:
- Cada certificado é contado uma vez. Cada emissão aparece duas vezes nos logs, como pré-certificado e como certificado final. Entradas com o mesmo emissor e o mesmo número de série são unidas.
- Os subdomínios são coletados a partir dos nomes de cada certificado e ordenados pela data do certificado mais recente. Curingas como
*.example.comaparecem à parte. - Os 40 nomes mais recentes são resolvidos no DNS para ver se ainda levam a algum lugar.
- Os emissores são contados, no total e nos últimos 90 dias, e comparados com o seu registro CAA, se você publicar um.
Quando um domínio tem um histórico muito longo, o crt.sh devolve só uma parte ou estoura o tempo limite. A página avisa quando isso acontece e recorre aos certificados ainda válidos.
CNAMEs órfãos e sequestro de subdomínio
Imagine que status.example.com já foi um CNAME para example.herokuapp.com. Alguém apagou o app e esqueceu o registro DNS. O apelido agora aponta para um nome livre para ser reivindicado, e quem criar um app com esse nome na mesma plataforma recebe o tráfego do seu subdomínio. A partir daí, pode servir uma página de login sob o seu domínio e obter um certificado válido para ela.
A coluna de status mostra o que o DNS diz hoje.
- Resolve
- O nome tem um endereço. Nada a fazer.
- Destino sumiu (vermelho)
- Um CNAME para uma plataforma conhecida por deixar reaproveitar nomes abandonados, como GitHub Pages, Heroku, Azure, Amazon S3, Netlify ou Shopify, e o destino responde
NXDOMAIN. Trate como urgente. - Destino sumiu (âmbar)
- A mesma situação num serviço que não reconhecemos.
- Sumiu / Sem endereço
- O próprio subdomínio não existe mais. É inofensivo, embora o nome continue nos logs.
O conserto leva um passo. Apague o registro CNAME, ou recrie o recurso na plataforma se ainda precisar do subdomínio. E daqui em diante, inclua “remover o registro DNS” no encerramento de qualquer serviço hospedado.
Lendo a tabela de emissores
A maioria dos domínios mostra uma ou duas autoridades. Let’s Encrypt e Google Trust Services aparecem muito porque hospedagens e CDNs pedem certificados a elas automaticamente. Um emissor recebe a marca Incomum em dois casos. Ou ele emitiu nos últimos 90 dias e não está no seu registro CAA, ou você não tem registro CAA e ele responde por no máximo dois certificados num domínio que tem dez ou mais.
Incomum não quer dizer hostil. Ativar uma CDN, um construtor de sites ou uma nova ferramenta de landing pages muitas vezes traz uma nova autoridade junto. Pergunte a quem cuida desses serviços. Se ninguém souber explicar o certificado, encontre o número de série dele pelo link do crt.sh na última tabela e peça a essa autoridade que o revogue.
Para restringir quem pode emitir daqui em diante, publique registros CAA que citem só as autoridades que você usa:
example.com. CAA 0 issue "letsencrypt.org" example.com. CAA 0 issue "pki.goog"
Só 40 nomes são testados, e só quanto à falta do destino do CNAME. Algumas plataformas podem ser sequestradas mesmo quando o destino ainda responde, e nomes de host cobertos por um curinga nunca aparecem nos logs. Um resultado limpo aqui não é uma auditoria completa da sua zona DNS.
Perguntas frequentes
Posso remover um subdomínio dos logs de Certificate Transparency?
Não. Os logs só aceitam acréscimos, e são feitos para que uma exclusão seja notada. Considere que qualquer nome de host colocado num certificado público fica público para sempre.
Como encontrar todos os subdomínios de um domínio?
Os logs de CT são a fonte pública mais completa, porque quase todo nome de host com HTTPS teve um certificado em algum momento. Ficam de fora os nomes que só usaram certificado curinga e os que nunca serviram HTTPS.
Por que há centenas de certificados para o meu domínio?
Certificados automáticos duram 90 dias ou menos e são renovados mais ou menos a cada 60 dias, por nome de host, e uma CDN na frente do site emite os seus próprios por cima. Um site com cinco nomes de host pode gerar mais de trinta certificados por ano.
Como manter nomes de host internos fora dos logs?
Use um certificado curinga, que registra só *.example.com, ou emita certificados internos por uma autoridade privada em que os seus próprios aparelhos confiam. Em certificados públicos, evite nomes descritivos como vpn-admin ou o nome de um produto ainda não lançado.
Um certificado nos logs quer dizer que o site está no ar?
Não. Quer dizer que alguém conseguiu provar o controle daquele nome no dia da emissão. A verificação de DNS na tabela de subdomínios diz se o nome ainda leva a algum lugar.