6.2 数字证书与 PKI：互联网的信任链
6.2 数字证书与 PKI：互联网的信任链
本节摘要：TLS 握手能挡住窃听，挡不住"假公钥"——中间人只需递出自己的公钥冒名顶替。数字证书把身份与公钥的绑定关系交给权威签名，公钥基础设施（PKI）再把权威组织成一棵可验证的信任树。本节拆解 X.509 证书的字段、根与中间 CA 的层级、吊销与证书透明度这两块拼图，并回答那个终极问题：凭什么信任根 CA。
公钥的身份证由谁签发
4.3 节的中间人攻击还留着一个尾巴：DH 与 ECDHE 解决了协商，但若攻击者在 ClientHello 后直接把自己的证书与公钥递上来，客户端凭什么拒绝？协议层无法分辨——它验证的只是"签名对得上"，而攻击者的自签证书签名同样对得上。缺的是一环："这把公钥确实属于这个域名"的第三方背书。
数字证书就是这份背书的标准化形态。X.509 证书把一组关键信息绑在一起：主体（域名或组织，浏览器校验的是 SAN 扩展里的域名）、主体公钥（站点真正的公钥）、有效期、密钥用途扩展，最后由签发者（CA）对以上全部内容的摘要做数字签名（4.5 节的哈希再签名在此落位）。签名把"身份—公钥"钉死：改公钥，摘要变，签名失效；改域名，同理。验证就是一次摘要比对加一次公钥验签。
图：从根 CA 到站点的证书信任链
二、吊销与透明度：信任链的两块补丁
信任树不是装完就完事，两块补丁各堵一段盲区。吊销处理"证书还没到期但已经不该被信"：私钥泄露、域名易主、签发失误。传统方案是证书吊销清单（CRL，定期下发黑名单）与在线状态协议（OCSP，逐证书实时查询），前者滞后、后者既慢又向 CA 泄露用户浏览记录，浏览器普遍"软失败"（查询超时就放行），吊销体系的实际效力长期打折。改进包括 OCSP 装订（服务器代为取回签名状态随握手附上）与短有效期化——Let's Encrypt 把证书压到 90 天，业界正走向 47 天级别，让"吊销"逐渐被"快速过期"取代。
**证书透明度（CT）**处理另一个盲区：CA 乱签证书，公众根本看不见。2011 年荷兰 CA 巨头 DigiNotar 被入侵后给包括谷歌域名在内的大量站点签发了假证书，伊朗用户被精准中间人，事件曝光后该公司一个月内破产——暴露的正是"签发不可审计"。CT 要求所有证书进入公开可审计的日志（同样是 5.3 节默克尔树的用武之地），浏览器拒绝没有 CT 记录的证书。事后审计、事前威慑，WebPKI 的治理从"信任 CA 的良心"转为"信任公开日志的数学"。
用 Python 看一眼某站点的真实证书：
import ssl, socket hostname = "example.com" ctx = ssl.create_default_context() # 载入系统信任库，强制校验链 with socket.create_connection((hostname, 443), timeout=5) as sock: with ctx.wrap_socket(sock, server_hostname=hostname) as tls: cert = tls.getpeercert() # 校验通过后才拿得到证书 print(cert["subject"]) # 主体信息 print(cert["notAfter"]) # 有效期至 print(tls.version()) # 协商到的 TLS 版本
把 hostname 换成任意站点即可复现浏览器的整套链式校验——校验失败这里直接抛异常，连证书都拿不到。
💡 关键直觉：PKI 本质是一台"信任的批发商"机器：根 CA 用物理隔离换可信，中间 CA 用可吊销性换安全，短有效期与公开日志用速度与透明换治理。信任不再是无从检验的口碑，而是一条每一环都能验签的链。
排错速查：浏览器证书报错拆解
报错一：证书颁发机构无效。常见原因有四：系统时钟漂移导致证书"未生效"或"已过期"；服务器漏配中间证书，信任链在半路断掉；企业网或公共网络中的代理在拦截 TLS；以及真正的自签名证书。前三种都可修复，第四种则应警惕——它可能正是中间人攻击的样子。
报错二：域名不匹配。证书保护的是 SAN 扩展里列出的名字，访问裸 IP 或未列出的子域都会触发；泛域名证书只覆盖一层子域，多级子域需要单独列入。
报错三：链中证书被吊销或透明度日志缺失。前者多用 OCSP 装订缓解，后者意味着签发流程不规范，浏览器有权直接拒绝。
排查方面，openssl 的 s_client 子命令可以拉取任意站点的完整证书链与握手详情，配合浏览器的安全面板，绝大多数证书问题都能在十分钟内定位。运维侧建议：用 ACME 协议自动续期、部署时确认中间证书完整、对到期时间做监控——证书过期导致服务中断，至今仍是运维事故榜的常客。
信任库治理与私有 PKI
浏览器的信任库并非黑箱：主流开源信任库有公开的收录政策，CA 需通过年度审计、技术合规检查与事故披露才能留在库里，违规者的处置记录全部公开可查。对企业而言，另一条常见路线是私有 PKI：内部服务之间用自家根 CA 签发的证书完成双向认证（mTLS），信任根由企业自己掌管，服务网格与零信任架构里处处可见。两套体系可以并存：对外走公共信任库，对内走私有信任链，交汇处由网关翻译。搭建私有 PKI 的常见失误是根私钥常年在线与证书链缺少名称约束——前者把信任根暴露在联网主机上，后者让一张内部证书被滥用到任意域名都可通过校验。治理私有信任库与治理代码仓库一样，需要清单、轮换与审计三件套。
常见问答：内网服务要不要上证书
问：纯内网服务是否可以裸奔 HTTP？不建议。内网不等于可信网络——横向移动是现代入侵的标准动作，而部署私有 CA 或 ACME 自动签发后，加 HTTPS 的边际成本已接近于零。证书除了加密还提供身份校验，恰好能挡住内网里的仿冒服务与中间人。务实的分层做法是：对外服务走公共证书与完整链校验，内部服务走私有 CA 与双向证书认证，管理面单独隔离。信任链的工程学，同样是内网的工程学。
本节要点回顾
- 证书的作用：X.509 用 CA 签名把"域名—公钥"钉死，中间人的假公钥在链式验签处被拒；
- 信任树：根离线自签、中间在线签发、叶子挂站点，预装的只是树根，隔离与可吊销换来工程安全；
- 吊销拼图：CRL 滞后、OCSP 隐私与软失败，短有效期正取代传统吊销，装订补传输盲区；
- 透明度：DigiNotar 事件催生 CT 公开日志，默克尔树让"CA 乱签"从秘密变成可审计的公开记录。
信任链搭完，互联网之外的场景怎么自建保密？下一节看 PGP 的混合加密骨架、磁盘加密的密钥层级，以及"没有 CA 的世界"里人们如何互信。