paozhu 1.13.0 对 HTTP/1 与 HTTP/2 协议解析进行了较大范围的重构，同时补上两项直接影响 HTTPS 运维的能力：通过 ACME 协议自动续期、刷新 SSL 证书，以及在服务器端启用 OCSP Stapling。前者减少证书过期事故，后者让客户端可以在 TLS 握手阶段直接拿到证书状态，避免额外查询 OCSP 服务。
自动续期不只是“申请一张新证书”
ACME 自动化通常包含一条完整链路：创建或加载账户、发起订单、完成域名所有权验证、获取证书、持久化私钥与证书链，然后让服务加载新证书。paozhu 1.13.0 将证书自动续期和刷新纳入框架，目标是让这一过程无需人工干预，并为未来接入更多证书供应商留下空间。
真正部署时，需要重点确认以下边界：
- ACME 挑战使用 HTTP-01、DNS-01，还是其他方式。
- HTTP-01 所需的 80 端口能否从公网访问，反向代理是否放行挑战路径。
- 证书和私钥写入目录是否持久化，容器重建后是否仍然存在。
- 多实例是否会同时续期，进而触发 CA 速率限制或覆盖同一份文件。
- 新证书写入后，框架是热加载 TLS 上下文，还是需要平滑重启。
- ACME 账户密钥和域名私钥是否具有最小文件权限，并被排除在镜像和代码仓库之外。
在容器或 Kubernetes 环境中，证书不能只放在容器可写层。可以把它挂载到持久卷，并且只允许负责续期的实例写入；其他实例通过共享存储、Secret 同步或发布流程读取证书。
OCSP Stapling 改变了证书状态查询路径
传统 OCSP 查询由浏览器向证书颁发机构的 OCSP 服务发起。这个额外请求会受到网络延迟、DNS、CA 服务可用性和客户端策略影响。启用服务器端 OCSP Stapling 后，服务器预先获取并缓存由 CA 签名的 OCSP 响应，再在 TLS 握手中将它发送给客户端。
这项能力可以减少客户端独立查询 OCSP 服务的需要，从而改善部分 HTTPS 连接的建立时间。但它不是一个“打开即永久有效”的开关：装订响应带有有效期，服务器必须定期刷新。如果响应已经过期、证书链不完整或 CA 没有提供可用的 OCSP 地址，客户端仍可能忽略装订结果或退回其他校验策略。
部署时应监控三类时间：证书的 notAfter、OCSP 响应的 thisUpdate，以及 nextUpdate。只监控证书到期日，仍可能漏掉 OCSP 响应长期未刷新的问题。
可以这样验证线上证书和 OCSP 状态
下面的脚本不依赖 paozhu 的内部配置格式，可用于验收任何已经启用 HTTPS 的 paozhu 服务。运行前把 example.com 改成实际域名；如果服务不在 443 端口，同时修改 PORT。
#!/usr/bin/env bash
set -euo pipefail
HOST="${1:-example.com}"
PORT="${2:-443}"
OUTPUT="$(mktemp)"
trap 'rm -f "$OUTPUT"' EXIT
openssl s_client \
-connect "${HOST}:${PORT}" \
-servername "${HOST}" \
-status </dev/null >"$OUTPUT" 2>&1
echo "== Certificate =="
openssl x509 -noout -subject -issuer -serial -dates <"$OUTPUT"
echo
echo "== OCSP Stapling =="
if grep -q "OCSP Response Status: successful" "$OUTPUT"; then
grep -E "OCSP Response Status:|Cert Status:|This Update:|Next Update:" "$OUTPUT"
else
echo "No successful stapled OCSP response was received" >&2
exit 1
fi
保存为 check-tls.sh 后可以直接运行：
chmod +x check-tls.sh
./check-tls.sh api.example.com 443
还可以用 curl 分别检查 HTTP/1.1 和 HTTP/2，确认协议解析重构后，两条访问路径都能完成 TLS 握手并返回预期响应：
curl --http1.1 --fail --silent --show-error \
--output /dev/null --write-out 'HTTP/1.1: %{http_code} %{time_appconnect}s\n' \
https://api.example.com/health
curl --http2 --fail --silent --show-error \
--output /dev/null --write-out 'HTTP/2: %{http_code} %{time_appconnect}s\n' \
https://api.example.com/health
其中 time_appconnect 包含建立 SSL/TLS 连接所花费的时间。单次结果不能证明 OCSP Stapling 带来的性能变化，应从不同网络位置多次采样，并结合服务端握手指标分析。
上线前把自动化的失败路径补齐
升级到 1.13.0 时，不要只确认“今天能签发”。更重要的是模拟后续续期和异常恢复：先在 ACME 测试环境完成演练，避免频繁请求生产 CA；验证挑战失败时旧证书不会被破坏；确认刷新 OCSP 响应失败时会告警；再检查 HTTP/1、HTTP/2、SNI、多域名证书和证书链是否符合现有流量入口的要求。
建议把以下项目放进发布检查表：
- 使用与生产相同的域名验证方式完成一次测试续期。
- 证书、私钥和 ACME 账户数据位于持久化且受限的目录。
- 续期任务具备单实例锁或明确的主节点机制。
- 证书剩余天数和 OCSP
nextUpdate均接入监控。 - 用
openssl s_client -status验证服务确实返回装订响应。 - 分别运行 HTTP/1.1 与 HTTP/2 的健康检查和回归测试。
- 保留上一份可用证书，并准备平滑回退流程。
paozhu 1.13.0 把证书生命周期与 OCSP 响应刷新推进到框架内部，能够减少 HTTPS 的日常运维工作。不过，自动化只是把人工步骤变成持续运行的系统：持久化、并发控制、监控和失败回退仍然需要在生产部署中明确设计。