What Is a Trust Store (CA Bundle)?
A trust store answers one question for a TLS client: which certificate authorities do I believe? It typically contains:
A trust store is the collection of root CA certificates (and sometimes explicit distrust rules) that software uses to decide which certificates to accept during TLS and other certificate-based authentication. If a certificate chains up to a root in the trust store, and nothing in the chain is revoked or blocked, the software treats it as valid. A trust store distributed as a single file is often called a CA bundle.
Where trust stores live#
Most environments have several, and different software uses different ones:
| Location | Examples | Who updates it |
|---|---|---|
| Browser | Firefox (NSS), Chrome Root Store | Browser vendor, often with fast push updates |
| Operating system | Windows certificate store, macOS Keychain, Linux ca-certificates |
OS vendor through system updates |
| Language runtime | Java cacerts, Go’s root handling |
Runtime releases |
| Bundled packages | Python certifi, Rust webpki-roots, Composer ca-bundle, Electron apps |
The package maintainer, then your next dependency update |
| Container images | CA bundle copied into the image at build time | Your next image rebuild |
| Custom stores | mTLS client-CA lists, appliance trust settings, uploaded CA files | You |
Why trust stores matter during CA incidents#
When a certificate authority is compromised or distrusted, every trust store that includes it must change. Browsers can react within hours because they push revocation and distrust data to installed copies. A static trust store, such as a bundled file inside an application or a container image, keeps trusting the old CA until a new version is built and deployed.
The October 2026 eMudhra intermediate CA compromise shows the pattern: browsers blocked the affected intermediates quickly, while Go, Python certifi, Rust webpki-roots, NSS and others shipped patched versions that each application then had to adopt.
How to tell which trust store an application uses#
- Check the HTTP library and runtime, not just the SDK. An API client usually delegates verification to an underlying library, which picks the trust store.
- Look for bundled CA files in the dependency tree (for example
certifiin Python projects). - Check environment overrides such as
SSL_CERT_FILE,REQUESTS_CA_BUNDLEorNODE_EXTRA_CA_CERTS, which point software at a specific bundle. - Test from inside the application’s real runtime or container, because a passing test in a browser or with
curlmay use a different trust store.
# Python: which bundle certifi provides, and its version
python -c "import certifi; print(certifi.where(), certifi.__version__)"
# Debian/Ubuntu: rebuild the system bundle after updating ca-certificates
sudo update-ca-certificates
Common mistakes#
- Disabling verification to make certificate errors go away. This removes the protection entirely.
- Updating the OS but not the containers built from older base images.
- Forgetting long-running processes, which keep the trust store they loaded at startup until restarted.
- Adding private CAs to the public trust store of a whole system when only one application needs them.