Prazo de revogação da DigiCert transformou a validação de certificado em um teste de responsabilidade de uptime

Resumo

• A DigiCert informou no Mozilla Bugzilla que verificou alguns domínios usando um valor aleatório em um registro CNAME sem o prefixo de sublinhado exigido, 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 armazenava adequadamente se o sublinhado estava presente.
• O problema de revogação foi imediato. Os Baseline Requirements do CA/Browser Forum exigem a revogação dentro de prazos definidos para certificados emitidos incorretamente, e o relatório de incidente de revogação tardia da DigiCert afirma que revogou todos os 83.267 certificados TLS afetados em 120 horas, em vez do prazo de 24 horas exigido pelas regras vigentes na época.
• O evento não foi apenas um erro de codificação de uma CA. Expôs a fragilidade do inventário de certificados dos assinantes, os limites de comunicação através de revendedores e contas corporativas, a pressão legal decorrente 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 era distribuído. A DigiCert controlava a implementação da validação, a identificação dos certificados, a notificação aos clientes, 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 dos clientes. Os assinantes controlavam seus inventários, automação, janelas de mudança e implantação específica de cada serviço. Os usuários finais não controlavam quase nenhum risco.
• A lição de responsabilidade é que as autoridades certificadoras não podem tratar a revogação como um evento burocrático raro, e os assinantes não podem tratar os certificados TLS publicamente confiáveis 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 sublinhado faltante se tornou um problema de continuidade global

O incidente da DigiCert é fácil de trivializar se for reduzido a pontuação. A questão técnica envolvia um prefixo de sublinhado exigido 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 publicamente confiáveis, muitos implementados em serviços de nuvem, redes de telecomunicações, ambientes de saúde, aplicações empresariais e sites voltados para o cliente.

O registro público do incidente da DigiCert noMozilla Bugzilla bug 1910322é a âncora factual. A DigiCert informou 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. Descreveu vários processos de verificação relacionados a DNS e afirmou que uma revisão de código encontrou um caminho onde um certificado poderia ser emitido quando o valor aleatório fosse usado como host em um registro CNAME sem antes adicionar um sublinhado. Mais tarde no mesmo bug, o relatório de incidente da DigiCert disse que o impacto estava limitado a emissores usando seu sistema de validação OEM, enquanto os caminhos de validação através do CertCentral e CIS, seu mecanismo 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 do incidente. 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. Explicou que isso provavelmente superestimava o conjunto verdadeiramente afetado porque os controles do sistema OEM não armazenavam adequadamente se um sublinhado estava presente. Essa frase é a peça central da responsabilidade.

O sistema podia identificar uma população de risco, mas não conseguia provar de forma limpa quais certificados tinham a forma compatível. Em um sistema de confiança, a incerteza sobre a conformidade pode se tornar uma obrigação de revogação.

A razão de segurança para o sublinhado 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 sublinhado ajuda a criar um namespace de validação especial que nomes de host comuns e muitos serviços de subdomínio delegados podem evitar. A falta de um sublinhado pode minar uma suposição usada para evitar 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 se enquadra no 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 for aceita do local errado, ou se um marcador de limite necessário estiver faltando, a CA pode tratar um posicionamento DNS mais fraco como prova de controle. O certificado então dá às partes confiáveis um sinal confiável pelo navegador para um nome. O poder de emitir está, portanto, vinculado ao poder de interpretar corretamente a delegação DNS.

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

OsBaseline Requirements TLS do CA/Browser Forumsão o conjunto de regras público 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 publicamente confiáveis. O artigo não precisa citar todos os requisitos para explicar a estrutura de responsabilidade: se um certificado foi emitido incorretamente ou a validação não estava em conformidade com os Baseline Requirements, a CA deve revogar dentro do prazo aplicável, a menos que as próprias regras permitam outro caminho.

O relatório de revogação tardia da DigiCert noMozilla Bugzilla bug 1910805declara 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 programas raiz e a comunidade sobre o impacto, decidiu adiar 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 Baseline Requirements atuais.

Essa admissão é importante porque separa dois incidentes. O Bug 1910322 tratou da não conformidade da validação de domínio. O Bug 1910805 tratou da revogação tardia. 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 ao vivo.

