Os certificados eMudhra entraram no centro de um alerta de segurança após a descoberta de chaves criptográficas fracas associadas a oito autoridades certificadoras intermediárias. O problema, divulgado em outubro de 2026, poderia permitir a criação de certificados TLS fraudulentos capazes de imitar sites legítimos e abrir caminho para ataques de interceptação de comunicações. Embora as principais empresas de tecnologia tenham reagido rapidamente, usuários do macOS que trabalham com ferramentas de terminal precisam observar um risco residual específico.
A Apple começou a bloquear os certificados afetados por meio de mecanismos automáticos de segurança, protegendo o Safari, o Mail e aplicativos que utilizam seus frameworks de rede. Entretanto, determinados utilitários de linha de comando, incluindo curl e git, podem continuar aceitando cadeias de certificados problemáticas quando utilizam o arquivo local /etc/ssl/cert.pem, sem aplicar os mesmos bloqueios. A empresa publicou um procedimento opcional para administradores que desejam antecipar essa proteção enquanto aguardam a atualização de software correspondente.
O episódio demonstra por que a segurança do HTTPS depende não apenas da criptografia utilizada nas conexões, mas também da integridade das autoridades que emitem certificados e da atualização dos repositórios de confiança. Para desenvolvedores, administradores de sistemas e profissionais de cibersegurança, compreender essa diferença é essencial para reduzir a exposição de ambientes de desenvolvimento e infraestrutura.
O que aconteceu com os certificados eMudhra
A eMudhra, empresa indiana que opera serviços de certificação digital, identificou um problema envolvendo oito certificados de autoridades certificadoras intermediárias. A descoberta foi comunicada por um pesquisador de segurança em 17 de outubro de 2026, e a empresa revogou os certificados afetados no dia seguinte. As informações divulgadas pela companhia indicam que não foram emitidos certificados finais a partir das autoridades comprometidas e que, até o momento, não há evidências públicas de exploração maliciosa ou de vazamento de dados relacionado ao incidente.
O risco, entretanto, era tecnicamente significativo. Se um invasor consegue recuperar a chave privada de uma autoridade certificadora intermediária confiável, ele pode tentar emitir certificados fraudulentos para domínios que não controla. Dependendo das verificações implementadas pelo cliente, esses certificados podem ser utilizados para personificar serviços legítimos.
Como surgiu a fraqueza criptográfica
A falha estava relacionada à geração inadequada de chaves privadas, que apresentavam entropia criptográfica insuficiente. Entropia é uma medida relacionada à imprevisibilidade dos valores utilizados em operações criptográficas. Quando uma chave é gerada com aleatoriedade inadequada, ela pode ser muito mais fácil de recuperar do que o algoritmo criptográfico originalmente projetado permitiria.
Segundo os relatos técnicos sobre o incidente, o problema afetou oito autoridades intermediárias, das quais seis estavam relacionadas à emissão de certificados TLS e duas à assinatura de código. A vulnerabilidade não significa que o algoritmo TLS tenha sido quebrado. O problema estava na segurança das chaves que sustentavam parte da cadeia de confiança.
Uma autoridade certificadora intermediária funciona como uma entidade autorizada por uma autoridade superior a emitir certificados. Essa estrutura permite distribuir responsabilidades sem que a chave da autoridade raiz precise ser utilizada diretamente em cada emissão.
Quando uma intermediária tem sua chave privada comprometida, a confiança depositada nela pode ser explorada para produzir certificados aparentemente legítimos. Por isso, a resposta não depende apenas da revogação tradicional: navegadores e sistemas também precisam deixar de confiar nas autoridades afetadas.
Como Apple, Google, Microsoft e Mozilla reagiram
Após a divulgação, os principais fornecedores de navegadores e plataformas iniciaram medidas para bloquear os certificados envolvidos.
O Google Chrome utilizou uma atualização de sua lista de bloqueio de certificados, enquanto a Mozilla aplicou bloqueios no Firefox por meio do mecanismo OneCRL. A Apple começou a bloquear os certificados em seus dispositivos em 19 de outubro e ampliou as medidas nos dias seguintes. A Microsoft também participou da resposta ao incidente, incluindo a atuação sobre os certificados associados à assinatura de código.
Essas medidas são importantes porque podem ser distribuídas sem exigir, em todos os casos, uma atualização completa do navegador. O bloqueio impede que os certificados identificados sejam aceitos pelas implementações abrangidas pela proteção.
Ainda assim, não é correto presumir que todas as aplicações instaladas em um computador herdam automaticamente os mecanismos de segurança do navegador. A forma como cada programa consulta certificados confiáveis e verifica revogações determina sua exposição residual.
Por que os certificados eMudhra ainda representam um risco no terminal do macOS
A principal preocupação para desenvolvedores e administradores está na diferença entre os mecanismos de validação utilizados pelo macOS e aqueles empregados por determinados programas de terminal.
O Safari, o Mail e os aplicativos que utilizam os frameworks de segurança e rede da Apple recebem os bloqueios de certificados distribuídos pela empresa. Já algumas ferramentas de linha de comando consultam diretamente o arquivo /etc/ssl/cert.pem, que contém certificados de autoridades consideradas confiáveis.
Entre os utilitários potencialmente afetados estão:
curl, utilizado para realizar requisições HTTP e HTTPS.git, empregado para clonar repositórios, buscar atualizações e enviar alterações.python3, em determinadas operações de conexão HTTPS.rubyeperl, dependendo das bibliotecas utilizadas.openssl, quando configurado para validar certificados com esse arquivo.
O ponto crítico é que essas ferramentas podem não consultar os mesmos bloqueios de certificados aplicados pelos frameworks da Apple. Quando a validação depende exclusivamente de /etc/ssl/cert.pem, uma conexão pode continuar aceitando uma cadeia que o navegador já rejeitaria.
Isso não significa que todos os programas de terminal estejam vulneráveis. Algumas aplicações utilizam seus próprios repositórios de certificados, enquanto outras dependem de bibliotecas e mecanismos de validação diferentes. A exposição precisa ser avaliada individualmente.
Como reduzir o risco usando o terminal
A Apple documentou um procedimento manual para remover do arquivo de certificados as autoridades raiz relacionadas às cadeias afetadas. A medida é opcional e destinada principalmente a administradores e desenvolvedores que precisam antecipar a proteção.
Atenção: a alteração afeta todas as ferramentas que utilizam esse arquivo. A remoção de uma autoridade raiz pode interromper a validação de sites legítimos que dependam dela por meio de outras autoridades intermediárias não comprometidas. Faça a alteração de forma consciente e mantenha uma cópia de segurança.
1. Faça uma cópia de segurança
Abra o Terminal e execute:
[ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.origO comando preserva uma cópia original do arquivo. Se o backup já existir, ele não será sobrescrito.
2. Remova a autoridade raiz emSign ECC Root CA – G3
Execute o comando abaixo exatamente como apresentado:
t=$(mktemp) && awk -v s='=== /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"O procedimento gera uma versão temporária do arquivo sem o certificado identificado, verifica se o resultado não está vazio e instala a versão modificada. A ausência de mensagens no terminal pode indicar que o comando foi concluído sem erros.
3. Considere remover também a AAA Certificate Services
A primeira alteração não bloqueia necessariamente todas as cadeias afetadas. Algumas foram assinadas novamente pela Sectigo e podem continuar sendo validadas por meio da autoridade raiz AAA Certificate Services.
Para bloquear também esse caminho de confiança no arquivo local, a Apple disponibiliza o seguinte comando opcional:
t=$(mktemp) && awk -v s='=== /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"Essa segunda remoção amplia o impacto sobre os certificados que podem ser validados pelo arquivo. Antes de aplicá-la, considere as dependências de aplicações corporativas, ambientes de desenvolvimento e serviços utilizados pela equipe.
4. Verifique o resultado
Após as alterações, execute:
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'Se as duas autoridades tiverem sido removidas, o comando não deverá exibir nenhuma delas. Se houver um erro durante o procedimento, a orientação da Apple é restaurar a cópia de segurança antes de tentar novamente.
Para restaurar o arquivo original, se necessário, utilize:
sudo cp -p /etc/ssl/cert.pem.orig /etc/ssl/cert.pemImportante: restaurar o backup também restaura as autoridades removidas. Faça isso somente se necessário para recuperar a configuração e avalie novamente o risco de confiança nos certificados afetados.
O procedimento deve ser realizado com uma conta administrativa e seguindo cuidadosamente as instruções oficiais. Evite editar o arquivo manualmente sem compreender a estrutura do bundle de certificados.
O que fazer depois da correção manual
A alteração de /etc/ssl/cert.pem é uma medida temporária, não um substituto para as atualizações oficiais do macOS. A Apple informou que pretende incorporar as mudanças necessárias em uma atualização futura do sistema.
Até que a correção esteja instalada, administradores devem verificar o arquivo após cada atualização do macOS, pois uma atualização pode substituí-lo pela versão fornecida pela Apple. Se isso acontecer, será necessário repetir o procedimento temporário, caso a atualização instalada ainda não contenha a correção definitiva.
Também vale verificar se ferramentas instaladas por gerenciadores de pacotes, ambientes Python, contêineres e aplicações de terceiros utilizam seus próprios repositórios de certificados. Alterar o arquivo do sistema não garante que todos esses componentes passem a rejeitar as cadeias comprometidas.
O impacto da crise de certificados na segurança do ecossistema
O incidente dos certificados eMudhra evidencia uma fragilidade importante da infraestrutura que sustenta o HTTPS: a confiança depende tanto da robustez matemática da criptografia quanto da qualidade dos processos utilizados para gerar, armazenar e administrar chaves privadas.
A resposta rápida dos navegadores reduziu a exposição dos usuários comuns. Entretanto, a diferença entre os mecanismos de confiança do navegador e os utilizados por ferramentas de terminal mostra por que a segurança precisa abranger todo o ambiente computacional, incluindo scripts de automação, integrações de desenvolvimento e servidores.
Para administradores, a prioridade deve ser manter sistemas operacionais, navegadores, bibliotecas criptográficas e repositórios de certificados atualizados. Também é recomendável revisar quais componentes validam certificados localmente e estabelecer procedimentos de recuperação para alterações em arquivos críticos.
A ausência de evidências públicas de exploração em larga escala é um dado positivo, mas não elimina a necessidade de prevenção. Chaves fracas podem permitir a personificação de serviços legítimos, e uma validação TLS inadequada pode expor credenciais, tokens e dados transmitidos em conexões comprometidas.
Verifique seus ambientes de desenvolvimento e suas ferramentas de terminal, especialmente se você utiliza curl, git ou scripts automatizados no macOS. Acompanhe as atualizações oficiais e avalie as medidas temporárias antes de modificar o repositório de certificados.
