Sumário

  • A DigiCert reportou no Mozilla Bugzilla que verificou alguns domínios usando um valor aleatório em um registro CNAME sem o prefixo de underscore obrigatório, afetando um caminho em seu sistema de validação OEM. Seu relatório de incidente disse que 83.267 certificados TLS válidos foram emitidos com base no método e que o conjunto afetado provavelmente foi superestimado porque o sistema não armazenou adequadamente se o underscore estava presente.
  • O problema de revogação foi imediato. Os Requisitos Básicos TLS do CA/Browser Forum exigem revogação dentro de janelas de tempo definidas para certificados emitidos incorretamente, e o relatório de incidente de revogação atrasada da DigiCert afirma que ela revogou todos os 83.267 certificados TLS afetados em 120 horas, em vez do período de 24 horas exigido pelas regras então vigentes.
  • O evento não foi apenas um erro de codificação da AC. Expôs a fragilidade do inventário de certificados entre os assinantes, os limites de comunicação por meio de revendedores e contas corporativas, a pressão legal de uma disputa de ordem de restrição temporária de um cliente, e o fato de que muitas organizações ainda não possuíam automação para substituir certificados rapidamente em escala.
  • O controle prático estava distribuído. A DigiCert controlava a implementação da validação, a identificação de certificados, a notificação ao cliente, a execução da revogação e o relato de incidentes. Os programas raiz e o CA/Browser Forum controlavam as expectativas de confiança e a pressão política, mas não a implantação pelo cliente. Os assinantes controlavam seus inventários, automação, janelas de alteração e implantação específica do serviço. Os usuários finais não controlavam quase nenhum risco.
  • A lição de responsabilidade é que as autoridades de certificação não podem tratar a revogação como um evento administrativo raro, e os assinantes não podem tratar os certificados TLS de confiança pública como infraestrutura estática. O modelo de segurança da Web PKI depende de que a substituição rápida seja operacionalmente rotineira antes que a emergência chegue.

Um underscore ausente se tornou um problema global de continuidade

O incidente da DigiCert é fácil de trivializar se for reduzido a pontuação. A questão técnica envolvia um prefixo de underscore obrigatório em um caminho de validação de controle de domínio baseado em CNAME DNS. Mas a consequência não foi uma correção tipográfica. A DigiCert teve que identificar e revogar dezenas de milhares de certificados de confiança pública, muitos implantados em serviços em nuvem, redes de telecomunicações, ambientes de saúde, aplicativos empresariais e sites voltados ao cliente.

O próprio registro público de incidentes da DigiCert no Mozilla Bugzilla bug 1910322 é a âncora factual. A DigiCert relatou que recebeu um relatório de problema de certificado indicando que poderia ter um problema com a implementação do método 7, validação baseada em DNS. Ela descreveu vários processos de verificação relacionados a DNS e disse que uma revisão de código encontrou um caminho onde um certificado podia ser emitido quando o valor aleatório era usado como host em um registro CNAME sem primeiro adicionar um underscore.

Mais adiante no mesmo bug, o relatório de incidente da DigiCert disse que o impacto foi limitado a emissores que usam seu sistema de validação OEM, enquanto os caminhos de validação por meio do CertCentral e do CIS, seu motor de emissão de alto volume para provedores de nuvem, validavam domínios corretamente e não foram afetados.

O número também é do registro público de incidentes. A DigiCert disse que 83.267 certificados válidos foram emitidos com base no método e que estava revogando todos os certificados válidos no banco de dados listados como usando validação DNS baseada em CNAME antes da data da correção. Ela explicou que isso provavelmente superestimou o conjunto real afetado porque os controles do sistema OEM não armazenaram adequadamente se um underscore estava presente. Essa frase é o ponto central da responsabilidade. O sistema podia identificar uma população de risco, mas não provar claramente quais certificados tinham a forma conforme.

Em um sistema de confiança, a incerteza sobre conformidade pode se tornar uma obrigação de revogação.

A razão de segurança para o underscore não é meramente estética. Os métodos de validação do CA/Browser Forum distinguem entre nomes que um assinante controla e nomes que podem ser delegados ou criados por usuários sob um domínio maior. A discussão no Bugzilla enfatizou que um rótulo com prefixo de underscore ajuda a criar um namespace de validação especial que nomes de host comuns e muitos serviços de subdomínio delegados podem evitar. Um underscore ausente pode minar uma suposição usada para evitar a emissão indesejada de certificados onde usuários podem criar subdomínios sob um domínio que não controlam.

