信任商店和信任链——介绍

    HTTPS 利用公钥加密来保护浏览器通信在互联网上传输时不被拦截或更改。服务器会向访问的浏览器提供公钥，然后使用该公钥为所有后续数据传输建立加密连接。然而，收到可用的公钥并不能保证相应的服务器确实属于合法实体、个人、公司或组织。中间人攻击者有能力篡改网络以分发自己的密钥，从而危及任何通信。

    为了阻止这种形式的篡改，浏览器使用证书对 HTTPS 服务器进行身份验证。这些数字证书是将公钥链接到特定主题的机器身份。这种联系由受信任的认证机构(CA) 确认，该机构通过对已批准数据库进行自动和手动验证来确认证书持有者的身份。

    证书是数字文件，它们遵循文件格式来存储信息（例如签名、密钥、颁发者等）。受浏览器信任的公共信任 PKI 必须符合 RFC 5280，这要求使用 X.509 v3 格式。X.509 v3 允许证书包含其他数据（例如使用限制或策略信息）作为扩展。这些扩展中的每一个都是关键的或非关键的，浏览器需要处理和验证所有关键的扩展。

    证书颁发机构 (CA) 使用私钥对其颁发的所有证书进行加密签名。此签名是不可更改的验证，表明特定 CA 颁发了证书，并且签名后没有进行任何修改。CA 通过拥有与公钥相对应的根证书（也称为信任锚）来声明对此签名密钥的所有权。CA 对根证书的创建、管理和使用受到严格监管和审核，符合 CA/B 论坛设定的基准要求。

    根证书下的所有证书都信任它，并使用根证书的公钥来签署其他证书。根证书的可信度构成了众多软件应用程序（包括浏览器）验证 SSL/TLS 连接的基础。鉴于这些根证书的高价值及其泄露带来的潜在风险，它们很少用于颁发终端实体证书。相反，通常使用中间证书。然后使用这些中间证书为其客户端颁发证书。中间证书在终端实体证书和根证书之间形成“信任链” 。

    根证书下的所有证书都信任根证书，并且根证书的公钥用于签署其他证书。许多软件应用程序继承了此根证书的可靠性，例如浏览器根据根证书的可信度验证 SSL/TLS 连接。由于这些根证书的价值以及证书被盗用的风险，它们很少用于颁发终端实体证书。相反，我们使用中间证书。然后可以使用这些中间证书颁发其客户的证书。中间证书在终端实体证书和根证书之间充当“信任链”。

    它的工作原理如下。根 CA 使用其私钥对中间根证书进行签名，从而使其可信。然后 CA 使用中间证书的私钥对最终用户 SSL 证书进行签名和颁发。此过程可以重复多次，中间根证书对另一个中间证书进行签名，最后对最终实体证书进行签名。从根证书到中间证书再到最终实体的这些链接就是证书链或 信任链。

    仔细观察信任链，并牢记 X.509 v3 证书格式，候选证书路径必须在已识别的信任锚和目标证书（即最终实体证书）之间“命名链”。从信任锚到目标证书，这意味着一个证书中的主题名称必须是路径中下一个证书中的颁发者名称，依此类推。在此示例中，路径以包含信任锚公钥的自签名证书开始。路径以 最终实体证书结束。路径中的所有其他证书都称为中间 CA 证书。请注意，链中除最后一个证书之外的每个证书都是 CA 证书。

    浏览器附带一个内置的受信任根列表，称为信任库。信任库是一组默认受信任的根证书，由操作系统和 Web 浏览器制造商（例如 Apple、Microsoft、Mozilla和 Google）维护。每个供应商都有自己的根证书标准和要求，但它们都要求颁发证书的 CA 接受一次或多次审核，以证明其可信度、有效性和符合 CA/B 论坛基线要求，然后才能将其根证书纳入。要验证证书，浏览器将获得一系列证书，每个证书都已签署序列中的下一个证书，将签名 CA 的根证书连接到服务器的证书。

    一旦建立了潜在的证书路径，浏览器就会利用证书中嵌入的数据对其进行身份验证。如果浏览器能够以加密方式确认，源自信任锚的证书对应的私钥被用于生成路径中的后续证书，并一直到最终实体证书，则该路径被视为有效。RFC 5280 提供了一种浏览器在验证 X.509 证书的证书路径时遵循的传统算法。

    本质上，浏览器会从信任锚开始验证路径中的所有证书，并验证每个证书的基本数据和重要扩展。一旦该过程到达路径中的最后一个证书且没有任何差异，则该路径被视为有效。如果出现不一致，则该路径被标记为无效。

    无论使用哪种扩展，浏览器都必须验证基本证书数据，例如签名或颁发者。浏览器执行的验证顺序如下：

1. 浏览器确认证书的完整性

    证书的签名可以使用标准公钥加密进行验证。如果发现签名无效，则意味着证书在颁发后已被更改，因此将被拒绝。

2. 浏览器确认证书的有效性

    证书的有效期是签名 CA 保证维护其状态信息的时间跨度。浏览器会拒绝任何有效期在验证检查日期和时间之前结束或之后开始的证书。

3. 浏览器检查证书的撤销状态

    证书颁发后，预计会在整个有效期内使用。但是，某些情况可能会导致证书在自然到期前失效。此类情况可能包括证书私钥被怀疑泄露。在这种情况下，CA 必须撤销相应的证书。这是通过使用撤销列表来实现的。

    有两种方法可以通知用户证书吊销。一种是通过证书吊销列表 (CRL)。CA 会定期发布一个带有签名和时间戳的吊销证书列表，称为证书吊销列表 (CRL)。CRL 分发到公共存储库中，浏览器在验证证书时可以获取并查阅 CA 的新 CRL。这种方法的一个缺陷是吊销的时间粒度仅限于 CRL 发布期。只有在所有当前发布的 CRL 都计划更新后，浏览器才会收到吊销通知。根据签名 CA 的政策，这可能要花一小时、一天甚至一周的时间。

    另一种方法是标准文档RFC6960中概述的在线证书状态协议 (OCSP) 。此协议允许浏览器从在线 OCSP 服务器请求特定证书的撤销状态。如果设置正确，OCSP 会更加即时，并避免前面提到的 CRL 更新延迟问题。此外，OCSP Stapling可提高性能和速度。

4. 浏览器验证发卡机构

    通常，X.509 证书与两个特征相关联：颁发者（即拥有签名密钥的实体）和主题（指证书验证的公钥的所有者）。浏览器会验证证书的颁发者字段是否与证书路径中前一个证书的主题字段匹配。

5. 约束处理

    按照上述步骤，浏览器会检查证书约束（如果 CA 已定义这些约束）。路径中的每个证书都可以施加其他约束，所有后续证书都必须遵守这些约束。这些约束可能是名称、策略和密钥用法。