Certificate Transparency na prática: SCTs e alertas

Resposta curta. O Certificate Transparency (CT, RFC 6962) obriga as CAs a enviar todo certificado TLS publicamente confiável para logs públicos append-only, que só aceitam o acréscimo de entradas. Cada log devolve uma promessa assinada de incluir o certificado, o SCT, e a CA incorpora os SCTs ao certificado. O Chrome, o Safari e o Firefox rejeitam certificados publicamente confiáveis que não tragam SCTs suficientes de logs independentes suficientes. Para você, isso significa duas coisas. Qualquer pessoa pode ver todos os certificados emitidos para seus domínios, pelo Cert Spotter, pelo crt.sh ou pelo seu próprio monitor. E convém acompanhar esses logs, porque um certificado que você não pediu é o primeiro sinal de um sequestro de DNS, de uma conta comprometida ou de uma CA que não se comporta como deveria.

Como o CT funciona

Um log CT é uma árvore de Merkle, a mesma estrutura de hashes append-only que o Git e o Bitcoin usam. Qualquer pessoa pode baixá-lo, verificar que as entradas nunca são removidas nem alteradas e obter uma prova curta de que um determinado certificado está incluído. A emissão com CT funciona assim:

1. A CA monta um pré-certificado: o conteúdo do certificado final mais uma extensão crítica “poison” (OID 1.3.6.1.4.1.11129.2.4.3), para que ele não possa ser usado como um certificado de verdade.
2. A CA envia o pré-certificado a vários logs. Cada log devolve um Signed Certificate Timestamp (SCT), uma assinatura sobre a entrada e um carimbo de tempo que promete a inclusão dentro do Maximum Merge Delay (MMD) do log, o prazo máximo para incluir a entrada.
3. A CA emite o certificado final com os SCTs incorporados em uma extensão X.509 (OID 1.3.6.1.4.1.11129.2.4.2).
4. Os navegadores conferem as assinaturas dos SCTs com sua lista de logs confiáveis e contam os SCTs de acordo com sua política.
5. Os monitores leem os logs e informam os certificados emitidos para os nomes que acompanham. Os auditores verificam se os logs continuam consistentes e cumprem suas promessas.

Na maioria dos casos, tanto o pré-certificado quanto o certificado final são registrados nos logs, e é por isso que as ferramentas de busca costumam mostrar cada certificado duas vezes.

Os SCTs de um certificado real

O openssl x509 -text decodifica os SCTs incorporados. Este é o certificado que letsencrypt.org servia em 20 de outubro de 2026:

subject=CN=letsencrypt.org
issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:
                                B0:F8:FC:5E:87:55:26:0F:15:D1:2E:72:BB:45:4B:14
                    Timestamp : Sep  4 15:33:02.377 2026 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:D0:2E:25:A4:9D:7F:C8:18:D6:7B:5E:...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 46:AF:86:3D:3B:3E:E5:9F:A5:77:DE:A8:24:5D:36:B0:
                                D9:ED:22:A2:23:F4:61:77:41:22:94:52:EE:95:50:5F
                    Timestamp : Sep  4 15:33:02.552 2026 GMT
                    Extensions: 00:00:05:00:24:DF:DB:0C
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:31:2F:83:D6:42:65:26:0D:58:D7:DD:C3:...

O ID do log é o hash SHA-256 da chave pública do log. Ao procurar os dois IDs na lista de logs do Chrome (log_list.json, versão de 19 de outubro de 2026), obtemos:

São dois logs de dois operadores diferentes, o mínimo para um certificado de 90 dias. A extensão do segundo SCT não é ruído. Os logs que seguem a static-ct-api colocam no SCT a posição da entrada no log: tipo de extensão 0 (leaf_index), comprimento 5 e um índice de 40 bits, aqui 618.650.380. Um monitor pode baixar essa entrada diretamente, sem precisar procurá-la.

