Cryptographic Trust Stores

A trust store contains local trust anchors and, on some platforms, intermediate certificates or private-key entries. A verifier uses those anchors when it builds and validates an X.509 certification path. Installing a root therefore changes the security boundary of every client that reads that store.

Trust-Store Boundaries #

No universal trust store exists on a host. A connection can cross several independent policy boundaries:

Windows exposes separate Current User and Local Machine stores. Trusted Root Certification Authorities contains anchors, Intermediate Certification Authorities supports chain building, and Personal can contain end-entity certificates with private keys. A Local Machine root affects more principals than a Current User root and requires corresponding administrative controls.

Apple platforms use Keychain trust settings with user, administrator, and system domains. Linux distributions commonly generate a system CA bundle and hashed certificate directory from administrator-managed source directories. Paths and update commands differ, so use the distribution’s certificate management mechanism instead of copying a PEM file into a guessed OpenSSL directory.

Browser and runtime behavior must be tested rather than inferred. Firefox can maintain an NSS certificate database while enterprise policy can import or consult platform roots. Java applications can select a JSSE truststore explicitly and otherwise use runtime defaults such as cacerts. Python, Node.js, containers, and statically packaged applications can each select different bundles. Record the actual consumer and configuration in deployment documentation.

Root, Intermediate, and Private CA Installation #

A root CA certificate becomes a trust anchor only when installed in an anchor store with appropriate trust settings. Trusting it delegates authority for every name and purpose allowed by local policy and certificate constraints. Import only the public root certificate; a root private key belongs in controlled CA infrastructure, not on client machines.

An intermediate CA normally belongs in chain-building material, not in the root store. Servers should transmit the intermediates needed to connect their leaf certificate to a known anchor. Marking an intermediate as an anchor can change name-constraint, policy, and path-processing behavior because RFC 5280 path validation begins from locally trusted information.

A private CA deployment needs more than certificate import:

1. Define the permitted DNS namespaces, extended key usages, certificate lifetime, and issuance approval policy.
2. Protect online issuing keys with access controls and protected key storage; keep an offline root where the deployment model permits.
3. Distribute only the required public anchors to an explicit user, machine, container, runtime, or application scope.
4. Inventory every store that receives the anchor because removal must reach all of them.

Development interception CAs deserve the same controls. Any holder of the CA private key can issue certificates accepted for arbitrary sites within the clients’ trust policy. Limit the scope and lifetime, never share the generated private key, and remove the anchor after the test.

Ownership, Updates, and Rollback #

Treat trust changes as versioned configuration. Each anchor needs an owner, fingerprint, purpose, approved scope, installation source, activation date, expiry or review date, and removal procedure. Distribution should use managed policy or the platform’s supported update tool so later changes are deterministic.

CA rotation requires an overlap period. Distribute the new root before issuing chains that depend on it, monitor path-building results, and remove the old root only after deployed certificates and clients no longer require it. Keep a tested rollback package that removes the new anchor and restores the previous bundle or trust settings without disabling certificate validation.

Revocation does not reliably undo an accidentally trusted private root because trust-anchor revocation processing is platform-specific. Compromise response must include stopping issuance, replacing affected certificates, removing the anchor from every managed store, rotating CA keys, and investigating certificates issued during the exposure.

Verify Path Building #

Verification must reproduce the target client’s inputs: leaf certificate, untrusted intermediates, trust anchors, DNS name, validation time, intended purpose, and algorithm policy. OpenSSL can diagnose one explicit path:

openssl verify \
  -CAfile organization-roots.pem \
  -untrusted intermediates.pem \
  -purpose sslserver \
  -verify_hostname api.example.com \
  server.pem

The result proves only the OpenSSL invocation’s policy. Also test the real browser, runtime, or application because another path builder can choose a different issuer, trust anchor, or policy. Inspect the served chain with a diagnostic client, confirm the selected anchor’s fingerprint, and test both a valid endpoint and expected failures such as a wrong hostname or unknown root.

Do not use --insecure, disable hostname checks, install a leaf certificate as a broad anchor, or replace the application trust manager to make a test pass. Those actions bypass the property under investigation and can turn a chain configuration error into a production vulnerability.

For certificate structure and path validation details, see X.509 Certificates.

References #

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• Microsoft: Certificate Stores
• Apple: Change the Trust Settings of a Certificate
• Mozilla: Setting Up Certificate Authorities in Firefox
• Java keytool Reference
• OpenSSL verify Documentation