3、证书链优化：从根源减少TLS握手延迟

证书链，说白了就是浏览器验证你网站身份时，要一路追溯到根证书的那条信任路径。很多团队只关注了证书本身有没有过期，却忽略了证书链的长度和验证开销。我见过一个极端案例——某电商平台的证书链长达7级，每次TLS握手光验证证书就要花掉近300毫秒。嗯，这显然是个坑。

3.1 证书链长度与验证开销

证书链越长，验证开销越大。为什么？因为客户端需要逐级验证每个证书的签名，直到找到信任的根证书。每多一级，就多一次签名验证、多一次证书解析、多一次网络请求（如果中间证书不在本地缓存）。

我个人习惯把证书链长度控制在3级以内：根证书 → 中间证书 → 服务器证书。超过3级，性能就开始明显下滑。

证书链优化的第一原则：能短则短，能直连则直连。如果CA支持，尽量使用由根证书直接签发的服务器证书，跳过中间证书。

3.2 OCSP Stapling：把验证压力扛在服务端

证书吊销状态检查，传统做法是客户端自己去OCSP服务器查询。这会导致两个问题：一是客户端多一次网络请求，延迟增加；二是OCSP服务器可能挂掉，导致验证失败。

OCSP Stapling 的原理很简单：服务端替客户端去查。服务端定期向OCSP服务器获取证书状态，然后在TLS握手时，直接把状态信息“钉”在Certificate消息里发给客户端。客户端拿到后，就不用再自己去查了。

配置OCSP Stapling，以Nginx为例：

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # 开启OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # 指定信任的根证书（用于验证OCSP响应）
    ssl_trusted_certificate /path/to/ca-bundle.pem;

    # OCSP响应缓存时间
    ssl_stapling_cache_size 1m;

    # DNS解析器（用于查找OCSP服务器）
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

你可能会问：如果OCSP服务器挂了怎么办？嗯，Nginx默认行为是软失败——拿不到OCSP响应时，仍然继续握手，但不会发送Stapling信息。客户端会回退到自己去查。我个人建议保留这个默认行为，别因为OCSP问题导致整个服务不可用。

3.3 证书压缩：给证书链“瘦身”

证书链再短，也有几KB到十几KB。在弱网环境下，这额外的传输开销不可忽视。证书压缩技术，就是给证书链做一次“瘦身”。

目前主流方案有两种：

• Gzip压缩：TLS 1.3支持对Certificate消息进行Gzip压缩。压缩率通常在60%-80%，能把10KB的证书链压到2-3KB。
• 证书指纹缓存：客户端缓存证书的指纹（Hash），服务端只发送指纹，客户端本地匹配。这需要客户端和服务端都支持，目前还在标准化过程中。

Gzip压缩的配置很简单，以Nginx为例：

# 在http块中开启
ssl_certificate_compression on;

# 可选：指定压缩算法（默认gzip）
ssl_certificate_compression_types gzip;

证书压缩的实际效果，我拿一个真实项目的数据来说明：

你看，虽然单次节省的时间不多，但在高并发场景下（比如每秒上万次TLS握手），累积的收益非常可观。

3.4 证书链优化知识体系

下面这张图，帮你把证书链优化的核心逻辑串起来：

证书链优化，说白了就是三个方向同时发力：缩短长度、转移验证压力、压缩传输体积。我建议你按照这个优先级来：先控制证书链长度（收益最大），再开启OCSP Stapling（收益稳定），最后考虑证书压缩（锦上添花）。