SSL/TLS 证书的私钥意外泄露（服务器被入侵、密钥文件被盗取），攻击者利用泄密的证书能伪造身份签发流量、发起中间人攻击。浏览器必如何够快速得知“泄密证书已失效”？

证书的生命周期管理从来不只是“申请与续期”，还包括“安全吊销”。证书吊销机制正是解决证书泄密这一问题的最后防线。

证书吊销早期依赖 CRL（Certificate Revocation List），后来进化到 OCSP（Online Certificate Status Protocol），如今主流则是 OCSP Stapling。

本文将对比三者工作原理、性能开销与隐私问题，并给出 Nginx 与 Apache 的生产级配置方案，帮助开放/运维工程师在兼顾安全性的同时，将首屏加载速度提升 100-300ms。

CRL（证书吊销列表）：早期的下载模式及其延迟弊端

CRL 是最古老的吊销机制（RFC 5280），由 CA（证书颁发机构）定期生成一个“黑名单文件”，里面包含所有已被吊销证书的序列号（Serial Number）、吊销时间和原因码。

CRL 工作流程

1. CA 维护 CRL 文件（通常几 MB 到几十 MB）。

2. 客户端（浏览器、操作系统）定期从 CA 指定的 CRL 分发点（CDP）下载最新列表（HTTP 或 LDAP）。

3. 验证证书时，客户端在本地 CRL 中查找证书序列号，若命中则拒绝连接。

CRL 致命缺陷

1. 延迟严重：CRL 更新周期通常为 1 小时到 7 天（Let's Encrypt 默认 24 小时）。在这段时间内，泄露的证书仍可能被浏览器信任，攻击时间窗口极大。

2. 带宽与存储开销：大型 CA（如 DigiCert）发布的 CRL 可达 50MB+，全球亿级客户端反复下载，浪费巨大流量。移动设备上更成为性能杀手。

3. 单点失败：如果 CRL 分发点宕机，客户端无法获取最新状态，只能按“未知”处理（部分浏览器直接拒绝）。

4. 无法实时：即使 CA 立即吊销，客户端也要等下一次下载周期。

现今纯 CRL（证书吊销列表） 已基本被废弃，仅作为 OCSP 失败时的后备。SSL Labs 评分中，依赖 CRL 的站点会直接扣分。

OCSP（在线证书状态协议）：实时查询的流程与隐私问题

OCSP（RFC 6960）彻底抛弃“下载列表”模式，转为“实时在线查询”。

OCSP 查询流程（客户端主动发起）

1. 客户端从证书扩展字段中读取 OCSP Responder URL（通常是 CA 的专用服务器）。

2. 构造 OCSP 请求（仅含证书序列号、Issuer 信息），通过 HTTP POST 发送到 Responder。

2. Responder 返回签名后的响应：good（有效）、revoked（已吊销）、unknown（未知）。

4. 客户端收到响应后立即决定是否信任证书。

5. 优势：实时性极高——CA 吊销后几秒内即可生效，攻击窗口大幅缩短。

OCSP 性能与隐私代价

1. 额外 RTT：每次 TLS 握手都要多一次 OCSP 请求（通常 100-300ms），首屏加载时间显著增加，尤其在移动弱网环境下。

2. 隐私泄露：OCSP 请求明文包含证书序列号，CA 服务器才能精确知道“你正在访问哪个网站”。大规模监控下，用户浏览行为被 CA 完整记录。

3. 可用性风险：Responder 宕机或被 DDoS 时，浏览器默认策略各异（Chrome 硬失败、Firefox 可配置软失败），导致大量用户无法访问。

4. 放大攻击：攻击者可构造大量 OCSP 请求，对 CA 基础设施发起反射攻击。

尽管 OCSP 解决了 CRL 的延迟问题，但“每次握手都要问 CA”的模式，在高并发站点上成了性能瓶颈。

OCSP Stapling（OCSP 装订）：服务器代劳查询，显著提升首屏加载速度

OCSP Stapling（RFC 6066，又称 TLS Certificate Status Request）是当前最优解：由服务器代替客户端去查询 CA，把 OCSP 响应“钉”（staple）在 TLS 握手消息中直接发给客户端。

OCSP Stapling 工作原理

1. 服务器后台定时（每小时）向 CA 的 OCSP Responder 查询自己证书的状态。

2. 获取到带 CA 签名的 OCSP 响应（缓存有效期通常 7 天）。

3. TLS 握手时，在 Server Hello 之后的 Certificate Status 消息中，把 OCSP 响应一起发送给客户端。

4. 客户端无需额外网络请求，直接验证响应签名即可知道证书状态。

OCSP Stapling 性能的提升

1. 消除客户端额外 RTT，握手时间减少 100-300ms，首屏加载速度提升 15-40%（实测移动端更明显）。

2. 客户端只收到一次 stapled 响应，带宽占用极低。

3. 隐私保护：CA 不再知道具体用户访问了哪个站点（服务器统一查询）。

4. 可用性提升：即使 OCSP Responder 临时故障，服务器仍可使用缓存响应（直到缓存过期）。

OCSP Stapling 生成推荐配置

1. Nginx

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate fullchain.pem;
    ssl_certificate_key privkey.pem;

    # 开启 OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;          # 验证响应签名
    ssl_trusted_certificate /etc/ssl/certs/ca-bundle.pem;  # 根证书链

    # DNS 解析器（必须配置）
    resolver 8.8.8.8 1.1.1.1 valid=300s;
    resolver_timeout 5s;
}

2. Apache

SSLEngine on
SSLCertificateFile fullchain.pem
SSLCertificateKeyFile privkey.pem

SSLUseStapling On
SSLStaplingCache "shmcb:logs/stapling_cache(150000)"
SSLStaplingResponderTimeout 5
SSLStaplingResponseMaxAge 86400   # 缓存 24 小时

3. OCSP Stapling 配置后用 openssl s_client -connect example.com:443 -status 验证效果，如果返回 “OCSP Response Status: successful” 即可确认生效。

CRL / OCSP / OCSP Stapling 性能对比

1. CRL：延迟最高（小时级）、带宽浪费最大，已基本淘汰。

2. 纯 OCSP：实时但额外 RTT + 隐私泄露，适合低流量站点。

3. OCSP Stapling：实时 + 零额外 RTT + 隐私保护，推荐的方案。Cloudflare、阿里云 CDN 已默认全站开启。

SNI 让共享 IP 的多站点 HTTPS 成为现实

1. 促使云主机、VPS、CDN 成本大幅下降。

2. Let's Encrypt 免费证书大规模普及（一个 IP 可签无数张）。

3. HTTP/2 + HTTP/3 多路复用在共享环境下的高效部署。

开放运维建议

1. 开启 ssl_stapling_verify on 防止伪造响应。

2. 配合 HSTS + TLS 1.3，进一步压缩握手开销。

3. 监控工具：Prometheus + ssl_exporter 监控 Stapling 缓存命中率；若命中率低于 95%，需加大缓存。

4. 紧急吊销场景：CA 吊销后立即重载 Nginx/Apache（nginx -s reload），让新 OCSP 响应生效。

5. 后备机制：配置 CRL 作为 Stapling 失败时的 fallback（Nginx ssl_stapling 结合 ssl_crl）。