Seu servidor pode estar confiando em certificados falsos. Veja como testar e corrigir.

Seu servidor pode estar confiando em certificados falsos. Veja como testar.

Imagine receber uma ligação de alguém que se apresenta como funcionário do seu banco. A pessoa conhece os procedimentos, passa informações convincentes e parece legítima.

Mas é um golpista.

Na internet, algo parecido pode acontecer com os certificados digitais. Eles ajudam seu computador a verificar se um site é realmente quem diz ser.

Foi justamente esse mecanismo de confiança que entrou em risco com o incidente da eMudhra (emSign), divulgado em outubro de 2026.

O que aconteceu?

As chaves privadas de oito certificados intermediários da eMudhra foram comprometidas.

Com essas chaves, um atacante poderia criar certificados aparentemente legítimos para domínios que não controla.

Na prática, isso abre espaço para ataques de man-in-the-middle (MITM), nos quais um criminoso intercepta a comunicação entre você e um serviço.

Isso não significa que seu servidor foi invadido. Significa que ele pode estar confiando em certificados que não deveria.

A solução é atualizar os certificados de confiança e verificar se o sistema passou a rejeitar os comprometidos.

1. Como saber se você está vulnerável?

Os pesquisadores disponibilizaram um endereço para testar essa falha.

No Linux ou macOS, execute:

curl https://dv-g3b-emudhra.we-have-a-problem.com/ 

Se aparecer:

Your client successfully connected to the site. That's bad! 

Seu curl aceitou a cadeia comprometida. É necessário corrigir.

O resultado esperado em um ambiente corrigido é:

curl: (60) SSL certificate problem 

Esse erro é uma boa notícia: significa que o certificado foi rejeitado.

Erros de DNS ou timeout não comprovam que o sistema está protegido.

2. Como corrigir no Linux

Primeiro, descubra qual distribuição está utilizando:

cat /etc/os-release 

Para identificar a arquitetura do processador:

uname -m 

• x86_64: normalmente Intel ou AMD.
• aarch64: arquitetura ARM64, como a Orange Pi.

Ubuntu e Debian

Descubra a versão instalada dos certificados:

dpkg-query -W ca-certificates 

Confira qual versão está disponível para atualização:

apt-cache policy ca-certificates 

Agora atualize:

sudo apt update sudo apt install --only-upgrade ca-certificates sudo update-ca-certificates --fresh 

Algumas versões corrigidas de referência:

Se o sistema não oferecer uma versão corrigida, revise os repositórios de segurança antes de prosseguir.

3. Como corrigir no macOS

No macOS, existe um detalhe: o curl nativo da Apple pode utilizar certificados diferentes dos utilizados pelo Homebrew.

Descubra qual versão está sendo executada:

which curl curl --version 

Se aparecer /usr/bin/curl, você está utilizando a versão fornecida pela Apple.

Uma alternativa é instalar e atualizar o curl pelo Homebrew:

brew update brew install ca-certificates curl brew upgrade ca-certificates curl 

Depois, configure o terminal para priorizá-lo:

echo 'export PATH="$(brew --prefix)/opt/curl/bin:$PATH"' >> ~/.zshrc source ~/.zshrc 

Confirme:

which curl 

O caminho deve apontar para o Homebrew, não para /usr/bin/curl.

Importante: isso não corrige automaticamente o curl nativo da Apple nem outros aplicativos. Eles precisam ser verificados separadamente.

4. Como validar a correção

Execute os dois testes disponibilizados pelos pesquisadores:

for domain in \ dv-g3b-emudhra.we-have-a-problem.com \ dv-g3b-aaa-emudhra.we-have-a-problem.com do echo "Testando: $domain" curl --noproxy '*' -sS \ --connect-timeout 10 --max-time 20 \ "https://$domain/" \ -o /dev/null \ -w 'HTTP: %{http_code} | Verify: %{ssl_verify_result}\n' done 

O resultado esperado para ambos é semelhante a:

curl: (60) SSL certificate problem HTTP: 000 | Verify: 20 

Agora confirme que uma conexão HTTPS legítima continua funcionando:

curl -I https://github.com 

Uma resposta como HTTP/2 200 confirma que o curl conseguiu estabelecer essa conexão normalmente.

Não utilize curl -k ou --insecure, porque esses parâmetros desabilitam justamente a validação que queremos testar.

5. E os serviços em Docker, Go, Python e Node.js?

Aqui está um detalhe importante: atualizar o sistema operacional não garante que todas as aplicações estejam corrigidas.

Algumas utilizam bibliotecas ou certificados próprios.

Versões corrigidas de referência:

Para verificar:

go version node -v python -m pip show certifi docker ps 

Se estiver utilizando Docker, revise também as imagens-base e os certificados de cada contêiner.

No Go, atualizar a versão instalada não corrige automaticamente os binários já compilados: é necessário recompilá-los com a versão corrigida.

6. O que encontrei nos meus servidores?

Depois de receber o alerta, resolvi verificar três ambientes que utilizo:

Os três passaram nos testes finais do curl.

O mais interessante é que os servidores estavam funcionando normalmente. Nenhuma falha aparente, nenhum serviço necessariamente parado.

O problema estava na confiança depositada em certificados comprometidos.

Um serviço estar online não significa necessariamente que está seguro.

Conclusão

Segurança não é apenas manter sistemas atualizados. É também testar se as correções realmente funcionaram.

Nesse caso, alguns comandos foram suficientes para encontrar um problema real, aplicar a correção e validar o resultado.

Vale lembrar que os testes apresentados verificam o comportamento do curl. Aplicações com mecanismos próprios de validação TLS precisam ser avaliadas separadamente.

Agradecimentos

Esse artigo nasceu de um alerta compartilhado no Slack pelo meu colega Jefferson Luis Martins (Jeff).

Ele trouxe o contexto do incidente, explicou os riscos e compartilhou orientações para correção, o que me motivou a verificar meus próprios ambientes.

Valeu pelo alerta, Jeff!

Segurança também se constrói compartilhando conhecimento.

Referências

• Relatório técnico do incidente eMudhra
• Documentação do curl sobre certificados SSL
• Ubuntu Security
• Debian Security

Publicado em outubro de 2026. As versões e recomendações refletem as informações disponíveis na data da publicação.