上两篇我们讲了加密、哈希、口令。这一篇上升到”信任”层面：你在浏览器输入 https://bank.com，怎么确定对面真是银行、而不是黑客伪造的钓鱼站？靠的是 PKI（公钥基础设施） 和 TLS 证书。

读完这篇，你能说清”绿色小锁”背后发生了什么，以及证书为什么能防伪。

核心难题：公钥怎么证明身份

非对称加密里，你用对方公钥加密，只有对方私钥能解。但问题来了：你怎么确定手里这个”公钥”真的是银行的，而不是黑客伪造的？ 如果你误用了黑客的公钥，你以为在和银行通信，其实全程对黑客说悄悄话。

这就需要有个可信第三方来”背书”：证明”这个公钥确实属于 bank.com”。这个体系就是 PKI。

PKI 的四大角色

• CA（证书颁发机构）：可信的第三方，负责验证身份并签发数字证书。浏览器/系统内置了几十个根 CA 的公钥，天然信任它们。
• 证书（Certificate）：一份”身份证”，把公钥 + 持有者身份（域名/组织）+ 有效期 + CA 签名绑在一起。核心是用 CA 的私钥对”公钥+身份”做数字签名。
• RA（注册机构）：帮 CA 审核申请者身份（确认你真拥有该域名）。
• 证书库/吊销机制：证书丢了私钥或出问题，要能吊销（CRL/OCSP）。

证书链：为什么信任能传递

你访问 bank.com，它给你一张证书。你怎么信？因为证书上有上级 CA 的签名。你顺着”网站证书 → 中间 CA → 根 CA”一路验证签名，只要最顶层的根 CA 公钥在你系统里（预置信任），整条链就可信。这叫证书链（Certificate Chain）。

你的浏览器
  └─ 信任内置根 CA 公钥
       └─ 根 CA 签名了 中间 CA
            └─ 中间 CA 签名了 bank.com 证书
                 └─ 于是你信任 bank.com 的公钥

如果任何一环签名对不上（比如黑客自己签的假证书），浏览器立刻报”证书不受信任”——这就是小锁和红色警告的来源。

TLS 握手：一次安全通信怎么建立

https:// 的背后是 TLS（传输层安全）协议。它把前面学的密码学全用上了。简化版握手：

1. 客户端 Hello：浏览器告诉服务器自己支持的加密套件。
2. 服务器发证书：把 bank.com 的证书（含公钥）发过来。浏览器验证证书链。
3. 协商对称密钥：浏览器生成一个随机的对称会话密钥，用服务器公钥（证书里的）加密发给服务器。只有服务器私钥能解——这就安全地把对称密钥交给了对方（解决了密钥分发）。
4. 切到对称加密：此后双方用这个会话密钥做对称加密，传输真正数据（因为快）。
5. 完整性：传输内容带 MAC/哈希，防篡改。

你看，这正是上篇说的组合拳：非对称加密安全地交换密钥 + 对称加密传输数据 + 证书/签名验证身份 + 哈希保完整。

证书怎么获取（实战）

现代最方便的是 Let’s Encrypt（免费、自动签发）配合工具 Certbot：

# 自动为域名申请并配置证书（以 Nginx 为例）
certbot --nginx -d example.com -d www.example.com

它会自动验证你对该域名的控制权、签发 90 天有效证书并配置 Web 服务器，到期前还能自动续期。小到个人站、大到企业，基本都走这套。

常见认知误区

• “有 HTTPS 小锁就绝对安全”：小锁只证明”你和对方建立了加密通道且对方证书可信”，不证明对方是合法网站——钓鱼站也能申请到合法证书。还要看域名是不是真官网。
• “自签名证书能用就行”：自签名证书没有可信 CA 背书，浏览器会警告。仅适合内部测试，生产必须用受信任 CA 签发。
• “证书永久有效”：证书有有效期（现在多≤1年），过期会导致服务不可用。务必配自动续期。
• “私钥可以随便放”：私钥一旦泄露，别人能用它伪造你的身份、解密流量。私钥必须严格保密、权限收紧。
• “HTTP 升级到 HTTPS 只改协议”：还要把站内资源（图片/脚本）链接改成 HTTPS，否则出现”混合内容”被浏览器拦。

证书里到底有什么：关键字段

