加密信任存储

信任存储包含本地信任锚，在某些平台上还包含中间证书或私钥条目。验证器使用这些锚构建并验证 X.509 认证路径。因此，安装根证书会改变读取该存储的每个客户端的安全边界。

信任存储边界 #

主机上不存在通用信任存储。连接可能跨越多个独立的策略边界：

Windows 暴露独立的“当前用户”和“本地计算机”存储。“受信任的根证书颁发机构”包含信任锚，“中间证书颁发机构”支持链构建，“个人”可以包含带私钥的终端实体证书。本地计算机根证书影响的主体比当前用户根证书更多，因此需要相应的管理控制。

Apple 平台使用包含用户、管理员和系统域的钥匙串信任设置。Linux 发行版通常从管理员管理的源目录生成系统 CA bundle 和哈希证书目录。路径和更新命令各不相同，因此应使用发行版的证书管理机制，而不是将 PEM 文件复制到猜测的 OpenSSL 目录。

必须测试浏览器和运行时行为，而不是根据推断得出结论。Firefox 可以维护 NSS 证书数据库，而企业策略可以导入或查询平台根证书。Java 应用可以显式选择 JSSE 信任库，否则使用 cacerts 等运行时默认值。Python、Node.js、容器和静态打包应用可能各自选择不同 bundle。应在部署文档中记录实际消费者和配置。

安装根证书、中间证书和私有 CA #

只有将根 CA 证书安装到具有适当信任设置的锚存储中，它才会成为信任锚。信任该证书会将允许的每个名称和用途的权限委托给本地策略和证书约束。只导入公开的根证书；根私钥属于受控的 CA 基础设施，不应放在客户端机器上。

中间 CA 通常应放在链构建材料中，而不是根存储中。服务器应传输将其叶证书连接到已知锚所需的中间证书。将中间证书标记为锚会改变名称约束、策略和路径处理行为，因为 RFC 5280 路径验证从本地信任信息开始。

私有 CA 部署不仅需要导入证书：

1. 定义允许的 DNS 命名空间、扩展密钥用法、证书生命周期和签发审批策略。
2. 使用访问控制和受保护的密钥存储保护在线签发密钥；在部署模型允许时保留离线根证书。
3. 仅将所需的公共锚分发到明确的用户、机器、容器、运行时或应用范围。
4. 清点接收该锚的每个存储，因为移除操作必须覆盖所有存储。

开发拦截 CA 也需要相同的控制。任何持有 CA 私钥的人都可以在客户端信任策略范围内为任意站点签发证书。限制范围和生命周期，绝不要共享生成的私钥，并在测试后移除该锚。

所有权、更新和回滚 #

将信任变更视为版本化配置。每个锚都需要所有者、指纹、用途、批准范围、安装来源、启用日期、过期或复核日期以及移除流程。应使用托管策略或平台支持的更新工具进行分发，使后续变更具有确定性。

CA 轮换需要重叠期。在签发依赖新根的链之前分发新根，监视路径构建结果，并仅在已部署证书和客户端不再需要旧根后移除它。保留经过测试的回滚包，以便移除新锚并恢复之前的 bundle 或信任设置，而不禁用证书验证。

由于信任锚撤销处理依赖平台，撤销并不能可靠地撤销一个被意外信任的私有根。妥协响应必须包括停止签发、替换受影响证书、从每个受管理存储移除锚、轮换 CA 密钥，以及调查暴露期间签发的证书。

验证路径构建 #

验证必须复现目标客户端的输入：叶证书、不受信任的中间证书、信任锚、DNS 名称、验证时间、预期用途和算法策略。OpenSSL 可以诊断一个明确的路径：

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

结果只证明该 OpenSSL 调用的策略。还应测试真实浏览器、运行时或应用，因为另一个路径构建器可能选择不同的颁发者、信任锚或策略。使用诊断客户端检查已提供的链，确认所选锚的指纹，并测试有效端点及预期失败（例如错误主机名或未知根）。

不要使用 --insecure、禁用主机名检查、将叶证书安装为广泛锚，或替换应用信任管理器来使测试通过。这些操作会绕过正在调查的属性，并可能将链配置错误变成生产漏洞。

有关证书结构和路径验证详情，请参见 X.509 证书。

参考资料 #

• RFC 5280：互联网 X.509 公钥基础设施证书和 CRL 配置文件
• Microsoft：证书存储
• Apple：更改证书的信任设置
• Mozilla：在 Firefox 中设置证书颁发机构
• Java keytool 参考
• OpenSSL verify 文档