Cryptographic Trust Stores

トラストストアにはローカルのトラストアンカーが含まれ、一部のプラットフォームでは中間証明書や秘密鍵エントリも含まれます。検証者は X.509 証明書パスを構築・検証するときにそれらのアンカーを使います。したがってルートをインストールすると、そのストアを読むすべてのクライアントのセキュリティ境界が変わります。

トラストストアの境界 #

ホストに普遍的なトラストストアはありません。接続は複数の独立したポリシー境界を越えることがあります。

境界	一般的な動作	運用上の問い
オペレーティングシステム	マシン全体およびユーザーごとのアンカーを提供する	どのアカウントとアプリケーションが変更を継承するか
ブラウザー	OS ストアを使うか、独自のルートプログラムとデータベースを保持する	管理ポリシーがブラウザーの既定値を上書きするか
言語ランタイム	OS API、パッケージ化された CA バンドル、ランタイムキーストアのいずれかを使う	どのランタイムバージョンとプロセス設定がストアを選ぶか
アプリケーション	非公開バンドルを同梱するか、選択した発行者や鍵をピン留めできる	発行者が変わったとき誰がバンドルを更新するか

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:

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

開発用インターセプト CA にも同じ制御が必要です。CA 秘密鍵の保有者は、クライアントの信頼ポリシー内の任意サイトで受け入れられる証明書を発行できます。スコープと有効期間を制限し、生成した秘密鍵を共有せず、テスト後にアンカーを削除します。

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.