É por isso que o evento pertence ao poder de delegação DNS. A validação de domínio é uma forma de converter evidências do DNS em autoridade para emitir um certificado. Se a evidência é aceita do lugar errado, ou se um marcador de limite obrigatório está ausente, a AC pode tratar um posicionamento DNS mais fraco como prova de controle. O certificado então dá às partes confiantes um sinal de confiança do navegador para um nome. O poder de emitir está, portanto, ligado ao poder de interpretar corretamente a delegação DNS.

As regras fizeram o que as regras fazem: forçaram ação

Os Requisitos Básicos TLS do CA/Browser Forum são o conjunto de regras públicas no centro do incidente. Eles definem métodos de validação de domínio e obrigações de revogação de certificados para certificados de servidor TLS de confiança pública. O artigo não precisa citar cada requisito para explicar a estrutura de responsabilidade: se um certificado foi emitido incorretamente ou a validação não estava em conformidade com os Requisitos Básicos, a AC deve revogar dentro do prazo aplicável, a menos que as próprias regras permitam outro caminho.

O relatório de revogação atrasada da DigiCert no Mozilla Bugzilla bug 1910805 declara o conflito de conformidade claramente. A DigiCert disse que estava trabalhando para revogar todos os certificados em 24 horas, mas após discussão com os programas raiz e a comunidade sobre o impacto, decidiu atrasar e revogar todos os certificados afetados em 120 horas. Seu relatório de incidente posterior resumiu o impacto: a DigiCert revogou 83.267 certificados em cinco dias em vez de 24 horas, conforme exigido pelos Requisitos Básicos vigentes.

Essa admissão é importante porque separa dois incidentes. O bug 1910322 dizia respeito à não conformidade na validação de domínio. O bug 1910805 dizia respeito à revogação atrasada. O primeiro problema foi como os certificados passaram a ser considerados não conformes. O segundo problema foi como o ecossistema lidou com a obrigação de remover esses certificados da confiança enquanto os clientes ainda dependiam deles para serviços ativos.

A distinção impede um argumento superficial. Poder-se-ia dizer que a DigiCert deveria simplesmente ter revogado imediatamente e cumprido a regra. Essa é a posição política limpa. Poder-se-ia também dizer que a revogação imediata teria interrompido serviços críticos e, portanto, o atraso era prático. Essa é a posição operacional. O incidente mostra a lacuna desconfortável entre as duas. As regras de confiança pública são projetadas para proteger as partes confiantes de certificados inválidos ou emitidos incorretamente.

Os assinantes do mundo real frequentemente operam como se os certificados fossem ativos difíceis de substituir, vinculados a janelas de manutenção, appliances, balanceadores de carga, sistemas embarcados e aprovações de alteração.

Os programas raiz foram cuidadosos quanto à autoridade. No tópico do Bugzilla, representantes do Chrome Root Program disseram que não tinham autoridade para conceder exceções aos Requisitos Básicos do CA/Browser Forum e que esses requisitos são orientados por consenso, e não propriedade de um único programa raiz. A política do Chrome Root Program fornece o contexto mais amplo do navegador raiz: uma AC participa do armazenamento raiz sob expectativas do programa, avaliação de incidentes e pressão contínua de conformidade. Mas a consulta de um programa raiz durante uma crise não é uma isenção mágica das regras públicas.

A Política de Armazenamento Raiz da Mozilla e o guia de resposta a incidentes da CA da Mozilla servem a uma função semelhante. Eles tornam a notificação de incidentes e a capacidade de resposta parte da governança de confiança. Eles não operam os servidores dos assinantes e não inventariam certificados dentro da infraestrutura do cliente. Eles criam o fórum público de responsabilidade no qual a DigiCert teve que explicar o que aconteceu e o que mudaria.

O relatório da DigiCert foi excepcionalmente sincero sobre causas organizacionais

A parte mais valiosa do relatório de incidente da DigiCert não foi a contagem de certificados. Foi a linguagem de causa raiz. A DigiCert disse que o problema foi exposto quando implementou mudanças para consolidar fluxos de validação de domínio e reutilizar valores aleatórios em vários métodos. Ela disse que um caminho através do sistema não incluía o underscore ao usar a verificação CNAME. Ela identificou causas raiz incluindo isolamento entre engenharia e conformidade, falha em levar a sério relatórios de problema de certificado se não incluíssem números de série e falta de rigor em engenharia.

