Certificados fantasma: o risco dos certificados que ninguém sabe que existem

Existe um certificado na sua infraestrutura agora que você não sabe que existe. Foi emitido dois anos atrás por alguém que já saiu da empresa, aponta para um load balancer que nunca foi documentado, e vai expirar em uma data que não está em nenhum calendário. Você só vai descobrir que ele existia no dia em que ele quebrar algo.

Esse é o problema dos certificados fantasma — e não é um cenário hipotético. É a causa raiz de alguns dos maiores incidentes de segurança e indisponibilidade já documentados. O ponto em comum de quase todos eles não é sofisticação técnica: é que ninguém sabia que o certificado estava lá.

Por que certificados desaparecem do radar

Certificados não somem por negligência de uma pessoa. Eles somem por características estruturais de como a infraestrutura cresce:

• Rotatividade de times. Quem emitiu o certificado saiu, e o conhecimento sobre ele saiu junto. Não há transferência formal de "certificados que eu gerencio".
• Emissão descentralizada. Qualquer time com acesso a uma CA — ou ao Let's Encrypt — pode emitir um certificado sem passar por um processo central. Certificados emitidos fora de processos aprovados passam despercebidos, ampliando a superfície de ataque e criando lacunas de compliance que auditores apontam.
• Ambientes híbridos. Certificados espalhados por on-premise, cloud e ambientes híbridos ficam sem rastreamento, criando pontos cegos perigosos que disparam indisponibilidades inesperadas.
• Escala pura. O inventário cresce mais rápido que a governança. A empresa média hoje gerencia mais de 250.000 identidades de máquina, contra cerca de 150.000 apenas dois anos atrás. Planilha não acompanha esse volume.

O resultado é o que a indústria chama de certificate sprawl: certificados demais, espalhados por lugares demais, sob responsabilidade de ninguém em particular.

O custo real: não é um problema de nicho

Falha de certificado não é um evento raro de borda. É uma linha recorrente nos registros de incidente das empresas. A pesquisa State of Machine Identity 2026 da Keyfactor apontou que mais de 70% das organizações tiveram ao menos uma indisponibilidade relacionada a certificados no último ano, que normalmente leva mais de quatro horas para identificar, remediar e recuperar, e que um único incidente costuma mobilizar de 11 a 20 pessoas entre times de segurança, infraestrutura e aplicações antes de ser resolvido.

O custo financeiro é significativo. Indisponibilidades causadas por expiração de certificado custam às empresas entre 500 mil e 5 milhões de dólares em média por incidente, e levam mais de cinco horas para serem identificadas e remediadas.

E não são só empresas pequenas ou mal estruturadas. A lista de quem já foi atingido é reveladora:

• Spotify: um certificado expirado causou indisponibilidade no Megaphone, a plataforma de podcasts da empresa.
• LinkedIn: a expiração de um certificado de subdomínio de país afetou a acessibilidade e a segurança dos serviços.
• Microsoft Teams: sofreu uma indisponibilidade amplamente noticiada em fevereiro de 2020, atribuída a um certificado expirado, que interrompeu reuniões de usuários.
• Governo dos EUA: 80 certificados expiraram, tornando diversos sites do governo inacessíveis.

O achado mais revelador vem da análise dessas revisões de incidente: o certificado quase nunca era desconhecido — apenas não era claramente responsabilidade de ninguém renová-lo.

Quando o certificado fantasma vira brecha de segurança: o caso Equifax

O exemplo definitivo de por que descoberta importa não é uma indisponibilidade. É uma das maiores violações de dados da história.

Em 2017, atacantes entraram na rede da Equifax por uma vulnerabilidade conhecida do Apache Struts. Isso, por si só, teria sido contido — se o monitoramento de tráfego estivesse funcionando. Não estava. O dispositivo usado para monitorar o tráfego de rede da aplicação ACIS ficou inativo por 19 meses por causa de um certificado de segurança expirado.

O mecanismo é preciso e assustador: as ferramentas de monitoramento deveriam descriptografar e inspecionar o tráfego saindo da rede, mas sem um certificado válido não conseguiam. A exfiltração criptografada dos atacantes parecia tráfego HTTPS normal. Os atacantes operaram dentro da rede por 76 dias, sem serem vistos.

O desfecho quando o certificado foi finalmente renovado é a lição inteira em uma frase: em 29 de julho de 2017, a Equifax atualizou o certificado expirado e imediatamente notou tráfego web suspeito. O monitoramento voltou a enxergar no exato momento em que o certificado foi corrigido — tarde demais.

E o certificado expirado não era um caso isolado. Na época da violação, a Equifax havia deixado mais de 300 certificados de segurança expirarem, incluindo 79 certificados que monitoravam domínios críticos para o negócio. A violação afetou cerca de 147,9 milhões de pessoas e resultou no maior acordo por violação de dados da história dos EUA à época, entre 575 e 700 milhões de dólares.

Um certificado que ninguém estava monitorando cegou o sistema que existia justamente para detectar o ataque.

O agravante que está chegando: SC-081

Se gerenciar certificados desconhecidos já é difícil hoje, a matemática está prestes a piorar. Com a ballot SC-081 do CA/Browser Forum, a validade máxima dos certificados TLS públicos cai para 47 dias até 2029. Com a validade caindo para 47 dias em março de 2029, processos manuais de renovação vão entrar em colapso sob o volume, tornando a automação inegociável.

Cada certificado fantasma que hoje expira uma vez por ano vai passar a expirar cerca de oito vezes por ano. Um inventário incompleto, que já é um risco anual, se torna um risco quase mensal.

Por que descoberta é o pré-requisito de tudo

Aqui está o princípio que amarra todos esses casos: você não pode renovar, automatizar, monitorar ou proteger um certificado que não sabe que existe. Toda estratégia de gestão de certificados que começa pela renovação ou pela automação está construindo sobre uma base furada, porque cobre apenas os certificados já conhecidos — que nunca são todos.

Descoberta é o passo zero. E descoberta eficaz precisa cobrir os lugares onde os fantasmas se escondem:

Múltiplas fontes, não uma só. Um certificado pode estar em um servidor on-premise, num load balancer, num bucket de cloud, ou visível apenas nos Certificate Transparency logs. Descobrir só o que está numa fonte é continuar cego para as outras.

Scan de rede ativo. Varrer as portas TLS da infraestrutura (443, 8443 e outras) revela certificados efetivamente em uso que não estão em nenhum inventário — inclusive os que apontam para aquele load balancer não documentado.

CT logs. Os Certificate Transparency logs registram publicamente certificados emitidos para seus domínios. Consultá-los revela emissões que aconteceram fora do seu processo — inclusive as não autorizadas.

Descoberta contínua, não pontual. Um inventário feito uma vez está desatualizado no dia seguinte. Novos certificados são emitidos o tempo todo. Descoberta precisa ser um processo recorrente, com detecção de delta — o que apareceu de novo desde a última varredura.

Da descoberta para a ação. Descobrir um certificado só tem valor se isso alimenta o próximo passo: monitoramento de expiração, renovação automática e deploy. Descoberta que gera uma lista estática que ninguém age é só documentação do problema, não solução.

O valor de uma boa descoberta é medido em quão rápido ela transforma "não sabíamos que isso existia" em "isso está sob controle". Quando esse ciclo leva 15 minutos em vez de 19 meses, o certificado fantasma deixa de ser uma bomba-relógio e vira só mais um item gerenciado.

Este é um tema sensível quando envolve incidentes de segurança reais. Os casos citados são de domínio público e servem para ilustrar riscos operacionais de gestão de certificados.