:Remediação para o comprometimento do certificado eMudhra no ca-certificates

Visão geral do incidente

Em 20 de outubro de 2026, foi divulgado publicamente o comprometimento das chaves privadas da autoridade certificadora (CA) intermediária pertencente à eMudhra. Partes não autorizadas podem usar as chaves comprometidas para emitir certificados X.509 fraudulentos. Se conseguirem interceptar ou redirecionar o tráfego de rede, elas podem se passar por services HTTPS e realizar ataques man-in-the-middle para roubar ou modificar dados de comunicação.

Trata-se de um problema de confiança em uma CA de terceiros, e não de uma vulnerabilidade de código no Alibaba Cloud Linux. Isso não significa que um sistema tenha sido atacado. Como os certificados raiz relacionados no repositório de confiança do sistema podem estabelecer cadeias de confiança para as CAs intermediárias comprometidas, o risco de confiança de certificados ainda exige remediação.

Detalhes do incidente

Em uma infraestrutura de chave pública (PKI), os clientes verificam a identidade de um service por meio de uma cadeia composta pelo certificado do servidor, certificados de CA intermediária e um certificado de CA raiz confiável. As chaves comprometidas pertencem a CAs intermediárias. Essas CAs podem encadear, por meio de assinaturas ou assinaturas cruzadas, às raízes Comodo AAA Services e emSign ECC Root CA - G3 presentes no repositório de confiança do sistema. Se as validações de cadeia, validade, uso e outras verificações forem aprovadas, os clientes que ainda confiam nessas raízes podem aceitar certificados de service fraudulentos.

O procedimento a seguir remove a confiança nos dois certificados raiz listados abaixo. Os rótulos de confiança identificam os certificados nos comandos. Use as impressões digitais SHA-256 para verificar a identidade do certificado.

Programas que utilizam o repositório de confiança do sistema para validar certificados TLS podem ser afetados. Exemplos incluem curl, wget, yum/dnf e aplicativos OpenSSL, GnuTLS, NSS ou Java configurados para usar esse repositório. O impacto depende do repositório de confiança e da cadeia de certificados em uso, e não apenas do nome do programa.

Produtos e versões afetados

A equipe de segurança do Alibaba Cloud Linux confirmou que os seguintes produtos e versões do pacote ca-certificates são afetados:

Remediação

Alibaba Cloud Linux 2, 3 e 4

Execute as operações a seguir como root em um ambiente bash. Primeiro, execute o comando somente leitura abaixo para verificar a versão do pacote. Se trust, OpenSSL ou update-ca-trust não estiverem disponíveis, pare e verifique se as ferramentas necessárias estão instaladas. Um comando ausente não significa que a remediação foi concluída.

rpm -q ca-certificates

1. Execute os comandos a seguir na mesma sessão bash para extrair os dois certificados raiz para o diretório local de desconfiança. Use o diretório blocklist se ele existir; caso contrário, use o diretório blacklist. A cadeia de comandos será interrompida se o diretório não existir, se a extração falhar ou se um arquivo de saída estiver vazio. Resolva o problema antes de continuar.

   d=/etc/pki/ca-trust/source/blocklist
   [ -d "$d" ] || d=/etc/pki/ca-trust/source/blacklist
   test -d "$d" &&
   trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' "$d/Comodo_AAA_Services_root.pem" &&
   test -s "$d/Comodo_AAA_Services_root.pem" &&
   trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' "$d/emSign_ECC_Root_CA_-_G3.pem" &&
   test -s "$d/emSign_ECC_Root_CA_-_G3.pem"

2. Na mesma sessão, exiba as impressões digitais SHA-256 dos certificados extraídos e compare cada uma com as impressões digitais na seção Detalhes do incidente. Se um comando falhar ou uma impressão digital não corresponder, pare. Não atualize o repositório de confiança.

   openssl x509 -in "$d/Comodo_AAA_Services_root.pem" -noout -fingerprint -sha256
   openssl x509 -in "$d/emSign_ECC_Root_CA_-_G3.pem" -noout -fingerprint -sha256

3. Após verificar a identidade de ambos os certificados, regenere o repositório de confiança do sistema:

   update-ca-trust extract

4. Execute os comandos a seguir para verificar se o pacote de certificados do sistema gerado ainda contém essas raízes. A configuração pipefail impede que a verificação de correspondência seja executada se o pipeline do OpenSSL falhar.

   set -o pipefail
   subjects=$(openssl crl2pkcs7 -nocrl -certfile /etc/pki/tls/certs/ca-bundle.crt | openssl pkcs7 -print_certs -noout) &&
   printf '%s\n' "$subjects" | grep -E 'subject=.*CN ?= ?(AAA Certificate Services|emSign ECC Root CA - G3)'

   As raízes estarão ausentes deste pacote somente se a listagem de certificados for bem-sucedida, o OpenSSL não relatar erros e o grep não produzir nenhuma saída correspondente. Um código de saída 1 do grep significa que nenhuma correspondência foi encontrada, o que é esperado. Se assuntos de certificados aparecerem ou ocorrer um erro de leitura de arquivo ou análise de certificado, não conclua que a remediação foi bem-sucedida. Esta verificação não confirma que todos os repositórios de confiança específicos de aplicativos foram atualizados.

Se você precisar reverter essa configuração local de desconfiança, primeiro avalie o risco de segurança de restaurar a confiança do certificado e obtenha a aprovação de alteração necessária. Em seguida, remova os dois arquivos PEM adicionados por este procedimento, execute update-ca-trust extract e verifique seus services. A reversão pode restaurar a confiança nas cadeias de certificados afetadas e não deve ser a resposta normal para falhas de conexão.

Alibaba Cloud Linux 4 (Deb Edition)

Atualize o ca-certificates por meio do repositório oficial de software configurado para a versão 20260816ubuntu0.24.04.1 ou posterior:

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

Após a atualização ser concluída com êxito, execute o seguinte comando somente leitura para visualizar a versão completa do pacote instalado e compará-la com a versão corrigida acima:

dpkg-query -W -f='${Package} ${Version}\n' ca-certificates

Se o pacote não estiver instalado, o repositório não fornecer a versão corrigida ou a atualização falhar, não considere a conclusão do comando como uma remediação bem-sucedida. O Deb Edition usa seu próprio mecanismo de gerenciamento de repositório de confiança. Não aplique os diretórios de sistema RPM ou os comandos update-ca-trust acima ao Deb Edition.

Após a remediação, confirme o repositório de confiança realmente usado por cada aplicativo e verifique conexões TLS críticas e logs de erros. Para processos de longa duração que armazenam em cache informações de confiança da CA, recarregue-os conforme exigido pelo aplicativo ou reinicie-os durante uma janela de manutenção. Atualize e verifique contêineres e outros repositórios de confiança independentes separadamente.

Referências

• Declaração da eMudhra sobre a desconfiança de CAs Intermediárias TLS Globais selecionadas e uma CA Raiz

• Anúncio de segurança da Mozilla sobre o comprometimento dos certificados intermediários da eMudhra

• Boletim de segurança da Red Hat RHSB-2026-012