O decodificador de SCT faz essa consulta por você. Ele mostra o nome de cada log, o estado dele nas listas do Chrome e da Apple e se o conjunto atende à política de cada navegador. O decodificador de certificados mostra a extensão de SCTs junto com o restante do certificado.

Os SCTs podem chegar ao navegador de três formas:

• Incorporados ao certificado, como acima. É o que quase todas as CAs fazem, e não exige nada de você.
• Na extensão TLS signed_certificate_timestamp. O servidor envia SCTs que ele mesmo obteve. Poucos servidores oferecem suporte a isso.
• Em uma resposta OCSP, via OCSP stapling. O Chrome só aceitava esses SCTs “em versões anteriores à versão 148” e, com a Let’s Encrypt e outras CAs desativando o OCSP, esse caminho está desaparecendo (veja OCSP e CRL em 2026).

O que os navegadores exigem

Os três principais motores de navegador exigem CT para certificados de CAs que fazem parte dos seus programas públicos de raízes.

Fontes: a política de CT do Chrome, a política de CT da Apple (abril de 2025) e a página de CT da Mozilla. Segundo a MDN, o Firefox exige CT no desktop desde a versão 135 (fevereiro de 2025) e no Android desde a versão 145 (novembro de 2025). A preferência security.pki.certificate_transparency.mode mostra o modo: 2 significa que o CT é exigido.

Duas consequências práticas:

• Os navegadores deixam de exigir CT se a lista de logs estiver antiga demais. O Chrome só exige CT enquanto sua lista de logs mais recente tiver menos de 70 dias, e a lista do Firefox expira depois de 10 semanas. Em uma máquina que não se atualiza há meses, o CT não é exigido de forma nenhuma; por isso, não use uma máquina assim para testar falhas de CT.
• CAs privadas estão isentas. As notas para empresas do Chrome dizem que o CT “só se aplica a CAs publicamente confiáveis”. Certificados de uma raiz que você mesmo instalou não precisam de SCTs e, de todo modo, os logs não os aceitam.

Os logs em si

A lista de logs do Chrome de 19 de outubro de 2026 conta 21 logs RFC 6962 utilizáveis, além de 2 somente leitura e 3 desativados. Ela também lista 22 logs static-ct-api utilizáveis e 37 qualificados. Onze operadores mantêm logs utilizáveis ou qualificados: Cloudflare, DigiCert, Geomys, GoDaddy, Google, HARICA, IPng Networks, Let’s Encrypt, Microsec, Sectigo e TrustAsia. Os logs são divididos em shards temporais. Um log chamado 2026h2 aceita apenas certificados que expiram no segundo semestre de 2026, o que mantém o tamanho de cada log limitado e permite desativá-lo quando seus certificados já tiverem expirado.

Os dois tipos de log recebem envios pelos mesmos endpoints da RFC 6962 (add-chain, add-pre-chain). A diferença está na forma como os monitores os leem. Um log RFC 6962 responde a chamadas dinâmicas de API:

{"tree_size":2980148930,"timestamp":1792499093002,"sha256_root_hash":"wr3F5apMl2E7wQHqbAA1yKsqaZbAzBXTT8WTAeRAy8M=","tree_head_signature":"BAMARzBFAiEAsC3Pr7fsPwy0vchrMDIXka7HxrZANu5tcXclDCUqqSYCIGJ64SaIT0tjM5hCGfycNGPfu6FP8q8RvW14Q4SoyvVU"}

São quase três bilhões de entradas em um único shard semestral. Um log static-ct-api (“tiled”, organizado em blocos chamados tiles) publica seu signed tree head (a cabeça assinada da árvore) como um checkpoint em texto puro, e as entradas como tiles imutáveis de 256 entradas, que as CDNs podem armazenar em cache:

tuscolo2026h2.sunlight.geomys.org
1007870339
aRhh7dPjYarH0itUM1LD+XJw7CW41z1+9tSnf3AizuY=