Essa sinceridade importa porque incidentes de Web PKI são frequentemente tratados como defeitos estreitos de conformidade. Um prefixo de validação ausente pode ser descrito como um bug de código, mas o próprio relatório da DigiCert o enquadrou como uma falha organizacional do sistema. A engenharia crítica para conformidade não pode viver em um mundo mental separado da interpretação de conformidade. Um relatório de problema de certificado sem número de série ainda pode ser um aviso real. Um projeto de consolidação pode melhorar sistemas enquanto revela defeitos herdados de limites antigos de fluxo de trabalho.

O mesmo registro do Bugzilla inclui a liderança da DigiCert reconhecendo que as equipes internas nem sempre trabalhavam juntas como deveriam e que o mundo que dependia delas tornava isso inaceitável. Isso não é uma conclusão legal, mas é uma forte admissão institucional: uma autoridade de certificação de confiança pública não é apenas mais um fornecedor de SaaS. Seu código de validação faz afirmações nas quais navegadores, sistemas operacionais, sites, agências, bancos, hospitais e usuários confiam sem ver o fluxo de trabalho interno da AC.

A DigiCert também disse que o caminho afetado era limitado ao sistema de validação OEM, não ao CertCentral e ao CIS. Esse limite é importante. Ele impede que o incidente seja exagerado como uma falha de todos os canais de validação da DigiCert. Mas o limite também levanta uma questão de controle: por que um caminho do sistema de validação tinha um comportamento de conformidade diferente, e por que o modelo de dados não reteve detalhes suficientes para distinguir casos conformes de não conformes após o fato?

A decisão de superestimar foi compreensível. Se a AC não pode determinar quais certificados foram emitidos com o underscore ausente, revogar todos os certificados no conjunto de risco é mais seguro para a confiança das partes confiantes do que deixar certificados possivelmente não conformes vivos. Mas a revogação excessivamente ampla aumenta a interrupção do assinante e a carga de suporte. Esse é o custo de precisão forense insuficiente nos dados de emissão de certificados.

A lição de responsabilidade para as ACs é, portanto, dupla. Primeiro, as implementações de validação precisam de cobertura de teste rigorosa contra os Requisitos Básicos. Segundo, os sistemas de emissão precisam de registros de evidências detalhados o suficiente para suportar remediação precisa. Uma AC não deve ter que escolher entre sub-revogação e super-revogação em massa porque seu próprio sistema falhou em preservar fatos críticos de conformidade.

O lado do assinante transformou política em dor

A atualização inicial da DigiCert no Bugzilla disse que 83.267 certificados afetavam 6.807 assinantes. Também disse que muitos clientes operando infraestrutura crítica, redes de telecomunicações vitais, serviços em nuvem e indústrias de saúde não estavam em posição de serem revogados sem interrupções críticas de serviço. Essa declaração não foi uma isenção geral. Foi evidência de que grandes partes do ecossistema de assinantes estavam operacionalmente despreparadas para substituição rápida.

O alerta de Revogações de Certificados DigiCert da CISA mostra o impacto no serviço público. A CISA disse que a DigiCert estava revogando um subconjunto de certificados TLS devido a um problema de não conformidade com a verificação de controle de domínio e alertou que a revogação poderia causar interrupções temporárias em sites, serviços e aplicações que dependem desses certificados para comunicação segura. A CISA instou os clientes a verificarem sua conta DigiCert e reemitirem ou renovarem chaves de certificados.

Sua atualização de 31 de julho apontou os clientes para informações atualizadas e prazos e incentivou o contato com a DigiCert se não fosse possível reemitir ou renovar chaves até o prazo de revogação atualizado.

A página de incidente do Google Cloud sobre o evento de revogação da DigiCert é útil porque mostra como um evento de AC se torna trabalho para o cliente da nuvem. Os provedores de nuvem podem não ter causado o bug de validação, mas eles têm clientes cujos serviços, balanceadores de carga, APIs, gateways ou produtos gerenciados podem depender de certificados afetados. Quando uma autoridade de certificação revoga em escala, os intermediários devem identificar ativos afetados, comunicar, fornecer caminhos de substituição e reduzir o tempo de inatividade.

Para organizações pequenas e médias, a dor pode ser mais aguda. Uma PME pode ter um certificado instalado em um painel de hospedagem, firewall, appliance VPN, sistema de ponto de venda, gateway de e-mail, provedor de identidade, gateway de API, backend de aplicativo móvel, integração SaaS ou plataforma gerenciada por fornecedor. A pessoa que solicitou o certificado pode ter saído. O contato de validação DNS pode ser um revendedor. O certificado pode ser rastreado em uma planilha ou não rastreado. A substituição pode exigir aprovação de alteração fora do horário comercial ou um chamado de fornecedor.

