Por qué las aplicaciones ignoran el almacén de confianza del SO: cacerts de Java, certifi de Python, Node.js y curl

Qué es

Un almacén de confianza del SO (/etc/pki/ca-trust, /etc/ssl/certs, el llavero System de macOS, el almacén Root de Windows) es solo uno de los varios lugares donde un proceso puede buscar certificados de CA de confianza. Varios runtimes habituales incluyen o mantienen uno propio:

• Java: el JDK incluye su propio almacén de claves, cacerts ($JAVA_HOME/lib/security/cacerts; jre/lib/security/cacerts en JDK 8), que se gestiona con keytool. A partir de JDK 9, keytool -importcert -cacerts -alias myca -file ca.pem -noprompt añade una CA sin preguntar "Trust this certificate?"; en JDK 8 hay que pasar -keystore con la ruta completa. La referencia de Oracle indica changeit como contraseña inicial del almacén, y normalmente el archivo solo puede ser modificado por root. El OpenJDK empaquetado por las distribuciones de la familia RHEL y de Debian/Ubuntu usa un almacén de claves generado a partir del almacén del SO; los tarballs de JDK de los proveedores y muchas imágenes de contenedor no lo hacen.
• Python: por defecto, la biblioteca requests verifica contra la lista de CA incluida en el paquete certifi, y no contra el almacén del SO. La documentación de Requests sobre la verificación de certificados SSL indica que la variable de entorno REQUESTS_CA_BUNDLE (o CURL_CA_BUNDLE) sustituye ese paquete, y que el parámetro verify= permite apuntar una única llamada a otro. SSL_CERT_FILE se lee en las rutas por defecto de OpenSSL (el contexto por defecto de ssl en Python, curl), pero no en requests, que pasa explícitamente la ruta de certifi.
• Node.js: por defecto, Node usa sus propios certificados raíz incluidos. La variable de entorno NODE_EXTRA_CA_CERTS, documentada en la referencia de la API de línea de comandos de Node, indica un archivo PEM adicional cuyos certificados se consideran de confianza además de los integrados en Node. Solo se lee al iniciar el proceso, un archivo ausente o mal formado genera únicamente una advertencia, y se ignora cuando el código pasa una opción ca explícita. --use-openssl-ca cambia al almacén de OpenSSL; las versiones recientes añaden --use-system-ca.
• curl: la mayoría de las compilaciones de curl de las distribuciones usan el paquete del SO, pero curl también acepta --cacert <file> para usar un paquete concreto en una sola invocación, y un curl compilado estáticamente (habitual en contenedores) puede apuntar a un paquete que una actualización de confianza con el gestor de paquetes nunca toca.

Por qué importa

Si un operador añade una CA al almacén del SO y comprueba que un servicio Java, un script de Python o un proceso de Node siguen rechazando el mismo certificado, no se trata de una cache desactualizada del SO: esas aplicaciones leen un paquete completamente distinto. Los contenedores agravan el problema: una imagen base mínima puede incluir curl enlazado estáticamente y ningún paquete de CA.

Cómo aplicarlo

• Cuando un error de certificado persiste tras actualizar la confianza a nivel de SO, revisa el runtime concreto: keytool -list -keystore $JAVA_HOME/lib/security/cacerts, python -c "import certifi; print(certifi.where())", echo $NODE_EXTRA_CA_CERTS.
• En los servicios que deben confiar en una CA interna, actualiza todos los paquetes que realmente leen, no solo el del SO, y documéntalos todos juntos.
• Solo NODE_EXTRA_CA_CERTS es aditiva. REQUESTS_CA_BUNDLE, SSL_CERT_FILE y --cacert reemplazan el paquete por defecto, así que apúntalas a un paquete completo (por ejemplo, el paquete del SO que ya contiene la CA privada) y nunca a un archivo que contenga solo la CA privada; de lo contrario, los sitios públicos dejarán de verificarse.

Trampas

• Reiniciar un servicio tras una actualización de confianza del SO pero no tras definir una variable específica del runtime, o al revés; en ambos casos hay que reiniciar el proceso para que vuelva a leer el paquete.
• Suponer que todas las instalaciones de Python se comportan igual: el certifi empaquetado por la distribución (Debian, Fedora) está modificado para apuntar al paquete del SO, mientras que un certifi instalado con pip en un virtualenv incluye su propia lista.