Resumo

  • Em 21 de abril de 2026, Geoff Huston revogou um certificado de teste da Let’s Encrypt e encontrou seu número de série na lista de revogação. Passadas 48 horas, as três versões de navegador testadas ainda aceitavam a conexão.
  • Na apresentação posterior à APNIC 62, Firefox passou a rejeitar o mesmo certificado após algumas semanas; Chrome e Safari continuavam a aceitá-lo naquele teste. O intervalo entre registrar e fazer valer a revogação é o ponto decisivo.

O certificado tinha sido formalmente revogado. No navegador, seguia com jeito de quem ainda possuía um crachá válido. Geoff Huston criou a credencial de teste com a Let’s Encrypt e a revogou quatro horas depois, em 21 de abril de 2026. Conferiu a lista da emissora: o número de série estava lá. Faltava descobrir se a notícia havia chegado à porta onde a conexão TLS é autorizada.

No relato de primeira mão publicado pela APNIC, Firefox 148.0.2, Chrome 147.0.7727.117 e Safari 25.4 aceitaram a conexão 48 horas depois. É uma observação datada, de um certificado em um ambiente de teste; não serve como placar permanente dos navegadores. Serve para mostrar a separação entre os dois atos. A autoridade retira sua declaração de confiança, mas o programa do usuário decide se admite aquela chave. A lista correta não fecha sozinha uma sessão.

Huston esperou mais. Nos slides da APNIC 62, ele diz que algumas semanas depois o Firefox rejeitou o mesmo certificado, enquanto Chrome e Safari ainda o aceitaram no teste. O artigo de abril e a palestra posterior não precisam ser nivelados numa frase única. Um retrata 48 horas; o outro, semanas. Entre os dois, a revogação estava publicada e a decisão do cliente mudou apenas em parte. É o atraso, não a disputa entre marcas, que merece o título.

Os caminhos para avisar o cliente cobram pedágio de modos diferentes. Baixar listas completas pesa. Perguntar a um servidor de status acrescenta latência, depende de sua disponibilidade e revela ao emissor quando o usuário visita um serviço. Anexar uma resposta assinada ao handshake economiza a consulta, mas quem apresenta conscientemente um certificado revogado dificilmente entregará com entusiasmo a prova contra si. Listas selecionadas distribuídas pelos navegadores trazem seu próprio calendário de atualização.

Huston também experimenta a tentação de encurtar a validade. Sair de 90 para 45 ou seis dias reduz o tempo possível de abuso; um comprometimento no primeiro dia ainda requer interrupção antecipada. Validade de horas pressionaria bastante o modelo atual de emissão e renovação. Nos slides finais, ele propõe guardar a informação da chave no DNS, assiná-la com DNSSEC, limitar a idade da resposta com TTL curto e talvez apresentar a cadeia de validação junto à conexão TLS. DANE é uma proposta de arquitetura nessa discussão, não uma mudança já implantada em toda a Web. A pergunta que permanece é brutalmente simples: quanto tempo uma informação de confiança pode ficar velha antes de alguém voltar a conferir?