Por que as aplicações ignoram o repositório de confiança do SO: Java cacerts, Python certifi, Node.js e curl

O que é

Um repositório de confiança do SO (/etc/pki/ca-trust, /etc/ssl/certs, o keychain System do macOS, o repositório Root do Windows) é apenas um dos vários lugares onde um processo pode buscar certificados de CA confiáveis. Vários runtimes comuns trazem ou mantêm um repositório próprio e separado:

• Java: o JDK inclui seu próprio keystore, cacerts ($JAVA_HOME/lib/security/cacerts; jre/lib/security/cacerts no JDK 8), gerenciado com keytool. No JDK 9 e posteriores, keytool -importcert -cacerts -alias myca -file ca.pem -noprompt adiciona uma CA sem perguntar "Trust this certificate?"; no JDK 8, use -keystore com o caminho completo. A referência da Oracle indica changeit como senha inicial do keystore, e o arquivo normalmente só pode ser gravado pelo root. O OpenJDK empacotado pelas distribuições da família RHEL e por Debian/Ubuntu usa um keystore gerado a partir do repositório do SO; os tarballs de JDK de fornecedores e muitas imagens de contêiner não fazem isso.
• Python: por padrão, a biblioteca requests verifica certificados contra a lista de CAs do pacote certifi, e não contra o repositório do SO. A documentação do próprio Requests sobre verificação de certificados SSL diz que a variável de ambiente REQUESTS_CA_BUNDLE (ou CURL_CA_BUNDLE) substitui esse bundle, e que o parâmetro verify= pode apontar uma única chamada para um bundle específico. SSL_CERT_FILE é lida pelos caminhos padrão do OpenSSL (o contexto padrão do módulo ssl do Python, o curl), mas não pelo requests, que passa explicitamente o caminho do certifi.
• Node.js: por padrão, o Node é vinculado aos seus próprios certificados raiz embutidos. A variável de ambiente NODE_EXTRA_CA_CERTS, documentada na referência da API de linha de comando do Node, indica um arquivo PEM adicional cujos certificados passam a ser confiáveis além dos embutidos. Ela é lida apenas quando o processo inicia, um arquivo ausente ou malformado gera somente um aviso, e ela é ignorada quando o código passa uma opção ca explícita. --use-openssl-ca muda para o repositório do OpenSSL; versões recentes adicionam --use-system-ca.
• curl: a maioria dos builds do curl das distribuições usa o bundle do SO, mas o curl também aceita --cacert <file> para usar um bundle específico em uma única execução, e um curl compilado estaticamente (comum em contêineres) pode apontar para um bundle que uma atualização de confiança feita pelo gerenciador de pacotes nunca toca.

Por que importa

Quando um operador adiciona uma CA ao repositório do SO e vê um serviço Java, um script Python ou um processo Node continuar rejeitando o mesmo certificado, o problema não é um cache desatualizado do SO: é um bundle completamente diferente. Imagens de contêiner agravam a situação: uma imagem base mínima pode incluir um curl com link estático e sem nenhum bundle.

Como aplicar

• Quando um erro de certificado persistir após uma atualização de confiança no nível do SO, verifique o runtime específico: keytool -list -keystore $JAVA_HOME/lib/security/cacerts, python -c "import certifi; print(certifi.where())", echo $NODE_EXTRA_CA_CERTS.
• Para serviços que precisam confiar em uma CA interna, atualize todos os bundles que eles realmente leem, não apenas o do SO, e documente todos juntos.
• Somente NODE_EXTRA_CA_CERTS é aditiva. REQUESTS_CA_BUNDLE, SSL_CERT_FILE e --cacert substituem o bundle padrão; por isso, aponte-as para um bundle completo (por exemplo, o bundle do SO que agora contém a CA privada) e nunca para um arquivo que contenha apenas a CA privada, ou os sites públicos deixarão de ser verificados.

Armadilhas

• Reiniciar um serviço após uma atualização de confiança do SO, mas não após definir uma variável específica do runtime, ou o inverso; nos dois casos o processo precisa ser reiniciado para reler o bundle.
• Supor que todas as instalações de Python se comportam da mesma forma: o certifi empacotado pela distribuição (Debian, Fedora) é modificado para apontar para o bundle do SO, enquanto um certifi instalado com pip em um virtualenv traz sua própria lista.