— tuscolo2026h2.sunlight.geomys.org W+DWDWi4dqCfFx8da0IS4+jwHKVL6ETEHGQCHn5y8rKflUhLRtLHQ3c6...
— grease.invalid Aui1jDc8Y7Uve7seHd/Pg1p+wHSUmw0+MTNyEKEAAbHaE5bY3Gi/MUZ3zBuk+NxUyhJL...
— tuscolo2026h2.sunlight.geomys.org 7BiSLwAAAaFZRnbMBAMARzBFAiA++3wWdtsK2H8l3IxZh6H/OQml...

As primeiras linhas são a origem, o tamanho da árvore e o hash da raiz. As linhas que começam com “—” são assinaturas. Repare que a URL de monitoramento (skylight) é diferente da URL de envio (sunlight). As duas constam da lista de logs.

Como encontrar seus certificados

Dois serviços públicos de busca cobrem praticamente todos os logs.

API do Cert Spotter (SSLMate). O endpoint de emissões lista os certificados não expirados de um domínio. Ele funciona sem chave, com um número limitado de consultas por hora. Para uso em produção, a SSLMate pede que você se cadastre para obter uma chave. Estes são os certificados de ecdsa.com:

curl -s "https://api.certspotter.com/v1/issuances?domain=ecdsa.com&include_subdomains=true&expand=dns_names&expand=issuer"

{
  "id": "16609031524",
  "tbs_sha256": "8c6f1f0bef5434da2012d5f29eab13f00bcec659f17832c07872ff600f61ecf5",
  "cert_sha256": "1396447e3454a081fe4e48dc1d5de18b7e3cf857ec1d7ff3c987d091c9024b04",
  "dns_names": [
    "ecdsa.com"
  ],
  "pubkey_sha256": "9a1fa381dad4630b83cf3a1a1a7a3da7f04577db8a41933dd9bac49dabfa8c29",
  "issuer": {
    "friendly_name": "Let's Encrypt",
    "pubkey_sha256": "2e8307068b6db620e4a39d068b5dee5d6ef5788cbb2c0b6d23ead84fcc17178c",
    "name": "C=US, O=Let's Encrypt, CN=YR1"
  },
  "not_before": "2026-08-19T14:52:58Z",
  "not_after": "2026-11-17T14:52:57Z",
  "revoked": false
}

Em resumo, a resposta trazia cinco emissões:

16609031524 2026-08-19 2026-11-17 Let's Encrypt ecdsa.com
16609045002 2026-08-19 2026-11-17 Let's Encrypt ecdsa.com,www.ecdsa.com
17525925247 2026-10-01 2026-12-30 Let's Encrypt *.ecdsa.com,ecdsa.com
17875915585 2026-10-19 2027-01-17 Let's Encrypt ecdsa.com,www.ecdsa.com
17878726033 2026-10-20 2027-01-18 Let's Encrypt ecdsa.com

Os resultados vêm na ordem em que a SSLMate os descobriu. Para paginar, passe o último id em after=. Um array vazio vem acompanhado de um cabeçalho Retry-After, o que permite usar o endpoint como um feed consultado periodicamente (polling). Repare no que o campo pubkey_sha256 permite fazer. Ao compará-lo com as chaves dos seus servidores, você descobre quais certificados estão de fato implantados e quais foram emitidos e nunca usados.