一张 X.509 证书（最常见的格式）包含：

• 主体（Subject）与颁发者（Issuer）：谁持有、谁签发。域名证书 Subject 里是 CN=example.com，现代更常用 SAN（Subject Alternative Name） 列多个域名（含 www 和裸域）。
• 公钥：证书持有者的公钥（注意：私钥绝不在证书里）。
• 有效期（Not Before / Not After）：证书只在一段时间内有效，过期浏览器就拒。
• CA 的数字签名：CA 用自己私钥对上面所有字段签名，任何人用 CA 公钥验证签名，确认”这些内容没被篡改且确由该 CA 签发”。

证书常见格式：PEM（文本，以 -----BEGIN CERTIFICATE----- 开头，可直读）和 DER（二进制）。Web 服务器通常用 PEM 的证书+私钥两个文件。

吊销机制：证书丢了怎么办

证书私钥泄露、或签发有误，得能让它”作废”。两种机制：

• CRL（证书吊销列表）：CA 定期发布被吊销证书的序列号清单，浏览器下载比对。缺点是列表会越来越大、有延迟。
• OCSP（在线证书状态协议）：浏览器实时问 CA”这张证还有效吗”，得到”有效/吊销/未知”。更快但涉及隐私（CA 知道你在访问谁）。

现代演进是 OCSP Stapling：由服务器自己定期向 CA 取 OCSP 响应并”钉”在 TLS 握手里发给浏览器，既快又保护隐私。配置 Web 服务器时建议开启。

双向 TLS（mTLS）：不只验服务器，也验客户端

普通 HTTPS 只验证”服务器是真银行”。但服务间调用（如微服务、API 网关对内网服务）还需要验证”调用方也是我信任的服务”。mTLS（双向 TLS） 让双方都出示证书、互相验证：

• 内部服务 A 调服务 B，B 要求 A 提供客户端证书，验证通过才放行。
• 常用于零信任网络、服务网格（如 Istio）、数据库客户端认证。

mTLS 把”身份”从”网络位置（IP 白名单）“升级为”密码学证书”，即使流量被截获或 IP 被伪造，没有合法证书也进不来。

证书透明度（CT）与防误签发

历史上出现过 CA 被攻破、错误签发了 *.google.com 之类证书的事故。为防范，证书透明度（Certificate Transparency） 要求 CA 把签发的每张证书公开记录到不可篡改的日志里，域名主人可监控”有没有人给我域名发了证”，及时发现误签发/恶意签发。主流浏览器已强制要求证书带 CT 证据，否则不信任。

运维清单：证书别出事

• 用 Let’s Encrypt + Certbot 自动签发并续期（90 天一轮），别手动管。
• 把私钥权限收到 600、存到安全位置，绝不进代码仓库、绝不打进容器镜像明文。
• 监控证书到期，提前告警（很多故障是”证书凌晨过期、服务挂了才发现”）。
• 站内资源全改 HTTPS，消除”混合内容”警告。
• 内网/服务间通信考虑 mTLS，而非仅靠网络隔离。

小测验：看看你掌握了没

• 问题一：证书为什么能防伪？答案：含 CA 对”公钥+身份”的数字签名，验证证书链到预置信任的根 CA 即可确认身份。
• 问题二：TLS 为什么先非对称后对称？答案：非对称安全交换对称会话密钥（解决分发），对称加密后续大数据（快）。
• 问题三：自签名证书能上生产吗？答案：不能，无可信 CA 背书浏览器报警，仅限内部测试；生产用受信任 CA（如 Let’s Encrypt）。

这一篇你该记住的

• 难题：如何确信对方公钥是真的。PKI 用可信 CA 背书解决。
• 四角色：CA（签发/信任锚）、证书（公钥+身份+签名）、RA（审核）、吊销机制。
• 证书链：网站证→中间 CA→根 CA，根 CA 公钥预置信任，整链可信则身份可信。
• TLS 握手：验证证书→非对称交换对称密钥→对称加密传数据→哈希保完整。
• 实战用 Let’s Encrypt + Certbot 免费自动签发；私钥严保、证书按期续、别用自签名上生产、防混合内容。

密码学三篇收尾——它是安全领域的数学地基。最后我们补上合规：当技术之外，法律和标准如何要求你”必须这么做”。