A distinção impede um argumento superficial. Pode-se dizer que a DigiCert deveria simplesmente ter revogado imediatamente e cumprido a regra. Essa é a posição política limpa. Também se pode dizer que a revogação imediata teria interrompido serviços críticos e, portanto, o adiamento foi 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 confiáveis contra certificados inválidos ou emitidos incorretamente.

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

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 Baseline Requirements do CA/Browser Forum e que esses requisitos são orientados por consenso, e não de propriedade de um programa raiz. Apolítica do Chrome Root Programfornece o contexto mais amplo do navegador-raiz: uma CA participa da raiz de confiança 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 renúncia mágica das regras públicas.

APolítica de Root Store da Mozillae aorientação de resposta a incidentes de CA da Mozillacumprem uma função semelhante. Elas tornam o relato de incidentes e a capacidade de resposta parte da governança da confiança. Elas não operam os servidores dos assinantes e não inventariam certificados dentro da infraestrutura do cliente. Elas 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 franco sobre as causas organizacionais

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

Essa franqueza importa porque os incidentes da Web PKI são frequentemente tratados como defeitos de conformidade restritos. 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 do sistema organizacional. A engenharia crítica para a conformidade não pode viver em um mundo mental separado da interpretação da 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 os sistemas enquanto expõe defeitos herdados de limites de fluxo de trabalho antigos.

O mesmo registro do Bugzilla inclui a liderança da DigiCert reconhecendo que as equipes internas nem sempre trabalhavam juntas como precisavam e que o mundo que dependia deles tornava isso inaceitável. Isso não é uma constatação legal, mas é uma forte admissão institucional: uma autoridade certificadora publicamente confiável 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 CA.

A DigiCert também disse que o caminho afetado estava limitado ao sistema de validação OEM, não ao CertCentral e CIS. Esse limite é importante. 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 de 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 compatíveis de não compatíveis após o fato?

A decisão de superestimar foi compreensível. Se a CA não pode determinar quais certificados foram emitidos com o sublinhado ausente, revogar todos os certificados no conjunto de risco é mais seguro para a confiança das partes confiáveis do que deixar certificados possivelmente não compatíveis ativos. Mas a revogação excessiva aumenta a interrupção para o assinante e a carga de suporte. Esse é o custo da precisão forense insuficiente nos dados de emissão de certificados.

A lição de responsabilidade para as CAs é, portanto, dupla. Primeiro, as implementações de validação precisam de cobertura de testes rigorosa em relação aos Baseline Requirements. Segundo, os sistemas de emissão precisam de registros probatórios detalhados o suficiente para apoiar a remediação precisa. Uma CA 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 a política em dor

A atualização inicial do Bugzilla da DigiCert disse que 83.267 certificados afetavam 6.807 assinantes. Também disse que muitos clientes operando infraestrutura crítica, redes vitais de telecomunicações, serviços de nuvem e setores 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 uma evidência de que grandes partes do ecossistema de assinantes estavam operacionalmente despreparadas para a substituição rápida.

O alerta daCISA sobre as revogações de certificados da DigiCertmostra 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 verificar sua conta DigiCert e reemitir ou trocar as chaves dos certificados. Sua atualização de 31 de julho apontou os clientes para informações e prazos atualizados e incentivou o contato com a DigiCert se não fosse possível reemitir ou trocar a chave até o novo prazo de revogação.

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

Para pequenas e médias organizações, a dor pode ser mais aguda. Uma PME pode ter um certificado instalado em um painel de hospedagem, firewall, aparelho 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 de forma alguma. A substituição pode exigir aprovação de mudança fora do horário comercial ou um ticket 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 manifesto "continuidade de serviço para PMEs" se encaixa. O incidente ameaçou a disponibilidade por meio 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, usuários verão avisos e serviços que nunca pareceram "infraestrutura de certificados" ficarã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 CA os emitiu, quando expiram, como substituí-los, quem aprova a mudança e se existe automação. Mas a responsabilidade da CA também é real. Uma CA que sabe que a revogação é obrigatória deve projetar validação, inventário, notificação e ferramentas para o cliente para substituição emergencial, não apenas renovações comuns.

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

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