Vinte e quatro horas é muito tempo para um script e pouco tempo para uma organização frágil.

É por isso que o rótulo de manifesto "Continuidade de Serviço PME" se encaixa. O incidente ameaçou a disponibilidade através de uma correção de controle de segurança. Um certificado pode ser matematicamente pequeno e operacionalmente central. Se expirar ou for revogado sem substituição, navegadores e clientes rejeitarão conexões, APIs falharão, os usuários verão avisos e serviços que nunca pareceram "infraestrutura de certificado" se tornarão indisponíveis.

A responsabilidade do assinante é real. As organizações que operam serviços públicos devem saber quais certificados possuem, onde estão implantados, qual AC os emitiu, quando expiram, como substituí-los, quem aprova a alteração e se existe automação. Mas a responsabilidade da AC também é real. Uma AC que sabe que a revogação é obrigatória deve projetar validação, inventário, notificação e ferramentas para o cliente para substituição de emergência, não apenas renovações ordinárias.

Revendedores e canais de cliente fizeram parte da superfície de falha

A discussão no Bugzilla incluiu preocupações de que revendedores poderiam não fornecer informações de revogação aos seus assinantes e que a notificação apenas por e-mail gerou confusão. A DigiCert disse mais tarde que adicionou mensagens no console para alertar os usuários, mas que comunicar fora do e-mail em um curto período era difícil. Esse é um detalhe prático com grandes consequências.

As autoridades de certificação frequentemente operam por meio de hierarquias de contas, revendedores, equipes de compras corporativas, provedores de serviços gerenciados e intermediários em nuvem. O assinante que controla o endpoint ativo pode não ser o titular da conta que recebe os e-mails da AC. Um revendedor pode receber um aviso e precisar encaminhá-lo. Uma equipe de segurança central pode possuir a conta da AC enquanto os proprietários de aplicativos possuem a implantação. Um serviço gerenciado pode manter a chave privada e o certificado em nome do cliente. Cada transferência consome tempo dentro de uma janela de revogação de 24 horas.

Isso torna a comunicação de revogação um controle, não uma cortesia. Os avisos de emergência devem alcançar contatos técnicos, contatos de conta, contatos de revendedor e endpoints legíveis por máquina. Eles devem identificar os seriais de certificados afetados, domínios, produtos, etapas de substituição, prazos e a consequência da inação. Eles devem estar disponíveis através do console da conta, API, e-mail e canais de status. Eles devem facilitar a exportação de um inventário completo de afetados pelo assinante.

O Aviso de Incidente de Revogação da DigiCert, vinculado pela CISA e na discussão da Mozilla, serviu ao papel de notificação voltada ao cliente. O portal de status da DigiCert em status.digicert.com também foi referenciado pela CISA para cronogramas atualizados. Essas páginas são importantes mesmo quando o acesso arquivístico é imperfeito porque agências públicas e discussões de programas raiz apontaram clientes para elas durante o incidente.

A comunicação também teve que evitar criar uma falsa promessa de que a revogação era opcional. Um participante do Bugzilla criticou a ideia de solicitações de clientes por atraso porque isso poderia sugerir que a revogação obrigatória é negociável. A própria DigiCert disse mais tarde que não gostaria de construir um formulário de solicitação de atraso porque revogações atrasadas não são permitidas e tal formulário poderia transmitir que são permitidas. Essa tensão é real. Uma AC precisa ouvir sobre risco de infraestrutura crítica, mas a regra existe para proteger partes confiantes que não participam da conversa privada.

A melhor resposta não é o silêncio. É uma comunicação preparada e consistente com a política. Os assinantes devem saber com antecedência que a AC pode revogar sem negociação prolongada. Eles devem ter automação para substituir rapidamente. As ACs devem ter inventários precisos e notificações multicanais. Os programas raiz devem manter a discussão pública de incidentes visível o suficiente para que alegações excepcionais não se tornem acordos privados.

A pressão legal expôs a borda frágil da revogação obrigatória

O relatório de revogação atrasada diz que a DigiCert recebeu aviso de que um cliente havia entrado com um pedido de ordem de restrição temporária contra as revogações. O dossiê público, Alegeus Technologies LLC v. DigiCert, faz parte do registro do incidente porque mostra como a pressão de continuidade do assinante pode colidir com as obrigações da AC. Comentários posteriores no Bugzilla disseram que as questões legais foram resolvidas entre as partes.

