Atraso nos logs de Certificate Transparency: o que 1.3M de certificados mostram
Resposta curta: Analisamos o histórico público de Certificate Transparency (CT) de cerca de 700 domínios de alto tráfego e comparamos o início de validade declarado de cada certificado (NotBefore) com o momento em que ele realmente apareceu em um log de CT. Em 1.29 milhão de certificados registrados de 2013 até meados de 2026, 19.6% levaram mais de dois dias inteiros para aparecer no CT, e 15.0% levaram mais de uma semana. Em seguida, dividimos os dados em 15 de junho de 2026, quando o Root Program do Chrome passou a exigir que o certificado final emitido, e não apenas o precertificate, contivesse um registro qualificado em log de CT. Após essa data, a proporção acima de 48 horas cai para 1.7% e a proporção acima de uma semana cai para 0.8%, na mesma população, medida da mesma forma. A mediana dos certificados já era rápida antes da exigência; o que mudou foi a cauda longa, os certificados que costumavam ficar sem registro por dias, semanas ou meses. Cada número aqui decorre de uma leitura passiva de um log público. Nenhum host foi contatado, nada foi escaneado. Veja exatamente como medimos isso, quais emissores fecharam a lacuna mais rápido e o que isso prova e não prova.
Dois números, uma mudança de política
O Certificate Transparency foi criado para tornar a emissão de certificados um registro público e append-only: toda CA publicamente confiável registra os certificados que emite, de modo que qualquer pessoa, seja o proprietário de um domínio, um navegador ou um pesquisador, possa ver o que foi gerado para determinado nome. O problema sempre esteve na palavra "eventualmente". Uma CA era obrigada a registrar um precertificate e incorporar seus timestamps assinados antes de emitir o certificado final desde 2018, e um Maximum Merge Delay padrão da indústria limita quanto tempo um log tem para incorporar um precertificate enviado, normalmente cerca de 24 horas. Mas até este ano, não havia um prazo equivalente para registrar o certificado final em si. Um certificado podia ser assinado, datado e já estar em uso em produção enquanto sua própria entrada no log atrasava dias, semanas ou, em pelo menos um caso relatado de forma independente, meses.
Observe a mediana com atenção: ela quase não se moveu, de 1.0 hora antes da exigência para 0.975 hora depois. Isso não é um erro de dados, é a forma real da distribuição. A maioria dos certificados, da maioria dos emissores, já era registrada em até uma hora muito antes de qualquer exigência existir. O que a exigência visivelmente eliminou foi a cauda: a minoria de certificados que costumava ficar por dias ou semanas sem nenhum registro público no log. O atraso médio conta essa história de forma mais direta, caindo de cerca de 64 dias antes do marco para 6.7 horas depois, porque a média é puxada justamente pelos outliers que a mediana esconde.
O mecanismo: um prazo para precertificate e nenhum prazo para o restante
O design original do Certificate Transparency registra um precertificate, um placeholder com poison extension que permite a uma CA coletar Signed Certificate Timestamps antes de assinar o certificado real. Múltiplos logs públicos de CT devem aceitar e incorporar esse precertificate dentro de um Maximum Merge Delay delimitado, na ordem de um dia, e os navegadores exigem que os logs cumpram isso desde 2018. Essa parte do pipeline sempre foi pontual, razão pela qual a indústria podia apontar que "CT é obrigatório" como algo amplamente verdadeiro.
A lacuna estava na outra metade: nada forçava a CA a enviar o certificado final emitido para um log em qualquer cronograma específico. Uma CA podia obter seus SCTs a partir do precertificate, incorporá-los, emitir o certificado e colocá-lo em produção, tudo corretamente, enquanto a entrada do certificado final no log de CT aguardava. Um caso relatado de forma independente descreve um certificado wildcard emitido pela DigiCert para uma grande plataforma que teve uma lacuna de cerca de três meses entre sua emissão declarada e sua aparição no CT (não verificamos esse caso específico de forma independente; trate-o como uma anedota ilustrativa, não conclusiva). Nossos próprios dados mostram o mesmo padrão em escala populacional: antes da exigência, uma parcela relevante dos certificados de várias grandes CAs ficava mais de uma semana sem registro público em log, que é exatamente a brecha que a política de junho de 2026 do Chrome visa fechar ao exigir que o próprio certificado final contenha um registro de log qualificado.
Quais emissores fecharam a lacuna e em quanto
Estamos citando as autoridades certificadoras aqui, não os domínios cujos certificados contabilizamos. A prática de registro da própria CA é uma informação de interesse público sobre a CA, da mesma forma que um estudo anterior nosso analisou quais CAs os domínios autorizam a emitir em seu nome. Para cada emissor com uma amostra relevante em ambos os lados do marco temporal, aqui está a proporção de certificados registrados mais de 48 horas após o NotBefore, antes e depois de 15 de junho de 2026:
| Emissor | Antes (n) | Antes | Depois (n) | Depois |
|---|---|---|---|---|
| DigiCert Inc | 160,949 | 27.9% | 290 | 6.2% |
| Amazon | 95,508 | 20.0% | 863 | 2.9% |
| Google Trust Services | 66,473 | 10.3% | 2,249 | 3.1% |
| Sectigo Limited | 24,430 | 0.02% | 60 | 0.0% |
| Let’s Encrypt | 532,280 | 0.06% | 5,523 | 0.0% |
Dois pontos se destacam. Primeiro, Let’s Encrypt e Sectigo já estavam perto de zero antes da exigência existir, o que é coerente com o fato de ambas operarem pipelines de emissão em grande escala e altamente automatizados, onde "emitir e registrar" é praticamente uma etapa atômica. Segundo, as CAs que tinham mais margem para melhoria, DigiCert, Amazon e Google Trust Services, melhoraram expressivamente, reduzindo sua parcela de registros atrasados em cerca de quatro a sete vezes. Não foi possível construir uma linha de antes/depois confiável para todos os emissores: GlobalSign, a marca legada da COMODO e ZeroSSL tiveram certificados pós-exigência insuficientes em nossa amostra para relato (menos de algumas dezenas) ou nenhum dos domínios monitorados renovou por meio delas desde 15 de junho de 2026. Esse é um limite da nossa amostra de domínios, não uma conclusão sobre esses emissores.
Como medimos isso
Um cético deve ser capaz de reproduzir isso do zero, portanto aqui está o método completo, sem nada oculto.
- A população. Cerca de 700 domínios do top 1.000 do Tranco, reunidos em vários dos nossos estudos recentes de passive-DNS. Para cada domínio, analisamos seu histórico completo de Certificate Transparency no crt.sh, que retorna todos os certificados registrados para esse domínio e seus subdomínios, retroagindo a 2013.
- A métrica. Para cada certificado registrado, comparamos seu campo
not_before(o início da validade declarada do certificado) comentry_timestamp(quando o crt.sh gravou essa entrada de log). A diferença é o atraso que relatamos. Eliminamos duplicatas pelo ID interno de entrada do crt.sh e descartamos algumas poucas entradas com uma discrepância implausível (mais de cinco anos), que interpretamos como anomalias de relógio ou de parsing, e não como comportamento real de emissão. - A divisão. Agrupamos cada certificado conforme seu NotBefore tenha ocorrido antes ou a partir de 15 de junho de 2026, data em que entrou em vigor a exigência do Root Program do Chrome de que o certificado final emitido contenha um registro qualificado em log de CT. Nossos dados em cache vão até 24 de julho de 2026, portanto a janela pós-exigência abrange aproximadamente as primeiras seis semanas sob a nova regra, e não um ano inteiro; considere os números pós-exigência como uma leitura preliminar que esperamos consolidar, e não como uma tendência madura.
- O que não fizemos. Nunca solicitamos um certificado, não nos conectamos a nenhum servidor web nem escaneamos nada. Ler um log público de CT é uma consulta, não uma sondagem, o mesmo princípio que rege cada projeto que conduzimos.
- O que mantivemos. Contagens agregadas, medianas e percentis, por emissor e por período. Nenhum nome de domínio ou subdomínio consta nos resultados e não coletamos dados pessoais; nomes de domínio e metadados públicos de certificados não são dados pessoais.
O que isso não prova
Limites honestos, porque um número sem suas devidas ressalvas é marketing.
- A janela pós-exigência é curta. Seis semanas de dados são suficientes para mostrar o formato da mudança, mas não para atestar sua permanência. Parte da melhoria pode refletir uma conformidade inicial rigorosa que se flexibilize com o tempo; planejamos verificar isso novamente.
- Nem todo emissor tem um cenário posterior confiável. Algumas grandes CAs simplesmente tiveram poucos certificados pós-exigência em nossa amostra específica de 700 domínios para que pudéssemos relatar com precisão. Uma amostra mais ampla de domínios supriria essa lacuna.
- NotBefore não é um indicador perfeito de "quando o certificado foi realmente assinado". Uma CA pode definir o NotBefore ligeiramente no passado para tolerar clock-skew. Essa prática inflaria ligeiramente nosso número de atraso, mesmo para uma CA que registra pontualmente; mas isso não explica lacunas medidas em dias ou semanas.
- Esta é uma medição de atraso, não uma constatação de emissão indevida. Um certificado registrado com atraso não é evidência de emissão incorreta, apenas de que a trilha pública de auditoria ficou para trás em relação ao seu uso. O risco é a própria lacuna de auditoria: pelo tempo em que um certificado permanecer sem registro, ninguém que esteja monitorando CT para seu próprio domínio conseguirá vê-lo.
- A população é inclinada para domínios de alto tráfego. O top 1.000 da Tranco tende a organizações com muitos recursos e grandes CDNs; o comportamento de emissão para a cauda longa de sites menores, que geralmente usam as mesmas grandes CAs mas por meio de automações diferentes, pode diferir.
Por que isso importa
Toda a proposta de valor do Certificate Transparency para o proprietário de um domínio é permitir monitorar o log público em busca do seu próprio nome e detectar um certificado inesperado antes que ele seja usado contra você. Isso só funciona se o registro ocorrer próximo à emissão. Um certificado que fica sem registro por um mês é um certificado que estava ativo, com a confiança de todos os navegadores e invisível para qualquer pessoa monitorando CT exatamente durante esse período. A lacuna que essa exigência fecha não é exótica; é a simples diferença entre "estamos tecnicamente em conformidade com o Certificate Transparency" e "você pode realmente ver o que emitimos, com rapidez, todas as vezes". Os dados mostram que os emissores mais rápidos da indústria, entre eles Let’s Encrypt e Sectigo, já tratavam isso como uma etapa atômica bem antes de qualquer política exigir. O restante está visivelmente correndo atrás agora que o Root Program do Chrome tornou isso um requisito, e não uma boa prática, o que coincide com a história que encontramos quando analisamos quem realmente atesta logs de CT em produção: as partes deste ecossistema cuja conformidade é cobrada avançam rápido, e as partes que são meramente incentivadas não.
Atraso nos logs de Certificate Transparency: respostas rápidas
O que é o atraso nos logs de Certificate Transparency?
A diferença entre o início da validade declarada de um certificado TLS (NotBefore) e o momento em que ele realmente aparece em um log público de CT. Uma lacuna curta significa que a trilha pública de auditoria acompanha o ritmo da emissão; uma lacuna longa significa que um certificado válido e utilizável existiu por um período sem nenhum registro público.
O Chrome exige que todos os certificados sejam registrados em logs de CT?
A política do Root Program do Chrome exige que o certificado final emitido, e não apenas o precertificate, contenha um registro qualificado em log de CT para certificados emitidos em ou após 15 de junho de 2026; certificados emitidos após essa data sem isso não são confiáveis para o Chrome. O registro de precertificates já era obrigatório desde 2018.
Por que um certificado poderia ser válido antes de ser registrado em log?
O CT exige o registro de um precertificate antes da emissão do certificado final, e as regras de Maximum Merge Delay (cerca de 24 horas) delimitam quanto tempo isso leva. Até a política de junho de 2026 do Chrome, não havia um prazo equivalente para registrar o próprio certificado final, de modo que ele podia ser assinado, datado e utilizado enquanto sua própria entrada no log atrasava, às vezes por meses.
Como isso foi medido?
De forma passiva. Lemos o histórico público de CT, via crt.sh, de aproximadamente 700 domínios do top 1.000 da Tranco, comparando o NotBefore de cada certificado com o timestamp de sua entrada no log. Nenhum host foi contatado, resolvido por DNS ou escaneado. O resultado abrange 1.29 milhão de entradas de log de 2013 a meados de 2026, divididas no marco da exigência de 15 de junho de 2026.