As autoridades certificadoras muitas vezes operam através de hierarquias de contas, revendedores, equipes de compras corporativas, provedores de serviços gerenciados e intermediários de nuvem. O assinante que controla o ponto final ativo pode não ser o titular da conta que recebe os e-mails da CA. Um revendedor pode receber um aviso e precisar encaminhá-lo. Uma equipe central de segurança pode ser proprietária da conta da CA enquanto os proprietários das aplicações são responsáveis pela 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 chegar aos contatos técnicos, contatos da conta, contatos de revendedores e endpoints legíveis por máquina. Devem identificar os números de série dos certificados afetados, domínios, produtos, etapas de substituição, prazos e a consequência da inação. Devem estar disponíveis através do console da conta, API, e-mail e canais de status. Devem facilitar para o assinante exportar um inventário completo dos afetados.

OAviso de Incidente de Revogaçãoda DigiCert, vinculado pela CISA e na discussão da Mozilla, cumpriu o papel de aviso voltado ao cliente. O portal de status da DigiCert emstatus.digicert.comtambém foi referenciado pela CISA para cronogramas atualizados. Essas páginas são importantes mesmo quando o acesso ao arquivo é imperfeito porque agências públicas e discussões de programas raiz apontaram os clientes para elas durante o incidente.

A comunicação também precisava evitar criar uma falsa promessa de que a revogação era opcional. Um participante do Bugzilla criticou a ideia de solicitações de adiamento por parte dos clientes porque poderia sugerir que a revogação obrigatória é negociável. Mais tarde, a própria DigiCert disse que não gostaria de criar um formulário de solicitação de adiamento porque as revogações tardias não são permitidas e tal formulário poderia transmitir que são permitidas. Essa tensão é real. Uma CA precisa ouvir sobre o risco à infraestrutura crítica, mas a regra existe para proteger as partes confiáveis 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 CA pode revogar sem negociação prolongada. Devem ter automação para substituir rapidamente. As CAs devem ter inventários precisos e avisos multicanal. 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 o lado frágil da revogação obrigatória

O relatório de revogação tardia diz que a DigiCert recebeu um aviso de que um cliente havia entrado com um pedido de ordem de restrição temporária contra as revogações. O processo público,Alegeus Technologies LLC v. DigiCert, faz parte do registro do incidente porque mostra como a pressão pela continuidade do assinante pode colidir com as obrigações da CA. 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 pedido judicial temporário não é uma decisão final de que a DigiCert estava certa ou errada, ou que o cliente tinha um direito duradouro de bloquear a revogação. É uma evidência da pressão durante o incidente. Um assinante que enfrenta tempo de inatividade pode recorrer a ferramentas legais se acreditar que a revogação causará danos. Uma CA que enfrenta obrigações de programas raiz pode precisar defender sua autoridade para revogar sob acordos de assinatura e regras de confiança pública.

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

Portanto, os acordos de assinatura e contratos corporativos devem ser explícitos. Uma CA deve manter o direito de revogar certificados quando exigido pelos Baseline Requirements ou pela política do programa raiz. Os clientes devem saber que a inconveniência operacional não é uma garantia de adiamento. Ao mesmo tempo, as CAs devem projetar programas de cliente para que a revogação emergencial não chegue como uma surpresa após anos tratando os certificados como ativos manuais.

O incidente também sugere que a prontidão legal faz parte da prontidão para incidentes da CA. Uma CA 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 os programas raiz sem pedir-lhes autoridade que não têm. O relógio é curto demais para improvisação.

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

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

O ACME, definido naRFC 8555, foi criado para automatizar a emissão e o gerenciamento de certificados. A automação não se limita ao ACME, e nem todo sistema corporativo 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. Ovoto SC-063 do CA/Browser Forum sobre certificados de vida curta e incentivos à automaçãomostra que o setor já estava pressionando por vidas 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 a resiliência em toda a Web PKI para que os eventos de revogação sejam menos disruptivos, e observaram que a automação e as abordagens do tipo ARI têm benefício limitado sem ampla adoção por CAs e assinantes. Orascunho da extensão ACME Renewal Informationé relevante porque visa permitir que as CAs sinalizem informações de tempo de renovação para clientes ACME. Não é uma solução completa para todos os problemas de revogação tardia, mas reflete a direção certa: coordenação de renovação e substituição legível por máquina.