A disputa legal não deve ser superinterpretada. Um arquivamento judicial temporário não é uma conclusão final de que a DigiCert estava certa ou errada, ou que o cliente tinha um direito duradouro de bloquear a revogação. É evidência de pressão durante o incidente. Um assinante enfrentando tempo de inatividade pode recorrer a ferramentas legais se acreditar que a revogação causará danos. Uma AC enfrentando obrigações do programa raiz pode precisar defender sua autoridade para revogar sob acordos de assinante e regras de confiança pública.

Este é um problema estrutural para a Web PKI. As partes confiantes em todo o mundo dependem de que as ACs revoguem certificados emitidos incorretamente prontamente. Um único assinante depende de seus próprios serviços permanecerem ativos. Tribunais, contratos e arquivamentos de emergência podem ser locais, enquanto a confiança do navegador é global. Se uma AC atrasa porque um único assinante obteve alívio legal, o risco não está isolado para esse assinante. Torna-se parte do registro de confiança pública.

Os acordos de assinante e contratos corporativos devem, portanto, ser explícitos. Uma AC deve manter o direito de revogar certificados quando exigido pelos Requisitos Básicos ou pela política do programa raiz. Os clientes devem saber que o inconveniente operacional não é uma garantia de atraso. Ao mesmo tempo, as ACs devem projetar programas de cliente para que a revogação de emergência não chegue como uma surpresa após anos tratando certificados como ativos manuais.

O incidente também sugere que a preparação legal faz parte da preparação para incidentes da AC. Uma AC deve saber, antes da próxima revogação em massa, quem pode revisar pedidos de ordem de restrição, como os contratos de assinante apoiam a revogação obrigatória, quais declarações públicas podem ser feitas e como coordenar com programas raiz sem pedir autoridade que eles não têm. O relógio é muito curto para improvisação.

A automação era a camada de resiliência ausente

O bug de revogação atrasada contém a linha mais clara de todo o episódio: após a revogação ser concluída, a DigiCert disse que a razão número um pela qual as organizações não podiam substituir em 24 horas era que a grande maioria das organizações na indústria ainda não usava automação para emitir, manter e substituir certificados. Essa é a lição operacional.

ACME, definido no RFC 8555, foi criado para automatizar a emissão e gerenciamento de certificados. A automação não se limita ao ACME, e nem todo sistema empresarial está pronto para ACME. Mas o princípio é mais amplo: os certificados devem ser renováveis e substituíveis através de fluxos de trabalho testados, não rituais manuais anuais. A cédula SC-063 do CA/Browser Forum sobre certificados de curta duração e incentivos à automação mostra que a indústria já estava avançando em direção a vidas úteis mais curtas e melhor agilidade antes deste incidente.

Os comentários do Chrome Root Program no Bugzilla fizeram o mesmo ponto. Representantes do Chrome disseram que priorizam melhorar a agilidade e resiliência em toda a Web PKI para que eventos de revogação sejam menos disruptivos, e notaram que a automação e abordagens no estilo ARI têm benefício limitado sem adoção ampla por ACs e assinantes. O rascunho de extensão de Informações de Renovação ACME é relevante porque visa permitir que ACs sinalizem informações de temporização de renovação para clientes ACME.

Não é uma solução completa para todos os problemas de revogação atrasada, mas reflete a direção correta: coordenação de renovação e substituição legível por máquina.

A automação também importa para inventário. Um assinante não pode substituir o que não pode encontrar. O gerenciamento de certificados deve responder rapidamente a perguntas básicas: quais certificados encadeiam para a DigiCert, quais são afetados por um incidente de AC, quais sistemas os usam, quais chaves privadas estão disponíveis, quais proprietários são responsáveis, quais substituições foram implantadas e quais endpoints ainda servem certificados revogados ou antigos. Muitas organizações descobrem durante emergências que seu inventário de certificados é aspiracional.

Para as ACs, a automação deve incluir descoberta de certificados afetados e notificação ao cliente. No Bugzilla, a discussão da DigiCert observou que coletar informações de certificados e contatos envolveu um data lake central e a equipe de business intelligence. Esse detalhe deve preocupar qualquer AC. Se uma equipe fora da resposta normal a incidentes é necessária para montar uma lista durante um prazo de 24 horas, o processo não está suficientemente operacionalizado. Os dados necessários para a revogação devem estar prontos para incidentes.

A automação não é uma forma de evitar responsabilidade. É o meio pelo qual a responsabilidade se torna possível em escala de internet. Regras que exigem revogação rápida só são críveis se ACs e assinantes puderem executar substituição rápida sem esforço manual heroico toda vez.

