证书颁发机构与信任链

只有当您能够相信某个公钥确实属于您认为的那个人或组织时，非对称加密才有用。如果没有 Trust 机制，攻击者就可以截获您获取他人公钥的请求，并替换成自己的公钥，这就是典型的中间人攻击。Public Key Infrastructure (PKI) 通过引入 Certificate Authority (CA) 解决了这一 Trust 问题。CA 是受信任的第三方，负责对将公钥与经过验证的身份绑定起来的 certificate 进行数字签名。如果您 Trust 该 CA，就可以 Trust 任何经过该 CA 认证的对象。

Certificate Authority (CA) 是一种组织，会在验证 certificate 申请者身份后签发数字 certificate。CA 使用自己的私钥为每个 certificate 签名，使任何 Trust 该 CA 的人都能使用 CA 的公钥验证 certificate 的真实性。CA 分为两类：Public CAs（例如 DigiCert、GlobalSign、Let's Encrypt），其根 certificate 会预先安装在操作系统和浏览器中；以及Private（Internal）CAs，由组织自行运行，用于内部 certificate 签发（VPN、内部 Services、设备 certificate）。

Root CA 是 PKI 层级中的最高 Authorities。Root CA certificate 是自签名的，因为不存在更高层的 Authorities 来验证它们。相反，操作系统供应商（Microsoft、Apple、Mozilla）会通过严格的审计流程审查 Root CAs，并将其 certificate 预先安装在受信任的 certificate 存储区中，因此这些根 certificate 才会受到 Trust。典型浏览器的 Trust 存储区中大约有 130 到 150 个受信任的 Root CAs。如果某个 Root CA 遭到入侵，它签发过的每个 certificate 都会受到怀疑，这就是为什么 Root CA 私钥会存储在离线、物理隔离的硬件安全模块（HSM）中。

Root CAs 很少直接向终端实体签发 certificate。相反，它们会通过向中级 CA 运营者签发 certificate 来创建Intermediate CAs（也称为从属 CA）。Intermediate CAs 随后签发终端实体 certificate（例如 HTTPS 服务器 certificate）。这种委派层级有多个作用：通过让 Root CA 保持离线来保护其私钥（如果某个 Intermediate CA 遭到入侵，只需撤销其 certificate chain，而不必撤销整个根）；允许针对不同用途设置专门的 CA（代码签名与 TLS）；并支持私有 PKI 中的组织层级。

certificate chain（或chain of trust）是从终端实体 certificate 一直回溯到受信任 Root CA 的 certificate 序列。对于典型的 HTTPS 网站，其链为：End-entity cert（例如 *.google.com）→ Intermediate CA cert（例如 Google Trust Services WR2）→ Root CA cert（例如 Google Trust Services LLC）。当您的浏览器访问网站时，它会验证整个链，检查每个 certificate 的签名是否由其上一级签发，并检查根是否位于 Trust 存储区中。该链中的任何断点都会导致 certificate error。

当两个独立的 PKI 层级需要建立相互 Trust 时，它们会使用交叉认证。每个 CA 都向对方的根签发 certificate，从而建立双向 Trust。Bridge CA 是一个中央枢纽 CA，它与多个领域 CA 进行交叉认证，在不同组织或政府机构之间建立 Trust 网。US Federal Bridge CA 连接了多个联邦政府 PKI 系统。交叉认证管理起来较为复杂，但在组织合并或建立机构间 Trust 时十分必要，这样既无需将所有系统合并为单一层级，又能实现相互 Trust。

Registration Authority (RA) 是代表 CA 执行身份验证、但不自行签发 certificate 的实体。RA 接收 certificate 请求，验证申请者身份（根据 certificate 类型，可能通过文件检查、域验证或现场验证），然后将批准的请求转发给 CA 进行签名。这种委派使 CA 能够扩大签发规模，而无需亲自执行所有验证工作。在企业 PKI 中，RA 可能是负责验证员工 certificate 请求的 HR 部门或 IT helpdesk。

CA 会提供不同验证级别的 certificate，以反映对申请者身份进行核验的彻底程度。Domain Validation (DV)：CA 只验证申请者是否控制该域名（自动完成，几分钟即可，用于 Let's Encrypt）。Organization Validation (OV)：CA 验证组织是否合法存在（1 至 3 个工作日）。Extended Validation (EV)：最彻底的审查，包括法定身份、实际地址和经营情况（1 至 2 周，用于在浏览器地址栏显示绿色公司名称）。对于基本加密，DV 已经足够；对于银行网站等高价值目标，则适合使用 EV。

certificate 固定是一种技术：应用程序通过硬编码，仅 Trust 特定的 certificate 或 CA，而不是 Trust 来自任意受信任 Root CA 的所有 certificate。即使攻击者从受信任 CA 获取了伪造 certificate，这种技术也能防止 MITM 攻击。移动应用和安全敏感型应用会使用固定机制，确保只接受自有服务器的 certificate。缺点是：如果被固定的 certificate 过期或轮换，应用程序就会停止工作，直到应用完成更新。HPKP（HTTP Public Key Pinning）曾是一种基于浏览器的固定机制，但由于错误部署风险，目前已被弃用。

组织会运行自己的private CA来满足内部 certificate 需求，例如验证 VPN 客户端、为内部 HTTPS Services 签发 certificate、签署代码以及验证设备身份。Microsoft Active Directory Certificate Services (AD CS) 是最常见的企业私有 CA。内部 CA certificate 必须分发到所有需要 Trust 内部签发 certificate 的设备和浏览器，通常通过组策略完成。Private CAs 无法签发受公共互联网 Trust 的 certificate，其使用范围仅限于安装了私有 CA 根 certificate 的组织设备。

DigiNotar compromise (2011) 是 Security+ 考生需要了解的最重要 CA 事件。荷兰 CA DigiNotar 遭到攻击者入侵，攻击者为 Google、Mozilla 以及政府域名签发了 fraudulent certificate。这些 certificate 被用于伊朗，对公民实施中间人攻击。结果是：所有主要浏览器和 OS 供应商都立即将 DigiNotar 从其受信任的根存储区中移除，使 DigiNotar 曾签发的所有 certificate 失效。DigiNotar 在数周内破产。该事件表明，CA 入侵会造成灾难性后果，也说明了为什么如今要求使用 CAA DNS 记录、Certificate Transparency，以及对 CA 系统实施多因素身份验证。

测试您对本课 CompTIA Security+（SY0-701）概念的理解。

本课您学到了：Certificate Authorities 将公钥绑定到经过验证的身份；信任链从终端实体经过中间 CA 延伸到自签名根；Root CAs 离线保存在 HSM 中，并由操作系统预先信任；而 CA 被攻破（DigiNotar）可能使数百万张证书失效。接下来我们将学习X.509 证书结构。