4.1 全站HTTPS上线纪实

4.1 全站HTTPS上线纪实

本节摘要：HTTPS 上线的完整路径是证书准备、双协议灰度、强制跳转、握手优化四步。会话复用与 HTTP/2 能把 TLS 开销摊薄到近于无形，"HTTPS 慢"多数是配置缺课。

证书准备

从证书机构拿到的是一张全链证书，中间证书必须拼上，否则部分客户端（尤其老安卓与某些 JDK）会报"证书链不完整"：

cat fullchain.crt private.key > 检查用
openssl x509 -in fullchain.crt -noout -dates -subject
​

自签或内部系统可用 openssl 生成，注意 SAN 而不是 CN 才是现代客户端校验的字段。

双协议共存与灰度

一刀切跳 HTTPS 是事故之源：搜索引擎收录的 http 链接、第三方回调、老客户端会在切换瞬间大面积断裂。正确的节奏是先共存：

server {
    listen 80;
    server_name shop.example.com;
    location /.well-known/acme-challenge/ {     # 证书续期通道保留
        root /data/www/cert;
    }
    location / {
        return 301 https://$host$request_uri;   # 其余逐步跳转
    }
}

server {
    listen 443 ssl;
    http2 on;                                   # 新版语法，旧版写作 listen 443 ssl http2
    server_name shop.example.com;

    ssl_certificate     /etc/nginx/certs/fullchain.crt;
    ssl_certificate_key /etc/nginx/certs/private.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:20m;         # 会话缓存：worker 间共享
    ssl_session_timeout 1d;
    ssl_session_tickets on;
}
​

灰度期间可观察 443 流量占比，超过九成再对残余 http 强硬。稳定后加 HSTS 头，让浏览器记住"只走 https"：

add_header Strict-Transport-Security "max-age=31536000" always;
​

⚠️ HSTS 一旦下发，max-age 内浏览器拒绝访问 http——本地调试与回退窗口要提前规划，先用小 max-age 试运行。

握手开销的真相

压测对比（2000 并发，100KB 页面）：

纯 HTTP           P99 = 78ms
HTTPS 无会话复用   P99 = 146ms   ← 首次握手 +1RTT~+2RTT
HTTPS 会话复用     P99 = 89ms    ← 短连接场景改善明显
HTTPS 会话复用+HTTP2 P99 = 82ms  ← 多路复用再省建连
​

结论直接写在数据里：TLS 的成本集中在握手，会话缓存让第二次连接跳过最贵的一步；HTTP2 再把同域名多请求挤进一条连接。两个开关（ssl_session_cache、http2）覆盖了九成的性能疑虑。TLS1.3 进一步把握手压到 1-RTT 且恢复连接 0-RTT，协议版本不要保守。

图：一次 HTTPS 请求的时间构成

上线前三项自检

证书配置完成后，三项检查全部通过才允许切流量。第一项验证链完整性与剩余有效期：

# 从外部视角检查证书链（在客户端机器上执行，不要在服务器本机）
openssl s_client -connect shop.example.com:443 -servername shop.example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates -issuer
# Verify return code: 0 (ok) 才算链完整；issuer 应是签发 CA 而不是自己
​

第二项核对覆盖域名：证书的 SAN 列表必须包含所有对外域名，www 与裸域各算一条，漏一条就有一半用户报证书不匹配。第三项确认续期通道：ACME 目录在 80 端口保留后，用 dry-run 模式跑一次续期命令，确认挑战路径可达。

半夜证书过期的复盘

某次真实故障：凌晨三点起，移动端大量请求失败。现象很典型——错误集中在部分老机型，桌面浏览器正常。定位过程十分钟：外部 openssl 检查发现证书还剩两天有效期，不是过期；对比正常与异常设备的握手日志，发现失败设备全部不支持 SNI 或 TLS1.2 以下协议，而配置里 ssl_protocols 只留了 1.2 与 1.3。根因是前一天安全整改时协议白名单收得太紧，把占比不到 0.5% 但绝对量不小的老设备拦在了门外。修复是把分级策略写进预案：

主域名：TLSv1.2 TLSv1.3        ← 面向现代浏览器
老网关域名：加 TLSv1.1          ← 仅给存量设备，标注下线日期
安全整改的每一刀都要看兼容性数据，不能只看安全报告
​

这个案例的教训被写进了上线清单：任何 ssl_protocols 与 ssl_ciphers 改动，必须附带"受影响客户端占比"的估算，占比不为零就要灰度。证书问题多数不是技术难，是节奏与核对清单的问题——过期、断链、覆盖缺口三类故障占了 HTTPS 运维事故的九成。

还有一项容易被忽略的收尾工作：全量盘点站内外的明文链接。页面里写死的 http 资源引用在 HTTPS 页面里会被浏览器拦截或降级警告，第三方回调地址要逐家通知更新，监控探活与定时任务里的 URL 也要过一遍。经验上这个盘点清单比 TLS 配置本身更长，且只能靠全站检索加人工确认逐步收敛。灰度期里观察浏览器控制台的混合内容告警，是发现漏网站内引用的最有效手段。

本节要点回顾

• 证书要全链拼接，中间证书缺失是最常见的兼容性故障；
• 先共存再跳转，保留 ACME 目录给证书续期留通道；
• 会话缓存与 HTTP2 两个开关解决九成性能疑虑；
• HSTS 谨慎启用，小 max-age 试运行后再放大。