must-staple 是什么
must-staple 指证书里带 TLS Feature 扩展并声明 status_request，签发时可理解为对客户端的承诺：本证书的吊销状态必须通过 OCSP 装订（stapling）方式提供。支持该扩展的客户端（Firefox、Chrome 等）遇到声明了 must-staple 的证书时，若服务端没有装订响应，会直接拒绝连接而不是回退去自行查询 OCSP。好处是吊销信息跟着握手一起送达，不依赖客户端出网；代价是一旦装订链路失效，站点直接不可用。
基本信息
| 规范 | RFC 7633（TLS Feature 扩展），值 status_request(5) |
|---|---|
| 客户端行为 | 声明了 must-staple 的证书必须收到装订响应，否则握手失败 |
| 支持情况 | Firefox 全量支持，Chrome 在部分平台支持，需按版本核对 |
| 风险 | 装订未就绪或 OCSP 不可用时服务直接不可用 |
| 检查 | 看证书扩展与 s_client 的 OCSP 响应状态 |
| 替代方案 | 普通装订 + 短有效期证书，容错性更好 |
典型使用场景
- 吊销时效要求高的业务：希望客户端每次都拿到新鲜的吊销状态。
- 客户端不出网的环境：避免每台终端自行查询 OCSP 造成的延迟与失败。
- 合规声明：按内部策略要求吊销信息随握手下发。
- 装订链路演练：验证 DNS、出网、时间同步三者齐备后才敢正式启用。
- 故障复盘：站点中断时确认是否因 must-staple 与装订失效叠加导致。
检查与测试装订
检查与测试装订
# 确认证书声明了 must-staple（TLS Feature 里含 status_request）
openssl x509 -in cert.pem -noout -text | grep -A1 'TLS Feature'
# 看服务端是否真的装订了 OCSP 响应
openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>&1 | grep -A3 'OCSP Response'
# 服务端侧还需确认能定期更新装订响应：观察 nginx 的 ssl_stapling 相关日志状态组合与结果
| 证书扩展 | 服务端装订 | 客户端结果 |
|---|---|---|
| 含 must-staple | 有有效装订响应 | 握手正常，吊销信息随握手下发 |
| 含 must-staple | 无装订响应 | 支持该扩展的客户端直接拒绝连接 |
| 普通证书 | 有装订 | 装订生效，但不强制 |
| 普通证书 | 无装订 | 客户端可能自行查询 OCSP 或按软失败处理 |
启用前先把整条装订链路验证通过：服务端能解析 OCSP 地址、能出网、系统时间准确、装订缓存能按期刷新。四项里任一缺失都会让站点在证书有效期内直接不可用。
证书已签发后再想加 must-staple 必须重新签发，扩展无法事后补写，规划时就要决定。