O fluxo de trabalho de substituição também deve incluir validação de sucesso. Um assinante não deve tratar um certificado recém-baixado como o fim do incidente. Ele tem que confirmar que o certificado está instalado em todos os endpoints, que as cadeias intermediárias estão corretas, que certificados antigos não são mais servidos por balanceadores de carga secundários ou sites de recuperação de desastres, que o monitoramento não vê mais o serial revogado e que clientes dependentes aceitam a substituição.

Em um ambiente grande, essas verificações precisam de varredura e atestado do proprietário do serviço, não de uma única captura de tela do console da conta. O evento da DigiCert mostrou por que a agilidade de certificados é uma disciplina de ciclo de vida: descobrir, emitir, implantar, verificar, monitorar e aposentar. Perder qualquer um desses passos pode transformar uma correção de conformidade da AC em tempo de inatividade prolongado do cliente.

A mesma lição se aplica à supervisão da gestão. A substituição de certificados deve ser ensaiada como um exercício de resiliência, não tratada como uma tarefa de renovação silenciosa de propriedade de um único responsável pela infraestrutura. Conselhos e comitês de risco não precisam inspecionar cada número de série, mas devem saber se os serviços públicos críticos podem substituir certificados fora da temporada anual de renovação, se pedidos de exceção chegam rapidamente às equipes jurídicas e operacionais e se a organização pode provar a conclusão antes que a revogação atinja os usuários.

Nesse sentido, o episódio da DigiCert foi também um exercício de mesa que muitos assinantes descobriram apenas depois que o relógio começou.

Os certificados afetados eram um problema de confiança, não necessariamente uma descoberta de exploração

O registro público apoia uma conclusão de validação não conforme e revogação em massa. Não apoia, a partir das fontes aqui utilizadas, uma conclusão ampla de que atacantes exploraram o bug da DigiCert para obter certificados para serviços importantes. Participantes do Bugzilla perguntaram se a DigiCert verificou exploração e discutiram possíveis cenários de risco envolvendo serviços que permitem que usuários criem subdomínios arbitrários. Essas perguntas eram importantes, mas perguntas não são conclusões.

Esse limite importa. Exagerar a exploração seria irresponsável. Subestimar o risco também seria errado. O propósito da validação de controle de domínio é impedir a emissão para partes que não controlam o domínio relevante. Se um método de validação relaxa um limite obrigatório, a AC tem que tratar os certificados emitidos através desse caminho como suspeitos, mesmo que nenhum atacante conhecido o tenha usado. A confiança pública depende da conformidade com as regras precisamente porque as partes confiantes não podem investigar cada evento de emissão.

O site público do CCADB fornece contexto para a infraestrutura de transparência usada pelos armazenamentos raiz e ACs, enquanto crt.sh e logs de Transparência de Certificados ajudam a comunidade a inspecionar certificados emitidos. No tópico do Bugzilla, membros da comunidade analisaram listas de certificados fornecidas pela DigiCert contra dados de transparência de certificados. Esta é uma força da Web PKI: evidências públicas existem para revisão externa. É também um lembrete de que a transparência após a emissão não substitui a validação correta antes da emissão.

O relatório de incidente disse que a DigiCert revogaria todos os certificados no conjunto de risco, mesmo que o conjunto provavelmente superestime. Esta é uma decisão de confiança conservadora. Mas decisões de confiança conservadoras impõem custos de disponibilidade. A Web PKI deve, portanto, investir em ambos os lados: reduzir erros de emissão através de melhores controles de validação e reduzir interrupções através de melhor automação de substituição.

A distinção também importa para os usuários finais. Um usuário de navegador vendo um aviso de certificado revogado não sabe se o certificado subjacente foi ativamente abusado, emitido através de um caminho não conforme ou pego em uma superestimação conservadora. O usuário vê apenas um problema de serviço. É por isso que a responsabilidade não pode parar na revogação. Deve incluir comunicação com o cliente e remediação rápida para que o sinal de segurança permaneça significativo, em vez de se tornar mais uma razão para os usuários clicarem através de avisos.

Os programas raiz eram supervisores, não operadores do tempo de atividade do cliente

