CA信任链与证书供应链安全第02页：信任模型与证书路径验证

01 · X.509 v3证书结构解析

X.509 v3证书是信任链的"原子"。理解每个字段的安全语义，是理解后续所有治理机制（CT、CAA、名称约束、短寿命改革）的前提。以下按RFC 5280规范逐字段解析：

02 · 信任链三层架构

2.1 根CA：离线、自签、被信任

根CA证书是自签名的（Issuer=Subject），其可信性不来自密码学证明，而来自被人工安装进根证书库这一治理行为。为保护根私钥，行业最佳实践要求根密钥离线保存（air-gapped HSM），日常签发全部由中间CA完成——因此根证书的直接滥用案例在公网极少，但一旦失守后果是全网性的。

2.2 中间CA：日常签发的执行层，也是历史事故的高发层

中间CA连接根与终端：承担业务分域（按品牌/区域/产品线）、算法过渡（新算法中间证书）、技术受限子CA（名称约束）等职能。CCADB披露的已申报中间CA证书数量级达数千张，加上历史遗留的未申报证书，构成了Web PKI最庞大、最难审计的一层。2011—2016年间几乎所有重大信任危机都发生在中间层或其委托环节（第3页逐案分析）。

2.3 终端实体证书：站点/用户/代码的身份载体

叶子证书不具备签发能力（BasicConstraints.cA=false），其EKU限定用途（serverAuth为Web服务器）。钓鱼治理中接触最多的DV证书即属此层——它与正规证书在密码学上完全等价，区别仅在签发前的身份审核强度。

2.4 交叉证书与桥接CA

交叉证书解决两个独立信任域的互联问题：CA-A用自己的私钥为CA-B的公钥签发一张证书，使信任CA-A的用户也能验证CA-B的链。典型用途有二：①新CA冷启动——先由老牌CA交叉签名过渡（新证书链"新根交叉+自身根"双路径）；②跨体系互信（历史上企业联邦、政府PKI互联曾大量使用）。美国曾建设联邦桥CA（Federal Bridge CA）连接各政府机构独立PKI，是桥接模式的公开案例。交叉证书的风险在于路径分叉：同一主体可能同时存在多条有效路径，验证结果取决于客户端实际构建的路径，增加了不可预期性——这也是现代浏览器倾向于精简交叉签名、要求CA明确披露交叉证书的原因。

2.5 真实信任链样例：Let’s Encrypt的链式演进

以Let’s Encrypt为例可直观看到交叉签名的实际形态：其ECDSA链早期同时携带两条路径——一条回溯至自有根ISRG Root X2，另一条经交叉签名回溯至广泛内置的ISRG Root X1（X1又曾由老牌根DST Root CA X3交叉签名），在新根尚未普及的过渡期兼容旧设备；DST Root CA X3于2021年9月30日到期后，通用兼容路径随之失效，Let’s Encrypt完成向纯ISRG链的切换（部分极旧Android设备因验证实现对交叉根过期时间的豁免处理，曾长期继续依赖该路径，属已公开的实现特例）。这个案例说明：交叉证书是有明确生命周期的过渡工具而非永久结构，评估信任链时必须核查每张交叉证书的到期时间与实际依赖比例。

03 · 证书路径验证算法深度解析

RFC 5280 §6定义的验证算法以"显式信任锚列表+待验证证书+验证时间+策略要求"为输入。其关键性质：自底向上验证、逐环维护状态变量——每个中间环节都会累积"允许的名称空间""剩余路径长度""合格策略集合"等约束状态，任一环节不满足即整体失败。核心检查项伪代码如下：

for cert in path(终端证书 → 中间CA序列):
    1. 用上级CA公钥验证 cert 签名
    2. 检查 cert.notBefore ≤ 验证时间 ≤ cert.notAfter
    3. 检查吊销状态（CRL/OCSP，客户端策略决定是否强制）
    4. 非终端证书必须 BasicConstraints.cA = true
    5. pathLenConstraint 逐级递减校验（剩余层数 ≥ 0）
    6. KeyUsage 必须含 keyCertSign（CA证书）
    7. 名称链接：cert.Issuer == 上级证书.Subject
    8. 名称约束状态求值：下级SAN必须落入上级约束集
    9. EKU/策略树按客户端策略求交

3.1 实践中偏离规范的三个真实问题

• 名称链接的"宽松匹配"历史包袱：早期实现允许Subject/Issuer字符串的宽松比较，曾导致不同密钥被误关联；现代实现按DER编码精确比较（RFC 5280要求）。
• 吊销检查的软失败：主流浏览器对OCSP/CRL查询失败默认放行（soft-fail），吊销作为安全机制的实际效力长期受质疑（Heartbleed期间实证），这是短寿命证书改革的动因之一（子课题04详析）。
• 路径构建的多解性：同一终端证书可能存在多条有效路径（交叉证书、AIA下载链差异），不同客户端构建结果不同——攻击面分析时必须考虑"最坏路径"。

04 · 约束机制全景对照

X.509的约束机制是"委托时的缰绳"。下表对照各机制的防什么、由谁签发、公网部署现状：

扩展 OID: 2.5.29.30 (nameConstraints), critical
permittedSubtrees:
  dNSName: example.com          ← 该CA只能为 *.example.com 空间签发
  dNSName: example.org
excludedSubtrees:
  dNSName: hostile.example.com  ← 显式排除子域

05 · 信任锚与交叉信任的治理

5.1 信任锚的来源与差异

同一台设备的信任锚实际由多层软件共同决定：操作系统根库（Windows/ macOS）、浏览器自带根库（Firefox使用自有NSS库，Chrome在部分平台使用Chrome Root Store）、Java/运行时自带库、以及企业MDM推送的受管根。各根库在数量与成员上存在差异——同一站点在不同客户端可能构建出不同的信任链，安全评估必须覆盖目标环境的交集。

5.2 组织侧的信任锚管理

• 基线收敛：定期比对终端信任库与厂商基线，清理历史遗留根（尤其是已退市CA的残留）；
• 受管根的受控使用：企业代理TLS检查需要植入本地根，必须限定受管设备范围、启用审计日志并告知终端用户（合规要求见第8页）；
• 移动端的碎片化：Android 7.0+默认不信任用户安装的CA（应用需显式声明networkSecurityConfig），iOS依赖受管描述文件——移动场景的本地根滥用面较PC时代收窄，但企业侧代理场景反而扩大。

06 · 本节小结与参考来源

小结：信任链的本质是"委托的数学化"——签名算法保证传递的完整性，而委托范围的控制依赖BasicConstraints/EKU/名称约束等扩展与根程序治理的共同作用。公网的现实是：密码学约束手段（名称约束）缺位，治理手段（披露、审计、退出）承担主力——这决定了第3、4页的研究重点。