公钥基础设施PKI

复习定位

PKI解决了"如何安全地分发公钥"的问题。当你通过HTTPS访问example.com——服务器发送它的SSL证书给你——你的浏览器验证证书上的数字签名——确保证书是由受信任的CA签发的且内容未被篡改——然后从中提取服务器的公钥——用于加密对称密钥。这个信任链的基础是根CA证书预装在浏览器和操作系统中——如果根CA被攻破——整个信任体系就崩塌。

X.509数字证书

数字证书将一个公钥与会话主体的身份绑定在一起——由CA数字签名——内容包括：

• 版本号(1/2/3)
• 序列号(CA唯一标识该证书的整数)
• 签名算法标识(如sha256WithRSAEncryption)
• 颁发者(CA的名称)
• 有效期(notBefore, notAfter)
• 主体(证书持有者——如域名example.com)
• 主体公钥信息(算法+公钥值)
• 颁发者唯一ID和主体唯一ID(可选)
• 扩展(v3——密钥用法、基本约束、CRL分发点等)
• CA的数字签名(用CA的私钥对证书摘要签名)

证书链与信任锚

浏览器内置了约100+个根CA证书(在操作系统/浏览器信任存储中)。当服务器发送一个证书时——浏览器可能只收到了终端实体证书——但需要验证层层向上到根：

1. 服务器发送服务器证书(由中间CA签发)。
2. 浏览器查找服务器证书的CA信息——用中间CA的公钥验证服务器证书的签名。
3. 如果浏览器没有中间CA证书——它可能需要从服务器获取或查找缓存——中间CA证书也有签发者(根CA)——浏览器从信任存储中找到根CA证书——用根CA的公钥验证中间CA证书的签名。
4. 根CA是"信任锚"——浏览器自身信任的——无需再向上验证。

CRL与OCSP

CRL(证书吊销列表)——CA定期发布已吊销的证书序列号列表——浏览器(或应用)下载并检查证书是否在列表中。但CRL有滞后性(更新频率可能一天一两次)——OCSP在线查询解决了实时性问题。

OCSP(在线证书状态协议)——实时查询(HTTP GET/POST)指定证书是否被吊销(返回good/revoked/unknown)。OCSP Stapling将OCSP响应由服务器保存在TLS握手时发给客户端——减少客户端的OCSP请求——提升性能并保护隐私。

理解信任模型

PKI的信任模型不是完美的——CA可能被攻破|颁发给非授权域名|因错误的验证签发恶意证书。为了解决这个问题——证书透明度(CT, Certificate Transparency)要求CA将每个新颁发的证书提交到公共日志服务器——域名所有者可以监控是否有"冒用自己域名的证书被颁发"——发现恶意证书及时处理。CT现在是主流浏览器对HTTPS证书的要求。

复习检查

1. PKI中CA签名的意义——CA用自己的私钥加密证书摘要——任何拥有CA公钥的人都可以解密验证证书内容是否被篡改。

2. 证书链如何验证——从底层证书起——可依次向上用上一级证书的公钥验证下一级证书的签名——最后到浏览器信任的根证书——形成一条完整的信任链。

3. CRL和OCSP的差异——CRL是全面清单(周期性更新——有延迟)——OCSP是单次查询(实时)——前者离线后也可验证但可能使用已吊销的证书很长一段时间——后者必须联网但准确实时。

4. 证书透明度(CT)的作用——防止CA在域名所有者不知情的情况下签发该域名的SSL证书——因为公有日志服务器分发了证书的副本——任何组织都可以监控。

5. 如果根CA的私钥泄露——会发生什么——攻击者可以签署任何域名的假证书——用户的HTTPS连接被中间人攻击而无法察觉——浏览器看到证书来自受信任的CA——不会发出警告。此时必须立即将该根CA从所有浏览器信任列表中移除(不信任)→所有由它签发的下级证书全部失效。