CONCEPT Cited by 1 source

Root CA trust store¶

Definition¶

A root CA trust store is the local database of trusted certificate-authority root certificates that a TLS client consults to validate a server's certificate chain. When a client receives a certificate from a server, it walks the chain upward to the issuing root and checks that the root is present in the local trust store. If yes, and the chain signatures validate, the connection is trusted; if the root is missing, the client aborts with an "unable to get local issuer's certificate"-class error.

Where the trust store lives¶

Different platforms ship trust stores in different places (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field):

macOS: /etc/ssl/cert.pem (OpenSSL bundle); also the system Keychain (/System/Library/Keychains/…) for OS-level consumers.
Linux: distribution-dependent, but typically /etc/ssl/certs/ or /etc/pki/tls/certs/; Debian/Ubuntu install the bundle via the ca-certificates package.
Windows: an internal CryptoAPI database accessed via CryptoAPI rather than a flat file.
Browsers: Firefox ships its own store (independent of the OS); Chrome/Safari/Edge defer to the OS store.
Language runtimes: the JVM has cacerts, Python has certifi, Go reads the OS store; containers may ship none until ca-certificates is explicitly installed.

Where the trust store comes from¶

The canonical public-CA list is the Mozilla CA Certificate Program (wiki.mozilla.org/CA) — Mozilla's published policy + audit regime for admitting a root CA into NSS. Linux's ca-certificates package, certifi, most BSD packages, and many container bases re-ship the Mozilla list verbatim. Apple, Microsoft, and Google maintain their own (overlapping) lists for their respective OS/browser trust stores.

Common failure mode: missing trust store in a container or¶

tool

The dominant user-visible failure on a managed-service TLS endpoint is not "certificate expired" but "CA not trusted", caused by the client's environment shipping without a public-CA trust store.

Observed instances (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field):

Third-party tools (Google Data Studio / Looker Studio, Retool) that expose CA Cert / Client Cert / Client Key fields in their connection UI but don't ship the public-CA list internally. Symptom: "Unable to get local issuer's certificate".
Linux installs without ca-certificates (minimal base images, Alpine without the package added explicitly).
Legacy systems with stale OpenSSL that predate a newer root-CA rotation.

Remediation hierarchy¶

Install the public-CA bundle — apt install ca-certificates on Debian/Ubuntu, apk add ca-certificates on Alpine, equivalent on other distributions. Preferred fix because it tracks upstream rotation automatically.
Point the driver / tool at an existing bundle — many database drivers accept an explicit CA-bundle path environment variable; pointing it at the OS bundle fixes the connection without installing new files.
Paste the specific root CA into the tool's CA Cert field — the CA-bundled cert for tool trust pattern: upload the Let's Encrypt ISRG Root X1 PEM (or whichever root the managed service pins) into the tool's CA Cert field. Works without root access on the tool's host, but the tool will break if the managed service ever changes CA.
Never: disable TLS verification. Opens MITM attack surface; canonicalised as self-signed-cert anti-pattern.

Trust store as infrastructure dependency¶

The trust store is a silent dependency of almost every TLS client — working assumption is that it exists and is current. When it breaks or lags (new-CA rollout, legacy container without ca-certificates, JVM running an old cacerts), the symptom is "CA not trusted" against a perfectly valid certificate, which is typically mis-diagnosed as a certificate problem rather than a trust-store problem. Distinguishing the two is the core skill of debugging TLS connection failures in production.

Seen in¶

sources/2026-04-21-planetscale-supports-notes-from-the-field — canonical wiki disclosure of the platform-by-platform trust-store paths, the Mozilla CA Certificate Program as the source of the Linux ca-certificates package, and the observed failure modes (libssl too old, Debian Buster library-compile-without-SSL case, missing CA bundle in third-party tools like Retool / Looker Studio). Post also provides the inlined Let's Encrypt ISRG Root X1 PEM for copy-paste into third-party tool CA Cert fields.