A segurança das conexões HTTPS depende de uma relação de confiança que normalmente passa despercebida pelos usuários: a integridade das autoridades certificadoras (CAs) responsáveis por validar a identidade dos servidores. O comprometimento das chaves privadas de certificados intermediários da eMudhra colocou essa confiança em risco, permitindo que terceiros potencialmente produzissem certificados fraudulentos capazes de se passar por sites legítimos. O problema também revelou uma particularidade importante do ecossistema da Apple: nem todas as ferramentas do macOS utilizam os mesmos mecanismos de validação de certificados.
A Apple começou a bloquear automaticamente os certificados afetados em outubro de 2026, protegendo navegadores, clientes de e-mail e aplicativos que utilizam suas estruturas nativas de rede e segurança. Entretanto, essa primeira intervenção não contemplava integralmente ferramentas tradicionais de linha de comando, como curl e git, que poderiam continuar aceitando certificados associados à infraestrutura comprometida.
A empresa agora avança com uma correção direcionada ao repositório de certificados utilizado por essas ferramentas. A mudança interessa especialmente a desenvolvedores, administradores de sistemas e profissionais de DevOps, pois scripts automatizados, pipelines de CI/CD e processos de integração podem estabelecer conexões HTTPS sem passar pelo mecanismo de confiança utilizado pelo Safari.
O incidente eMudhra e o perigo de chaves intermediárias expostas
O incidente veio à tona em 17 de outubro de 2026, quando a equipe de segurança da Mozilla recebeu uma denúncia sobre o comprometimento das chaves privadas associadas a oito certificados intermediários operados pela eMudhra. A comunicação também envolveu os programas de confiança da Apple, Microsoft e Google, devido ao alcance potencial do problema.
A gravidade estava na possibilidade de recuperar as chaves privadas correspondentes aos certificados. A investigação demonstrou que o material criptográfico apresentava falhas na geração das chaves, tornando possível recuperar os valores secretos e comprovar o controle sobre os certificados comprometidos.
Uma autoridade certificadora intermediária ocupa uma posição importante na infraestrutura de confiança da internet. Ela recebe sua legitimidade de uma autoridade raiz e pode emitir certificados para servidores e serviços. Quando sua chave privada é comprometida, um invasor pode utilizá-la para produzir certificados fraudulentos que aparentam ter sido emitidos legitimamente.
Na prática, isso abre caminho para ataques de adversário no meio (MitM). Caso consiga interceptar o tráfego de uma vítima, um atacante poderia apresentar um certificado falsificado para imitar um domínio legítimo, potencialmente permitindo a leitura ou modificação de informações transmitidas.
O problema envolveu oito autoridades certificadoras intermediárias. Desse conjunto, seis estavam relacionadas à emissão de certificados TLS, enquanto outras duas emitiam certificados de assinatura de código. Para a Apple, a preocupação principal estava nas seis CAs TLS, que poderiam ser utilizadas para criar certificados fraudulentos de sites.
Como a Apple iniciou o bloqueio dos certificados comprometidos
A Apple começou a distribuir bloqueios automáticos em 19 de outubro de 2026, por meio de atualizações dos dados de configuração de certificados. Essa abordagem permitiu que os dispositivos recebessem as alterações sem depender da instalação de uma nova versão completa do macOS.
O mecanismo protegeu o Safari, o Mail e aplicativos que utilizam os frameworks nativos de rede e segurança da Apple. Em 23 de outubro, a empresa também começou a bloquear o certificado raiz emSign ECC Root CA – G3, ampliando a proteção contra as cadeias de confiança relacionadas ao incidente.
Entretanto, essa estratégia tinha uma limitação importante: o bloqueio distribuído pela Apple não era automaticamente aplicado a todos os repositórios de certificados utilizados por softwares instalados no Mac.
Por que curl, git e outras ferramentas do terminal continuaram vulneráveis
O macOS possui diferentes mecanismos para armazenar e consultar certificados digitais. Enquanto os aplicativos integrados ao ecossistema da Apple podem utilizar o Chaveiro do macOS e os frameworks nativos de segurança, diversas ferramentas tradicionais de linha de comando utilizam um arquivo de certificados no formato PEM.
Esse arquivo é o /etc/ssl/cert.pem, que funciona como um repositório de autoridades certificadoras confiáveis para determinados programas.
Entre as ferramentas que podem consultar esse arquivo estão:
- curl: utilizado para realizar requisições HTTP e HTTPS, baixar arquivos e testar serviços.
- git: responsável por operações de versionamento e comunicação com repositórios remotos.
- python3: utilizado em scripts, automações e aplicações que estabelecem conexões HTTPS.
- ruby e perl: presentes em diferentes ambientes de desenvolvimento e administração.
- openssl: ferramenta amplamente utilizada para inspecionar certificados e realizar operações criptográficas.
O problema é que essas ferramentas podem validar uma cadeia de certificados utilizando diretamente as autoridades presentes em cert.pem, sem consultar os bloqueios dinâmicos distribuídos pela Apple.
Isso significa que um certificado poderia ser rejeitado pelo Safari e, simultaneamente, ser aceito por uma operação HTTPS executada pelo terminal.
A diferença é especialmente relevante em ambientes de desenvolvimento. Um pipeline de CI/CD pode utilizar curl para baixar dependências, git para clonar repositórios e Python para consultar APIs externas. Se essas operações confiarem em uma cadeia comprometida, existe a possibilidade de estabelecer conexões com servidores fraudulentos sem que o bloqueio aplicado ao navegador seja suficiente para impedir a comunicação.
Portanto, ter o macOS atualizado e navegar com segurança pelo Safari não significava necessariamente que todas as ferramentas instaladas estavam protegidas.
Certificados eMudhra no macOS: atualizações corrigem a brecha no terminal
A Apple anunciou em 9 de novembro de 2026 a disponibilização das atualizações que fecham a lacuna de segurança nas ferramentas de linha de comando.
As correções contemplam três versões do sistema operacional:
macOS Golden Gate
27.2.1
macOS Tahoe
26.7.3
macOS Sequoia
15.8.3
Versões com a correção disponibilizada em 9 de novembro de 2026.
A principal mudança está na atualização do arquivo /etc/ssl/cert.pem, que deixa de incluir certificados raiz associados às cadeias comprometidas.
Segundo as informações divulgadas sobre a atualização, a Apple removeu cinco certificados de autoridades certificadoras desse repositório, incluindo três certificados adicionais da eMudhra que não faziam parte da intervenção manual inicialmente recomendada.
Com isso, ferramentas como curl, git, python3 e openssl, quando utilizam o repositório de certificados fornecido pelo sistema, deixam de confiar nas cadeias afetadas.
A atualização elimina a necessidade de executar manualmente os procedimentos de remoção recomendados anteriormente. Administradores devem verificar a versão instalada e priorizar a aplicação da atualização correspondente à sua geração do macOS.
Como proteger sistemas legados editando cert.pem
Administradores que não conseguem atualizar imediatamente seus computadores ainda podem aplicar a mitigação manual documentada pela Apple.
O procedimento consiste em remover duas autoridades raiz do arquivo /etc/ssl/cert.pem: emSign ECC Root CA – G3 e AAA Certificate Services.
A segunda remoção é opcional na documentação, mas importante para bloquear também as seis cadeias de certificados intermediários que foram assinadas de forma cruzada pela Sectigo.
Antes de começar, é necessário utilizar uma conta com privilégios administrativos e realizar um backup do arquivo original.
1. Faça uma cópia de segurança:
[ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig2. Remova a autoridade raiz emSign ECC Root CA – G3:
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"3. Remova também a autoridade AAA Certificate Services, se necessário:
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"4. Verifique se os certificados foram removidos:
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'Se a remoção tiver sido realizada corretamente, o último comando não deverá apresentar resultados.
É importante observar que a exclusão dessas autoridades raiz pode afetar outros serviços legítimos que dependam exclusivamente delas para validar certificados. Portanto, ambientes corporativos devem avaliar possíveis dependências antes de aplicar a alteração.
Outro cuidado envolve as atualizações posteriores do macOS. Antes de instalar a correção definitiva, uma atualização intermediária do sistema pode substituir o arquivo modificado pela versão original da Apple. Nesse cenário, será necessário verificar novamente o resultado e repetir o procedimento caso os certificados tenham reaparecido.
Depois da instalação das versões corrigidas, essa intervenção manual deixa de ser necessária para as ferramentas incluídas no macOS e nas Ferramentas de Linha de Comando do Xcode.
A lição de higiene PKI para ecossistemas multiplataforma
O incidente dos certificados eMudhra no macOS demonstra que a segurança de um sistema operacional não depende exclusivamente da proteção oferecida pelo navegador. A confiança digital também precisa ser aplicada aos utilitários, bibliotecas, ambientes de execução e ferramentas de automação que trabalham silenciosamente em segundo plano.
Para equipes de desenvolvimento, isso significa revisar não apenas as versões do sistema operacional, mas também a origem dos repositórios de certificados utilizados por cada ferramenta. Aplicações instaladas por meio do Homebrew, runtimes de linguagens de programação e softwares de terceiros podem utilizar seus próprios pacotes de autoridades certificadoras.
Consequentemente, a atualização da Apple resolve a vulnerabilidade nas ferramentas abrangidas pela correção, mas não garante automaticamente que todos os programas instalados no computador utilizem a mesma política de confiança.
Uma boa estratégia de higiene de PKI deve incluir atualizações regulares, monitoramento de certificados, revisão das cadeias de confiança e testes de validação TLS nos ambientes de desenvolvimento e produção.
Para administradores responsáveis por vários computadores, também é recomendável incorporar a verificação dos certificados confiáveis às rotinas de gerenciamento de dispositivos e aos processos de conformidade de segurança.
A correção disponibilizada em novembro encerra uma lacuna importante, mas deixa uma lição para todo o ecossistema multiplataforma: proteger o navegador não é o mesmo que proteger todas as conexões realizadas pelo computador.
