Por que depender de uma única CA é um risco: Entrust, DigiCert, DigiNotar e o caso das múltiplas Autoridades Certificadoras

Toda a segurança do TLS público depende de uma premissa simples: quando seu navegador confia em uma Autoridade Certificadora (CA), ele confia em tudo que aquela CA emite. É um modelo de confiança transitiva — e é exatamente por isso que ele é frágil. O elo mais fraco não é o seu servidor nem a sua chave privada. É a própria CA.

A maioria das equipes escolhe uma CA, integra o fluxo de emissão e nunca mais pensa no assunto — até o dia em que essa CA falha. E CAs falham de três maneiras distintas, todas com histórico real e consequências que já tiraram sites do ar e empresas do mercado.

A gestão de certificados públicos é mais difícil do que parece

Antes dos casos, vale entender por que isso é operacionalmente complexo. Um certificado público não é só um arquivo que você instala e esquece. Ele carrega:

• Validação de domínio (DCV) que precisa ser feita e, cada vez mais, refeita a cada renovação — via DNS, HTTP ou e-mail.
• Uma cadeia de confiança que depende de raízes que os navegadores podem remover a qualquer momento, sem pedir sua opinião.
• Um ciclo de vida encurtando — com a ballot SC-081 do CA/Browser Forum, a validade máxima cai para 47 dias até 2029, multiplicando os eventos de renovação por certificado.
• Dependência de um terceiro — a CA — cuja saúde de compliance você não controla e raramente monitora.

É esse último ponto que a maioria subestima. E os três casos abaixo mostram por quê.

Caso 1 — Entrust: quando uma CA perde a confiança dos navegadores

Este é o caso mais recente e o mais instrutivo, porque não envolveu nenhum hacker. Em 27 de junho de 2024, o Google anunciou que o Chrome deixaria de confiar em novos certificados TLS da Entrust e da AffirmTrust, após uma série de falhas de compliance, compromissos de melhoria não cumpridos e progresso insuficiente diante de incidentes divulgados publicamente ao longo de seis anos.

Na prática: certificados Entrust com um Signed Certificate Timestamp (SCT) datado após 11 de novembro de 2024 deixaram de ser confiáveis no Chrome. A Mozilla seguiu com a distrust a partir de 1º de dezembro de 2024, e a Apple também estabeleceu suas próprias datas de corte. Servidores usando esses certificados passaram a exibir o aviso "Sua conexão não é particular" para os usuários.

A Entrust não era uma CA pequena ou obscura. Sua importância não vinha do volume de certificados emitidos, mas de quem eram seus clientes: governos, companhias aéreas, bancos e grandes corporações — organizações com receita na casa dos bilhões. Essas empresas foram forçadas a migrar de CA às pressas para evitar interrupção de serviço.

O ponto crítico: a decisão de distrust não estava sob controle de nenhum cliente da Entrust. Você podia ter feito tudo certo — chave protegida, certificado válido, deploy correto — e ainda assim ver seu site quebrar, porque a decisão foi de um terceiro (o Google) sobre outro terceiro (a Entrust).

Caso 2 — DigiCert: quando uma CA é obrigada a revogar em massa

Em julho de 2024, a DigiCert — uma das maiores e mais respeitadas CAs do mundo — precisou revogar certificados por uma falha no próprio processo de validação de domínio. O incidente afetou 83.267 certificados de 6.807 clientes, cerca de 0,4% das validações de domínio aplicáveis.

A causa foi técnica e específica: em um dos métodos de validação, o cliente configura um registro DNS CNAME com um valor aleatório fornecido pela DigiCert, que faz um lookup para confirmar que os valores batem. Devido a alterações introduzidas no sistema a partir de 2019, a DigiCert deixou de adicionar o prefixo underscore ao valor aleatório usado na validação via CNAME — uma falha que passou despercebida por anos.

O mais grave foi o prazo. As regras do ecossistema obrigavam a revogação em 24 horas, e a DigiCert deixou claro que todos os certificados afetados seriam revogados até 3 de agosto de 2024, 19:30 UTC, sem exceção. Alguns clientes chegaram a entrar com ações judiciais para tentar bloquear a revogação, e a CISA (agência de cibersegurança dos EUA) emitiu um alerta sobre possíveis interrupções em sites, serviços e aplicações.