Os programas raiz da Mozilla, Chrome, Apple e Microsoft moldam o ecossistema de ACs de confiança pública. A Política de Armazenamento Raiz da Mozilla, a política do Programa Raiz do Chrome, as informações do programa de certificados confiáveis e transparência de certificados da Apple e os requisitos do Programa Raiz Confiável da Microsoft ajudam a definir o ambiente de confiança no qual as ACs operam. As políticas específicas diferem, mas a ideia compartilhada é que a inclusão no armazenamento raiz é condicional ao comportamento confiável da AC.

O incidente da DigiCert mostra os limites dessa supervisão. Os programas raiz podem exigir relatórios, avaliar padrões, desconfiar de uma AC, exigir itens de ação e promover melhorias em toda a indústria. Eles não podem reimplantar os certificados de um hospital, atualizar os balanceadores de carga de uma operadora de telecomunicações, reescrever o processo de gerenciamento de mudanças de um cliente ou fazer um revendedor encaminhar avisos instantaneamente. O trabalho de prevenção de interrupções é distribuído.

Isso não torna os programas raiz passivos. Seus comentários públicos no Bugzilla foram importantes porque resistiram à criação privada de exceções e mantiveram pressão sobre os Requisitos Básicos. O comentário do Chrome de que não tinha autoridade para conceder exceções é uma declaração de responsabilidade. A discussão posterior da Mozilla sobre revisão da política de revogação atrasada mostrou que o incidente poderia realimentar a governança do programa raiz. Os fóruns públicos do programa raiz são onde as explicações das ACs se tornam revisáveis por mais do que o cliente afetado e a AC.

O CA/Browser Forum é outra camada. O fórum escreve os Requisitos Básicos através de consenso entre ACs e navegadores. A página dos Requisitos Básicos TLS não é, portanto, um estatuto externo imposto apenas à DigiCert. A DigiCert e outras ACs participam do ecossistema que cria as obrigações. Quando uma AC posteriormente considera a obrigação operacionalmente dolorosa, isso é um sinal para melhorar a agilidade do ecossistema, não uma prova de que a obrigação é arbitrária.

A questão de governança mais difícil é se os prazos de revogação devem ser mais flexíveis para não conformidade de baixa gravidade e risco de alta disponibilidade. Pessoas razoáveis na comunidade Web PKI discordam. Este artigo não resolve esse debate político. Ele identifica o fato de responsabilidade: na data do incidente, a DigiCert reconheceu um requisito de 24 horas e então completou a revogação em 120 horas. Esse descompasso é um evento de confiança pública.

O que a DigiCert controlava e o que os assinantes controlavam

A DigiCert controlava o caminho do código de validação, o processo de revisão de engenharia e conformidade, a resposta ao relatório de problema de certificado, a correção, o processo de identificação de certificados afetados, a notificação ao cliente, o relatório público de incidente, a execução da revogação e os itens de ação de acompanhamento. Ela também controlava se seus sistemas preservavam dados suficientes para distinguir exatamente quais validações usaram um underscore conforme. No registro público, essa precisão de dados estava ausente.

A DigiCert não controlava a implantação de certificados de cada assinante. Ela não controlava cada transferência de revendedor, cada conselho de mudança corporativo, cada limitação de appliance, cada arquitetura de cliente de nuvem ou cada janela de manutenção de hospital. Ela também não controlava sozinha os Requisitos Básicos. Ela era responsável por cumpri-los e por explicar quando não cumpria.

Os assinantes controlavam inventário, propriedade, automação, arquitetura de implantação, teste de renovação, escalação de fornecedor e prontidão de gerenciamento de mudanças. Um assinante que não pode substituir um certificado TLS público dentro de um dia tem um risco de disponibilidade, independentemente de o gatilho imediato ser culpa da DigiCert. O próximo gatilho pode ser um comprometimento de chave, política de certificado de curta duração, evento de desconfiança de emergência, exposição de chave privada ou erro de expiração.

Revendedores e provedores de serviços gerenciados controlavam a transferência entre o aviso da AC e os operadores de endpoint. Se eles recebiam avisos mas não os encaminhavam, ou não podiam mapeá-los para sistemas ativos, eles se tornavam parte da superfície de interrupção. Provedores de nuvem controlavam camadas de certificados gerenciados e comunicação com o cliente para serviços que operavam. Agências públicas como a CISA controlavam alertas públicos e orientação ao cliente, não os sistemas da AC.

Os usuários finais controlavam quase nada. Eles dependiam de navegadores e clientes para aplicar a confiança do certificado, de ACs para validar corretamente, de operadores de serviço para substituir certificados e de programas raiz para responsabilizar as ACs. Se um certificado era revogado e um serviço falhava, as escolhas do usuário eram parar de usar o serviço, aceitar o risco se o cliente permitisse desvio ou esperar. Essa assimetria é por que o ônus recai sobre as instituições.

