Resumo

  • Renovar ou trocar o certificado altera a chave que assinará versões futuras, mas não invalida sozinho os binários corretamente assinados e carimbados antes do vencimento.
  • A transição deve ser controlada por artefato: hash, certificado, token RFC 3161, hora efetiva de revogação, local de distribuição e decisão observada do verificador.

Ao meio-dia, uma editora de software transfere a esteira de lançamento para um certificado novo. A primeira compilação é assinada corretamente e o painel fica verde. Mesmo assim, um instalador da noite anterior continua em um espelho regional, leva um carimbo válido e ainda passa na verificação dos clientes.

Isso não é necessariamente uma falha. A falha de controle seria chamar a rotação do certificado de transição de confiança concluída.

A assinatura liga os bytes a uma identidade. O carimbo de tempo acrescenta outra afirmação: uma autoridade confiável atesta que um hash existia em determinado momento. Essa combinação pode manter uma assinatura aceitável depois do vencimento normal do certificado. Também pode separar software assinado antes e depois da hora efetiva de revogação de uma chave comprometida.

Por isso o certificado tem dois finais operacionais. O primeiro é o vencimento, após o qual não deveria gerar novas assinaturas válidas. O segundo é o instante em que o verificador deixa de reconhecer sua autoridade. As datas podem coincidir, mas o sistema não obriga que sejam iguais.

O que o carimbo realmente prova

A RFC 3161 define o MessageImprint, formado pelo identificador do algoritmo e pelo hash dos dados. A Autoridade de Carimbo de Tempo confere algoritmo e comprimento, sem examinar o programa. O token inclui política, número de série único e genTime, e é assinado por uma chave dedicada.

Logo, o token não declara que o programa é seguro. Ele prova que um hash específico foi apresentado sob certa política. Não prova que a editora controlava todos os caminhos de assinatura nem que a versão antiga saiu de todos os espelhos.

A verificação continua sendo trabalho ativo. A RFC exige conferir resposta, certificado da autoridade, hash, algoritmo, assinatura e tempestividade. A Microsoft expõe a mesma separação no SignTool: sign, timestamp e verify são operações distintas. O caminho RFC 3161 usa /tr para o servidor e /td para o algoritmo do resumo temporal. A verificação pode examinar a cadeia e a revogação, não apenas a presença de uma estrutura assinada.

A documentação do ClickOnce mostra o efeito prático: com carimbo válido, um aplicativo pode continuar aceito após o certificado vencer. Isso evita re-assinar todo pacote histórico íntegro a cada renovação. A mesma persistência, porém, torna insuficiente olhar apenas para a próxima compilação.

A revogação cria uma fronteira no tempo

Os requisitos de assinatura de código do CA/Browser Forum abrangem certificados publicamente confiáveis e suas autoridades de tempo. Exigem que a CA emissora opere serviço compatível com RFC 3161, recomende o uso e rejeite MessageImprint em SHA-1.

Os requisitos também mostram por que revogar não é apagar. Um certificado pode ter assinado um objeto ou milhares; a revogação pode invalidar código íntegro junto com código suspeito. A CA deve começar a investigar uma denúncia plausível em vinte e quatro horas. Em comprometimento de chave, a data efetiva deveria ser o primeiro instante suspeito sustentado por evidência.

Essa data delimita os artefatos afetados. Os requisitos dizem que objetos com carimbo anterior à data de revogação deveriam continuar tratados como válidos. É uma regra do programa, não prova de comportamento idêntico em todas as plataformas.

A autoridade de tempo tem outra fronteira. A RFC 3161 distingue encerramento normal de comprometimento da chave. Se a autoridade for retirada sem comprometimento e o motivo for expresso corretamente, tokens anteriores podem permanecer válidos. Se a chave temporal for comprometida, seus tokens não merecem confiança automática; registros de auditoria ou um segundo carimbo independente podem se tornar necessários.

O denominador é todo artefato distribuído

Inventário de certificados não basta. A editora precisa saber qual artefato foi assinado, qual token está anexado, onde continua disponível e como cada verificador de destino o trata.

O perímetro inclui downloads, repositórios, caches, lojas corporativas, canais de atualização, instaladores offline e mídias de recuperação. Remover um arquivo da página atual não o retira desses locais. Revogar antes de localizar pacotes históricos íntegros pode transformar resposta de segurança em interrupção evitável.

O controle mínimo é um livro de transição da autoridade dos artefatos. Para cada hash, registra compilação, versão, impressão e série do certificado, algoritmos, token e autoridade temporal, genTime, vencimento, status e hora da revogação. Liga esses dados a cada local de distribuição, estado de retirada ou substituição, política de verificação e resultado observado.

Assim o encerramento pode ser testado. A transição termina quando a produção futura usa o signatário previsto, cada artefato antigo mantido possui decisão explícita, o material retirado desapareceu das superfícies controladas e verificadores representativos entregam o resultado esperado.

Limite da evidência

A RFC 3161 especifica token e verificação, não certifica um prestador. Os requisitos do CA/Browser Forum não uniformizam todos os sistemas operacionais. A documentação da Microsoft estabelece o comportamento documentado de SignTool, Authenticode e ClickOnce, não o de todo ecossistema.

Nenhum comprometimento é alegado. Vencimento, rotação, revogação e falha da autoridade temporal são eventos diferentes. Uma transição defensável mantém essa diferença na evidência e na decisão.

Fontes