O crt.sh (Sectigo) tem uma interface web e uma saída JSON (https://crt.sh/?q=example.com&output=json). É gratuito e cobre um histórico muito longo, incluindo certificados expirados. Também é um serviço compartilhado com muito tráfego. As quatro consultas JSON que fizemos em 20 de outubro de 2026 retornaram 502 Bad Gateway. Use-o como uma conveniência, e não como uma dependência do seu monitoramento.

A ferramenta de histórico de CT mostra os certificados de um domínio ao longo do tempo, com o emissor, a validade e os nomes de cada um.

Como monitorar seus domínios

A busca responde “o que existe?”. O monitoramento responde “o que há de novo?” e avisa você em questão de minutos ou horas após a emissão. As opções:

• Um monitor hospedado. O Cert Spotter hospedado da SSLMate e os painéis de várias CAs enviam e-mails ou webhooks quando surgem novos certificados para seus domínios.
• O certspotter de código aberto (v0.25.0, setembro de 2026) lê os logs por conta própria. Você lista os nomes em ~/.certspotter/watchlist (um ponto no início cobre todos os subdomínios, por exemplo .example.com), e ele envia um e-mail ou executa os scripts de ~/.certspotter/hooks.d para cada correspondência. Desde a v0.24, ele também traz o certspotter-authorize, que marca os certificados esperados para que só os inesperados gerem alertas.
• A API de busca como feed. Consulte periodicamente o endpoint de emissões do Cert Spotter com after= e compare cada certificado novo com o que sua automação emitiu.

O que deve gerar um alerta:

1. Um emissor que você não usa. Compare com seus registros CAA. Um certificado de uma CA que seu CAA proíbe é um incidente da CA e precisa ser comunicado à CA.
2. Nomes que você não reconhece, principalmente subdomínios esquecidos. Um certificado para old-campaign.example.com pode significar que alguém assumiu o controle de um registro DNS órfão (dangling).
3. Uma chave pública que você não gerou para um nome gerenciado pela sua automação.
4. Certificados curinga, se sua política não os usa.

Com certificados de 47 dias, as emissões legítimas ficam frequentes. Sem o certspotter-authorize ou uma comparação com os registros do seu cliente ACME, a fadiga de alertas vai fazer você ignorar justamente o certificado que importa.

O CT e os nomes privados

Tudo o que está em um certificado publicamente confiável é publicado: cada nome da lista SAN, para sempre. Nomes de hosts internos como jenkins.corp.example.com ou staging-payments.example.com se tornam públicos no momento em que você obtém um certificado público para eles, e qualquer pessoa que leia os logs, inclusive quem procura alvos, consegue vê-los. As opções, segundo as notas do Chrome para empresas e a prática comum:

• Use uma CA privada para nomes internos. O CT não se aplica, e nada é publicado.
• Use um certificado curinga (*.corp.example.com) quando um certificado público for inevitável. Ele revela a zona, mas não cada host.
• Não conte com pedir a uma CA pública que não registre o certificado nos logs. Nesse caso, o certificado falharia em todos os navegadores que exigem CT.

Erros comuns

• Achar que um SCT prova a inclusão. Um SCT é uma promessa de incluir a entrada dentro do MMD. Auditores e monitores verificam se os logs cumprem essa promessa.
• Contar duplicatas. As entradas do pré-certificado e do certificado de uma mesma emissão aparecem como duas linhas na maioria das ferramentas de busca. Elas têm o mesmo emissor e o mesmo número de série, então elimine as duplicatas por esse par antes de contar certificados.
• Esperar informações de revogação no CT. Um certificado revogado fica no log para sempre. A revogação é um sistema à parte.
• Usar um navegador antigo para testar a exigência de CT. A exigência de CT se desliga sozinha quando a lista de logs do navegador fica desatualizada.
• Monitorar por meio de um único serviço gratuito. O crt.sh sai do ar de vez em quando. Use uma segunda fonte ou seu próprio monitor.

Fontes

• RFC 6962: Certificate Transparency (pré-certificados, SCTs, API dos logs). A RFC 9162 define o CT 2.0, que os navegadores não usam.
• static-ct-api: a API de leitura de logs em tiles e a extensão leaf_index.
• Política de CT do Chrome, lista de logs do Chrome, CT para empresas.
• Política de Certificate Transparency da Apple e lista de logs.
• MDN: Certificate Transparency, a página de Certificate Transparency da Mozilla e as notas de versão do Firefox 135.
• SSLMate: API do Cert Spotter e certspotter no GitHub.

As saídas dos comandos foram geradas em 20 de outubro de 2026 com OpenSSL 3.5.7 e curl 8.14.1 em node:24.22.0-trixie.