Resumo

  • Um SCT é a promessa assinada de um log de incorporar uma entrada; ele não substitui a validação normal nem satisfaz automaticamente a política do navegador.
  • A liberação deve registrar testes externos nos clientes atendidos, incluindo versão, lista efetiva e estado de aplicação de CT.

O serviço de certificados recebeu três SCTs e validou todas as assinaturas. O novo certificado chegou aos pontos de terminação. Mesmo assim, um conjunto de navegadores rejeita a conexão. A contagem de recibos não resolve o caso porque o cliente aplica condições que não pertencem ao evento de emissão.

A RFC 9162 define o SCT como uma promessa do log: a entrada aceita será incorporada à árvore Merkle append-only dentro do Maximum Merge Delay. Depois, inclusão e consistência podem ser auditadas. A própria RFC separa esse mecanismo da validação convencional do certificado do servidor e da sua cadeia.

O Chrome avalia como o SCT foi entregue, quantos logs distintos participaram, quantos operadores independentes estão representados e o estado do log na emissão e na verificação. Para SCTs incorporados em certificados de até 180 dias, a política atual pede ao menos dois logs e dois operadores distintos, além de um log que ainda contribua no momento da checagem. A entrega via TLS tem critérios próprios.

Logo, três SCTs podem ser insuficientes. A métrica esconde concentração em um operador, mudança de estado do log ou um canal de entrega submetido a outra regra.

A lista vigente também é parte do certificado operacional

O Chrome publica diariamente uma lista de logs. Ela identifica logs, operadores e estados de ciclo de vida que influenciam a decisão. O cliente também aplica um limite de atualização: se a lista mais nova armazenada tiver 70 dias ou mais, a aplicação de CT é desativada. Sucesso em um cliente desatualizado pode significar ausência de fiscalização, não conformidade superior.

Essa lista não deve ser convertida em autoridade universal. O Google delimita seu uso ao ecossistema Chrome e alerta outros agentes contra a reutilização como política própria. A Apple mantém requisitos diferentes: distingue logs atualmente aprovados de logs anteriormente aprovados, define combinações próprias de SCT e limita a contribuição do mesmo operador. A infraestrutura é compartilhada, mas a decisão continua específica do cliente.

Fragmentos temporais dão prazo à elegibilidade

Novos logs reconhecidos pelo Chrome precisam usar fragmentação temporal. Cada fragmento aceita certificados cujo notAfter esteja no intervalo declarado. O emissor escolhe, portanto, não apenas um operador disponível, mas um log compatível com a expiração do certificado e com o estado exigido.

A orientação do Chrome para operadores de sites diz que a informação CT de um certificado pode perder validade antes do vencimento do próprio certificado. A recuperação pode exigir SCTs novos via TLS ou substituição do certificado. Um alarme baseado apenas na data final não cobre esse risco.

Os fatos confirmados são as definições da RFC e as políticas publicadas por Chrome e Apple. A proposta de conciliar o recibo com clientes reais é uma inferência operacional. As fontes não mostram o parque de navegadores, as exceções, os contratos, os terminais ou o histórico de incidentes de uma organização. Também não demonstram falha atual de qualquer autoridade, log ou navegador. O que é privado permanece desconhecido até ser medido.

Um registro de aceitação deve reunir impressão digital, nomes e terminais, forma de entrega dos SCTs, IDs e horários dos logs, políticas e listas efetivas, cliente e versão testados, resultado externo, exceção, responsável e margem para troca. O recebimento pertence ao fluxo de emissão; a prova de conexão pertence ao serviço.

Fontes