Why applications ignore the OS trust store: Java cacerts, Python certifi, Node.js and curl

What it is

An OS trust store (/etc/pki/ca-trust, /etc/ssl/certs, the macOS System keychain, the Windows Root store) is one of several places a process can look for trusted CA certificates. Several common runtimes ship or maintain a separate one:

• Java: the JDK bundles its own keystore, cacerts ($JAVA_HOME/lib/security/cacerts; jre/lib/security/cacerts on JDK 8), managed with keytool. On JDK 9 and later, keytool -importcert -cacerts -alias myca -file ca.pem -noprompt adds one without asking "Trust this certificate?"; on JDK 8 pass -keystore with the full path instead. Oracle's reference gives changeit as the initial store password, and the file is normally writable only by root. Distribution-packaged OpenJDK on RHEL-family and Debian/Ubuntu uses a keystore generated from the OS store; vendor JDK tarballs and many container images do not.
• Python: the requests library, by default, verifies against the certifi package's bundled CA list rather than the OS store. Requests' own documentation on SSL certificate verification says the REQUESTS_CA_BUNDLE environment variable (or CURL_CA_BUNDLE) replaces that bundle, and the verify= parameter can point a single call at one. SSL_CERT_FILE is read by OpenSSL's default paths (Python's ssl default context, curl) but not by requests, which passes the certifi path explicitly.
• Node.js: Node links against its own bundled root certificates by default. The NODE_EXTRA_CA_CERTS environment variable, documented in Node's command-line API reference, names an additional PEM file whose certificates are trusted in addition to Node's built-in ones. It is read only when the process starts, a missing or malformed file produces just a warning, and it is ignored when code passes an explicit ca option. --use-openssl-ca switches to OpenSSL's store; recent releases add --use-system-ca.
• curl: most distribution builds of curl use the OS bundle, but curl also accepts --cacert <file> to use a specific bundle for one invocation, and a statically built curl (common in containers) may point at a bundle that a package-manager trust update never touches.

Why it matters

An operator who adds a CA to the OS store and finds a Java service, a Python script or a Node process still rejecting the same certificate is not looking at a stale OS cache — they are looking at a different bundle entirely. Container images compound this: a minimal base image may include curl statically linked with no bundle at all.

How to apply

• When a certificate error persists after an OS-level trust update, check the specific runtime: keytool -list -keystore $JAVA_HOME/lib/security/cacerts, python -c "import certifi; print(certifi.where())", echo $NODE_EXTRA_CA_CERTS.
• For services that must trust an internal CA, update every bundle they actually read, not only the OS one; document all of them together.
• Only NODE_EXTRA_CA_CERTS is additive. REQUESTS_CA_BUNDLE, SSL_CERT_FILE and --cacert replace the default bundle, so point them at a complete bundle (for example the OS bundle that now contains the private CA), never at a file holding only the private CA, or public sites stop verifying.

Pitfalls

• Restarting a service after an OS trust update but not after setting a runtime-specific variable, or vice versa; both require the process to restart to reread the bundle.
• Assuming all Python installs behave alike: distro-packaged certifi (Debian, Fedora) is patched to point at the OS bundle, while a pip-installed certifi in a virtualenv ships its own list.