A automação também importa para o inventário. Um assinante não pode substituir o que não consegue 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 da CA, 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 CAs, a automação deve incluir a descoberta de certificados afetados e a notificação ao cliente. No Bugzilla, a discussão da DigiCert observou que a coleta de informações de certificado e contato envolveu um data lake central e a equipe de inteligência de negócios. Esse detalhe deveria preocupar qualquer CA. Se uma equipe fora da resposta normal a incidentes for 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 a 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 credíveis se as CAs e os assinantes puderem executar a substituição rápida sem esforço manual heroico a cada vez.

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

Em um ambiente grande, essas verificações precisam de varredura e atestação do proprietário do serviço, não 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. A falta de qualquer uma dessas etapas pode transformar uma correção de conformidade da CA em tempo de inatividade persistente para o 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 silenciosa de renovação feita por um único proprietário de 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 as solicitações 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 chegue aos usuários.

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

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

O registro público apoia uma constatação de validação não conforme e revogação em massa. Ele não apoia, a partir das fontes usadas aqui, uma constatação ampla de que atacantes exploraram o bug da DigiCert para obter certificados para serviços importantes. Os participantes do Bugzilla perguntaram se a DigiCert havia verificado exploração e discutiram possíveis cenários de risco envolvendo serviços que permitem aos usuários criar subdomínios arbitrários. Essas perguntas foram importantes, mas perguntas não são constataçõ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 necessário, a CA deve tratar os certificados emitidos por esse 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 confiáveis não podem investigar cada evento de emissão.

Osite público do CCADBfornece contexto para a infraestrutura de transparência usada pelas raízes de confiança e CAs, enquanto ocrt.she os logs de Transparência de Certificados ajudam a comunidade a inspecionar os certificados emitidos. No tópico do Bugzilla, membros da comunidade analisaram listas de certificados fornecidas pela DigiCert em relação aos dados de transparência de certificados. Esta é uma força da Web PKI: existem evidências públicas 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 estivesse superestimado. Essa é 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 a emissão indevida através de melhores controles de validação e reduzir a interrupção 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 que vê um aviso de certificado revogado não sabe se o certificado subjacente foi ativamente abusado, emitido por um caminho não conforme ou pego em uma superestimativa 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 a comunicação com o cliente e a 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 dos avisos.

Os programas raiz eram supervisores, não operadores da disponibilidade do cliente

Os programas raiz da Mozilla, Chrome, Apple e Microsoft moldam o ecossistema de CAs publicamente confiáveis. APolítica de Root Store da Mozilla, apolítica do Chrome Root Program, asinformações sobre Transparência de Certificados e programa de certificados confiáveis da Applee osrequisitos do Programa de Raiz Confiável da Microsoftajudam a definir o ambiente de confiança em que as CAs operam. As políticas específicas diferem, mas a ideia compartilhada é que a inclusão na raiz de confiança está condicionada a um comportamento confiável da CA.

O incidente da DigiCert mostra os limites dessa supervisão. Os programas raiz podem exigir relatórios, avaliar padrões, desconfiar de uma CA, exigir itens de ação e impulsionar melhorias em toda a indústria. Eles não podem reimplantar os certificados de um hospital, atualizar os balanceadores de carga de uma empresa 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 importaram porque resistiram a exceções privadas e mantiveram a pressão sobre os Baseline Requirements. 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 a revisão da política de revogação tardia mostrou que o incidente poderia retroalimentar a governança do programa raiz. Os fóruns públicos dos programas raiz são onde as explicações das CAs se tornam revisáveis por mais do que o cliente afetado e a CA.

O CA/Browser Forum é outra camada. O fórum escreve os Baseline Requirements por consenso entre CAs e navegadores. A página dosBaseline Requirements TLSnão é, portanto, um estatuto externo imposto apenas à DigiCert. A DigiCert e outras CAs participam do ecossistema que cria as obrigações. Quando uma CA posteriormente acha 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 da Web PKI discordam. Este artigo não resolve esse debate político. Ele identifica o fato de responsabilidade: na época do incidente, a DigiCert reconheceu um requisito de 24 horas e depois completou a revogação em 120 horas. Essa incompatibilidade é 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. Também controlava se seus sistemas preservavam dados suficientes para distinguir exatamente quais validações usavam um sublinhado compatível. No registro público, essa precisão de dados estava ausente.

