[!info] related notes

• 公钥密码: 非对称密码学
• 数字签名: 数字签名
• RSA: RSA
• HTTPS: HTTPS
• TLS 排障: TLS 握手失败排查

Public Key Infrastructure（PKI）

一句话定义

PKI 解决：

某个 public key 为什么值得被相信属于某个名称、组织或实体？

它不是 encryption algorithm。

它是一套：

• certificate format；
• CA hierarchy / trust anchor；
• certificate issuance；
• validation；
• revocation/status；
• policy/process；

共同组成的 trust infrastructure。

Certificate 的核心作用

X.509 certificate 典型地绑定：

subject identity / DNS name + subject public key + validity + extensions

并由 issuer 签名。

浏览器验证 certificate 的关键不是“证书文件存在”，而是：

能否构造并验证一条最终到达本地可信 trust anchor 的 certification path。

Trust Anchor

Trust Anchor 是验证链的起点。

在 Web PKI 中通常来自：

• OS trust store；
• browser trust store；
• enterprise-managed trust store。

Root CA 常以自签 certificate 形式分发，但：

root certificate 被信任的原因不是“它自签名”，而是它被本地策略预先配置为 trust anchor。

Certificate Chain

典型：

Root CA → Intermediate CA → Leaf / End-Entity Certificate

客户端通常验证：

• signature chain；
• issuer / subject relation；
• validity period；
• Basic Constraints；
• Key Usage / Extended Key Usage；
• name binding；
• policy constraints；
• revocation/status policy；
• algorithm/security requirements。

不是只验证最后一张证书上的签名。

DNS Name Binding

HTTPS 中访问：

https://api.example.com

客户端必须验证 certificate 是否对该 hostname 有效。

现代 X.509/TLS 主要依据 Subject Alternative Name（SAN）中的 DNS identity。

因此：

certificate signature valid ≠ hostname match

两者都要成立。

Root / Intermediate / Leaf

Root CA

• trust anchor；
• private key 通常高度保护；
• 很少直接签大量 leaf。

Intermediate CA

• 由上级 CA 授权；
• 实际签发大量 end-entity certificate；
• 可以做 policy / operational isolation。

Leaf Certificate

• 网站、服务、用户或设备实际使用；
• public key 用于相应 TLS / signature / authentication operation。

Issuance

典型流程：

subject generates key pair
→ creates CSR
→ CA validates requested identity/control
→ CA signs certificate
→ certificate issued

注意：

CA 通常不需要也不应该拿到 subject private key。

PKI 管理的是 identity ↔ public key binding，不是集中收集所有私钥。

Revocation

certificate 到期前，如果：

• private key 泄漏；
• 域名/主体不再受控；
• certificate 错签；
• policy 被违反；

可能需要撤销。

常见机制：

• CRL；
• OCSP；
• 浏览器/平台的其他 revocation mechanism。

但 revocation 在实际 Web PKI 中存在 availability、latency、privacy、soft-fail 等 trade-off。

所以不能把“有 OCSP = 所有撤销一定即时可靠”作为绝对结论。

Expiration ≠ Revocation

Expiration 是 certificate 的预定有效期结束。

Revocation 是在到期前主动声明不再应信任。

两者语义不同。

PKI 与 TLS

TLS 可以使用 certificate 完成：

• server authentication；
• 可选 client authentication。

之后 session key 通常通过 ECDHE 等 key agreement 建立，并用 symmetric AEAD 保护数据。

因此：

certificate / PKI → authenticate key/name
key agreement → establish session secret
symmetric crypto → protect bulk traffic

不是“HTTPS 全程用 certificate 公钥加密”。

Private PKI

企业内部也可以拥有：

• internal Root CA；
• intermediate；
• device/user/service certificate；
• internal trust store distribution。

只要 client 明确信任对应 root，就能建立自己的 trust domain。

这与 public Web PKI 的 root program 不同。

PKI 不能解决什么

PKI 不能自动保证：

• 网站业务可信；
• 服务没有漏洞；
• private key 没被 endpoint malware 偷走；
• CA 永不误签；
• 用户访问的内容就是善意的。

PKI 解决的是 cryptographic identity binding / trust chain，不是所有安全问题。

学习检查

1. PKI 的核心问题为什么不是“怎样生成公私钥”？
2. Root CA 为什么不是因为“自签名”本身才被信任？
3. certificate path validation 至少要验证哪些层面？
4. signature valid 为什么不能推出 hostname match？
5. expiration 与 revocation 有什么区别？
6. CA 为什么通常不应该获得网站 private key？
7. HTTPS 中 PKI、ECDHE、symmetric AEAD 各自负责什么？
8. 企业 private PKI 与 public Web PKI 的 trust anchor 来源有什么差异？