Melhores evidências e controles para o próximo incidente

Um conjunto melhor de controles pós-incidente começa no design da validação. Toda AC deve manter testes executáveis que mapeiem diretamente para cada método de validação dos Requisitos Básicos que ela suporta. Se a redação do método exige um rótulo com prefixo de underscore, o teste deve falhar sem ele. Se vários produtos ou sistemas OEM implementam o mesmo método, eles devem compartilhar uma biblioteca de validação revisada para conformidade ou provar comportamento equivalente.

A publicação posterior do código de validação de controle de domínio pela DigiCert em github.com/digicert/domain-control-validation, com informações de pacote visíveis em Maven Central e documentação em javadoc.io, é relevante aqui. Material de implementação aberto pode ajudar clientes e a comunidade a entender o comportamento de validação, embora código aberto sozinho não prove configuração de produção ou elimine risco organizacional.

Em segundo lugar, os registros de emissão devem reter fatos críticos de conformidade. Uma AC deve ser capaz de responder, para cada certificado válido, qual método de validação foi usado, qual caminho do sistema o executou, qual registro DNS foi observado, se prefixos obrigatórios estavam presentes, quando a validação ocorreu, qual conta ou revendedor estava envolvido e quais certificados dependiam dessa validação. Essas informações devem ser consultáveis sob pressão de incidente sem precisar de trabalho improvisado de business intelligence.

Em terceiro lugar, a comunicação de revogação deve ser legível por máquina. Os assinantes devem poder puxar seriais afetados e requisitos de substituição através de APIs, painéis e ganchos de automação. E-mail é necessário mas insuficiente. Banners no console ajudam, mas podem perder operadores que não fazem login diariamente. Revendedores devem ter deveres contratuais e mecanismos técnicos para repassar avisos rapidamente.

Em quarto lugar, os assinantes devem manter uma lista de materiais de certificados. Deve incluir locais de certificados públicos e privados, proprietários de renovação, status de automação, armazenamento de chaves, serviços dependentes, runbooks de substituição e contatos de emergência. Os inventários de certificados devem ser testados substituindo certificados fora da temporada anual de renovação. Um runbook que nunca substituiu um certificado sob pressão é apenas uma esperança.

Em quinto lugar, os programas raiz e o CA/Browser Forum devem continuar a discussão pública sobre revogação atrasada sem permitir que a cultura privada de exceções se torne normal. Se as regras evoluírem, devem evoluir de forma transparente. Se não evoluírem, ACs e assinantes devem construir operações para cumpri-las.

A lição duradoura

O incidente de revogação da DigiCert em 2024 é uma lição compacta de como confiança e tempo de atividade colidem. Um caminho de validação perdeu um underscore obrigatório. A AC não conseguiu separar precisamente cada caso conforme do não conforme. As regras exigiam revogação rápida. Os clientes não tinham automação suficiente. Alguns operadores de serviços críticos enfrentaram interrupção. Um desafio legal apareceu. Os programas raiz foram consultados, mas não puderam renunciar às regras. A CISA alertou o público. A DigiCert eventualmente revogou os certificados TLS afetados em cinco dias e reconheceu causas organizacionais.

Os atacantes nesta história, se existiram, não são o ponto do registro público. O registro é sobre controle institucional. A DigiCert controlava validação e revogação. Os programas raiz controlavam a supervisão de confiança. Os assinantes controlavam a prontidão de implantação. Revendedores e provedores de nuvem controlavam caminhos de comunicação. Os usuários arcavam com as consequências.

O padrão prático é claro. Uma autoridade de certificação deve ser capaz de provar que cada método de validação suportado é implementado exatamente como exigido, que os registros de certificados preservam detalhes suficientes para remediação precisa e que a revogação de emergência pode ser executada sem necessidade de coleta de dados heroica. Os assinantes devem ser capazes de substituir certificados públicos rapidamente, repetidamente e através de automação. Os programas raiz devem manter a notificação de incidentes pública o suficiente para que as decisões de confiança sejam visíveis.

A credibilidade da Web PKI depende da parte desconfortável da regra: certificados emitidos incorretamente ou não conformes devem deixar a confiança rapidamente, mesmo quando isso é operacionalmente doloroso. A resposta não é fingir que a revogação será sempre indolor. A resposta é construir operações de certificado para que a próxima revogação obrigatória seja um fluxo de trabalho de manutenção controlado, não uma correria global em torno de um prazo.