A DigiCert não controlava a implantação de certificados de cada assinante. Não controlava cada transferência de revendedor, cada conselho de mudanças corporativo, cada limitação de aparelho, cada arquitetura de cliente de nuvem ou cada janela de manutenção de hospital. Também não controlava sozinha os Baseline Requirements. Era responsável por cumpri-los e por explicar quando não o fez.

Os assinantes controlavam inventário, propriedade, automação, arquitetura de implantação, teste de renovação, escalonamento de fornecedores e prontidão para 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, seja ou não o gatilho imediato culpa da DigiCert. O próximo gatilho pode ser um comprometimento de chave, política de certificado de vida curta, evento de desconfiança emergencial, 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 CA e os operadores de endpoint. Se recebiam avisos mas não os encaminhavam, ou não conseguiam mapeá-los para sistemas ativos, tornavam-se parte da superfície de interrupção. Os provedores de nuvem controlavam camadas de certificados gerenciados e a comunicação com o cliente para os serviços que operavam. Agências públicas como a CISA controlavam o alerta público e a orientação ao cliente, não os sistemas da CA.

Os usuários finais não controlavam quase nada. Dependiam dos navegadores e clientes para impor a confiança nos certificados, das CAs para validar corretamente, dos operadores de serviço para substituir os certificados e dos programas raiz para responsabilizar as CAs. Se um certificado fosse revogado e um serviço falhasse, as escolhas do usuário eram parar de usar o serviço, aceitar o risco se um cliente permitisse contornar ou esperar. Essa assimetria é o porquê de o ônus recair 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. Cada CA deve manter testes executáveis que mapeiam diretamente para cada método de validação dos Baseline Requirements que ela suporta. Se a redação do método exige um rótulo com prefixo de sublinhado, 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 emgithub.com/digicert/domain-control-validation, com informações do pacote visíveis emMaven Centrale documentação emjavadoc.io, é relevante aqui. Materiais de implementação abertos podem ajudar clientes e a comunidade a entender o comportamento da validação, embora o código aberto por si só não prove a configuração de produção nem elimine o risco organizacional.

Em segundo lugar, os registros de emissão devem reter fatos críticos de conformidade. Uma CA deve ser capaz de responder, para cada certificado válido, qual método de validação foi usado, qual caminho do sistema o realizou, qual registro DNS foi observado, se os prefixos exigidos 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 necessidade de trabalho improvisado de inteligência de negócios.

Em terceiro lugar, a comunicação de revogação deve ser legível por máquina. Os assinantes devem poder obter os números de série afetados e os requisitos de substituição através de APIs, painéis e ganchos de automação. O e-mail é necessário, mas insuficiente. Banners no console ajudam, mas podem não alcançar operadores que não fazem login diariamente. Os 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 certificado. Deve incluir localizações de certificados públicos e privados, proprietários de renovação, status de automação, armazenamento de chaves, serviços dependentes, manuais 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 manual 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 tardia sem permitir que a cultura de exceção privada se torne normal. Se as regras evoluírem, devem evoluir de forma transparente. Se não evoluírem, as CAs e os assinantes devem construir operações para atendê-las.

A lição duradoura

O incidente de revogação da DigiCert em 2024 é uma lição compacta sobre como confiança e disponibilidade colidem. Um caminho de validação perdeu um sublinhado exigido. A CA não conseguiu separar precisamente todos os casos compatíveis dos não compatíveis. As regras exigiam revogação rápida. Os clientes careciam de 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 podiam renunciar às regras. A CISA alertou o público. A DigiCert eventualmente revogou os certificados TLS afetados ao longo de 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 a validação e a revogação. Os programas raiz controlavam a supervisão da confiança. Os assinantes controlavam a prontidão de implantação. Revendedores e provedores de nuvem controlavam os caminhos de comunicação. Os usuários arcavam com as consequências.

O padrão prático é claro. Uma autoridade certificadora deve ser capaz de provar que cada método de validação suportado está implementado exatamente como exigido, que os registros de certificado preservam detalhes suficientes para remediação precisa e que a revogação emergencial pode ser executada sem necessidade de coleta heroica de dados. Os assinantes devem ser capazes de substituir certificados públicos rapidamente, repetidamente e através de automação. Os programas raiz devem manter os relatórios de incidentes públicos 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.