Repare na assimetria: uma mudança interna de UX na DigiCert, cinco anos antes, resultou em milhares de organizações tendo 24 horas para trocar certificados ou sair do ar. Nenhum desses clientes tinha visibilidade ou controle sobre a falha.

Caso 3 — DigiNotar: quando uma CA é comprometida de verdade

O caso canônico de CA hackeada aconteceu em 2011, e mudou a internet para sempre. Hackers invadiram a CA holandesa DigiNotar e emitiram mais de 531 certificados fraudulentos, incluindo um para *.google.com.

O certificado falso do Google não foi curiosidade acadêmica. Ele foi usado para interceptar as comunicações de Gmail de cerca de 300.000 pessoas no Irã — um ataque man-in-the-middle em escala estatal contra dissidentes, ativistas e jornalistas.

A falha de origem foi banal: a invasão começou por uma instalação desatualizada de DotNetNuke — uma vulnerabilidade conhecida com patch disponível — e o servidor web público da DigiNotar estava no mesmo domínio Windows que os servidores da CA, então um servidor comprometido significou todos comprometidos. A empresa tinha HSMs, mas HSMs protegem contra roubo físico, não contra acesso aparentemente autorizado.

O desfecho foi terminal. Diferente da Comodo, que sobreviveu à sua brecha, a DigiNotar foi completamente destruída: os navegadores revogaram a confiança em todos os seus certificados, o governo holandês assumiu o controle e a empresa declarou falência em semanas. Da brecha à falência foram 42 dias. Esse episódio foi um dos motores da criação do Certificate Transparency, o mesmo mecanismo que hoje permite monitorar emissões não autorizadas.

O padrão comum: você não controla o elo mais fraco

Três casos, três causas completamente diferentes — falha de compliance, erro operacional de validação, e invasão criminosa. Um único fator em comum: em nenhum deles o cliente da CA tinha controle sobre o que deu errado, mas todos sofreram a consequência.

É por isso que uma pesquisa da AppViewX apontou que 90% das empresas da Fortune 1000 usam mais de 3 Autoridades Certificadoras — não por acaso, mas como estratégia de resiliência. Depender de uma única CA é concentrar em um terceiro um risco que pode tirar toda a sua operação do ar da noite para o dia.

Por que múltiplas CAs mudam o jogo

Trabalhar com mais de uma CA transforma um evento catastrófico em um evento gerenciável:

• Se uma CA perde a confiança dos navegadores (Entrust), você reemite os certificados afetados pela CA alternativa, sem migração de emergência.
• Se uma CA precisa revogar em massa (DigiCert), os certificados críticos emitidos por outra CA continuam válidos enquanto você reemite os afetados.
• Se uma CA é comprometida (DigiNotar), você não tem 100% da sua superfície de confiança concentrada no ponto que falhou.

A questão deixa de ser "qual é a melhor CA?" e passa a ser "como eu opero com várias CAs sem multiplicar o trabalho manual por três?".

O que isso exige do seu CLM

Suportar múltiplas CAs só é viável na prática se a plataforma de gerenciamento de certificados (CLM) absorver a complexidade em vez de repassá-la para a equipe. Na hora de escolher um CLM, verifique se ele:

Suporta múltiplas CAs nativamente. Emissão via Let's Encrypt, DigiCert, AD CS e outras a partir da mesma interface, sem integrações separadas e desconexas para cada uma.

Automatiza a validação de domínio (DCV). Com o SC-081 exigindo revalidação a cada renovação, DCV manual não escala. O CLM precisa criar, verificar e limpar os registros de validação automaticamente — seja DNS-01, HTTP-01 ou CNAME.

Permite trocar de CA sem trocar de processo. Migrar um certificado de uma CA para outra deveria ser uma mudança de configuração, não um projeto. Se cada CA exige um fluxo operacional distinto, você não tem redundância real.

Monitora a superfície inteira, não só o que você emitiu. Descoberta contínua e monitoramento de Certificate Transparency logs para detectar certificados emitidos para seus domínios — inclusive emissões não autorizadas, a lição direta do DigiNotar.

Automatiza o deploy, não só a emissão. Reemitir por uma CA alternativa não adianta se o certificado novo não é redistribuído automaticamente para todos os pontos que o consomem.

A resiliência de CA não é um recurso premium para grandes corporações. É a diferença entre um incidente de CA ser uma troca de configuração de dez minutos ou uma corrida de 24 horas contra o relógio, como viveram milhares de clientes da DigiCert em agosto de 2024.