吊销机制总览
吊销机制用于让证书在到期前失效。吊销列表由 CA 定期发布，列出被吊销证书的序列号；在线状态查询针对单张证书返回实时状态，返回值为有效、已吊销或未知三类。现代实践普遍配合短有效期、状态装订与浏览器自有名单来降低吊销检查的可用性风险，因为客户端侧检查失败时往往采用放行策略。
基本信息
| 吊销列表 | 定期发布全量名单，体积随时间增长 |
|---|---|
| 在线查询 | 按证书查询状态，实时但引入可用性与隐私问题 |
| 状态装订 | 服务端缓存查询响应并随握手下发 |
| 趋势 | 部分 CA 转向列表与短有效期（以官方公告为准） |
典型使用场景
- 证书泄露后的应急处置：确认吊销是否已生效
- 排错：客户端仍信任已吊销证书时核对检查机制
- 内网 PKI：用吊销列表做本地闭环检查
- 合规审计：确认吊销流程可执行
- 评估：判断是否需要部署状态装订
手工查询吊销状态
手工查询吊销状态
openssl ocsp -issuer ca.pem -cert cert.pem -url http://ocsp.example.com -resp_text | head -20
openssl crl -in ca.crl -noout -nextupdate # 确认列表仍在有效窗口
openssl verify -crl_check -CRLfile ca.crl -CAfile ca.pem leaf.pem # 链上检查吊销机制对照
| 机制 | 特点 | 主要问题 |
|---|---|---|
| 吊销列表 | 全量、可离线校验 | 体积增长，时效滞后 |
| 在线查询 | 单证书、实时 | 可用性与隐私问题 |
| 状态装订 | 随握手提供 | 依赖服务端定期刷新 |
| 短有效期 | 把过期变成主要手段 | 续期频率升高 |
客户端侧的吊销检查可能被软失败跳过（超时即放行），因此不能把它当成唯一防线，短有效期与密钥保护同样重要。
落地建议
- 吊销流程要有可执行的脚本与操作记录
- 内网 PKI 明确吊销列表的分发与更新周期
- 对状态装订服务做可用性监控
- 把吊销与续期流程合并到同一套工单体系
认为吊销后立即全网失效是常见误解：客户端缓存、软失败与检查机制差异会导致延迟甚至完全跳过，凭证泄露后的正确应对是吊销并更换密钥。