01 · 现状盘点：六问自查
组织在选型与整改前，必须先把“事实底账”摸清。以下六问对应六个可核查的技术事实，任何一问答不上来都意味着治理盲区：
| 编号 | 自查问题 | 核查方法 | 达标基线 |
|---|---|---|---|
| Q1 | 本组织全部证书清单（含影子证书）是否完整？ | CT反查（crt.sh/Censys按域名检索）+ 网络扫描 + 配置审计三方对账 | CT可见证书台账覆盖率100%，差异项有归属结论 |
| Q2 | 每张证书挂在哪个CA、用哪个自动化通道续签？ | 台账字段核查；确认ACME账户/订单归属 | 无“无人认领”证书；续签触发可追溯到流水线 |
| Q3 | 证书中内嵌的吊销端点（AIA/CRLDP/OCSP）现状如何？ | openssl x509 -text 解析AIA/CRLDP；核查CA是否仍运营对应端点 | 端点可达且更新及时；对LE等已停OCSP的CA无依赖假设 |
| Q4 | Stapling是否在生效、节点级覆盖率多少？ | 外部探针周期执行 openssl s_client -status；多前端逐节点探测 | staple存在且剩余有效期大于刷新缓冲（建议≥12小时） |
| Q5 | 私钥存放在哪里、谁有导出权限、是否出过网络边界？ | HSM/KMS/文件系统分级盘点；导出权限审计日志 | 私钥不出受控边界；导出操作有双人审批与日志 |
| Q6 | 证书到期与吊销应急的通知链路是否实测可用？ | 对照告警规则逐条演练（非工作时间触发测试） | 告警→责任人 Ack 时长有SLA（建议高危15分钟内） |
盘点原则：外部基准优先于内部台账。CT反查（子课题02的方法）能看到组织自己都忘记的证书——历史上多起“过期证书断服”事故的主角都是台账外的影子证书。盘点结论应形成《证书资产台账》并进入第8页的成熟度评级。
02 · 验证与吊销机制选型决策树
2.1 决策框架
2.2 选型对照表
| 场景 | 推荐组合 | 不推荐/需规避 |
|---|---|---|
| 普通公网站点 | ACME自动化 + CT监测 + Stapling保留 | Must-Staple（CDN边缘不可控时断服风险高） |
| 高保证API入口 | 短周期预签双证书热备 + 自动化秒级切换；客户端可控时评估Must-Staple | 依赖“吊销后用户侧自动安全”的任何假设 |
| 内部微服务mTLS | 短寿命证书（天级）+ 网格自动轮换；吊销仅作兜底 | 长寿命+人工吊销流程 |
| 内网AD域 | 组策略硬失败+CDP冗余；CRL发布点纳入监控 | CDP单点（域控宕机导致全网验证失败） |
选型铁律：吊销机制的选择不改变一个底层事实——2025年后的公网Web场景中，“用户被吊销保护”的覆盖率由浏览器生态（CRLite/CRLSets）决定，不由组织选择决定。组织能决定的是三件事：误签后的暴露窗口（寿命与监测）、更换速度（自动化）、私钥不泄露（密钥管理）。把预算投在这三件事上，回报远高于任何吊销协议层面的调优。
03 · 应急SOP：私钥泄露与证书误签
3.1 时限坐标（BR §4.9.1）
- 24小时：确认密钥泄露（keyCompromise/cACompromise/aACompromise）后，CA须在24小时内完成吊销——组织侧倒排：从确认泄露到向CA提交吊销请求，安全余量建议压缩到8小时以内；
- 5天：其余吊销原因（误用、信息不准、业务下线等）；
- 7天：中间CA证书的吊销时限——信任链级事件，另行启动专项预案。
3.2 四阶段动作清单
| 阶段 | 目标 | 关键动作 | 责任方 |
|---|---|---|---|
| T+0～2h 遏制 | 阻断继续利用 | 隔离涉密系统；若私钥托管于HSM/KMS，吊销对应密钥的使用授权；冻结相关CI/CD发布通道；初步评估泄露范围（哪些证书/域名/服务） | 安全运营+运维 |
| T+2～8h 定位 | 全量确定受影响面 | CT反查受影响域名全部证书（含历史）；核对ACME账户订单；确认私钥对应的证书清单与部署位置；确认是否存在第二泄露点 | PKI负责人 |
| T+8～24h 处置 | 吊销+替换并行 | 向CA提交吊销（keyCompromise原因码）；新证书预签+灰度切换上线（新私钥全新生成于受控环境）；按浏览器行为最差假设启动用户侧通知评估 | PKI负责人+业务方 |
| T+24h～7d 收尾 | 验证闭环 | 验证CRL/CRLite中已可查（Firefox验证最直观）；确认无残留部署点；复盘报告（泄露根因、时间线、自动化缺口）；更新SOP与演练脚本 | 安全运营 |
3.3 事件收尾的“四件套”标准
不以“CA已吊销”作为收尾标准。合格的收尾须同时满足：①私钥/域名控制权已收回；②CA吊销已完成（CRL/CRLite可查）；③域名与内容层处置已联动（防钓鱼复用，对接CNNIC域名投诉举报处理平台等通道）；④受影响用户通知与客户端侧风险沟通已完成。任何一件缺失，事件即为“处置中”。
04 · 可观测性指标体系
吊销与验证层的可观测性应纳入PKI运营统一指标面板（与子课题06的证书生命周期指标合并呈现）：
| 指标 | 定义 | 告警阈值建议 |
|---|---|---|
| Stapling有效率 | 外部探针采样中随握手返回有效staple的比例（按前端节点分维度） | 任一节点的有效率<95% |
| OCSP端点可达性 | 本组织证书AIA所列端点的周期探测成功率 | 连续3次探测失败（注：该指标随CA停OCSP而逐渐退役） |
| CRL更新及时性 | 本组织证书CRLDP所列CRL的thisUpdate新鲜度 | 超过CA承诺更新周期的1.5倍 |
| 吊销条目可见性 | 应急吊销后，CRLite/CRL中可查的时延（以Firefox实测为准） | 超过24小时需升级CA工单 |
| 续签成功率/自动覆盖率 | ACME续签成功比例；自动续签覆盖的证书占比 | 成功率<99.5%或覆盖率<95%（2026年前须达100%） |
| 影子证书增量 | CT反查发现的无台账证书数 | 任何新增均触发归属核查（高危即时） |
| 到期风险分布 | 剩余有效期<30天/14天/7天的证书计数 | <7天证书非零即高危（2026年后阈值随寿命压缩下调） |
05 · 演练设计：半年吊销演习 + 年度过期演习
- 吊销演习（每半年）：选取一张非生产证书执行完整SOP——真实吊销、真实替换、真实验证CRL/CRLite可见性。演习度量四个时间戳：发现→提交吊销、提交→CA吊销完成、吊销→CRL可见、吊销→CRLite可见（Firefox实测）。目标：全流程<24小时且各环节有明确责任人与工单记录。
- 过期演习（每年）：模拟“续签流水线全灭”（如ACME账户密钥失效、DNS API凭据过期）场景，验证熔断预案：人工应急通道签发、备用CA切换、降级运行策略。度量RTO（恢复时间目标）。
- Must-Staple压力测试（有条件时）：在预发环境对启用Must-Staple的证书执行“staple获取中断”故障注入，验证断服行为是否符合预期、恢复是否自动化。
- 演习纪律：每次演习输出《吊销时效实测报告》，与CA承诺值对账；连续两次演习不达标项必须进入整改计划并向管理层报告——演练的价值不在“通过”，而在暴露SOP与现实的差距。
本节参考来源（本页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
CA/B论坛 Baseline Requirements §4.9（吊销时限）、§6.2（私钥保护）：cabforum.org/working-groups/server/baseline-requirements；DigiCert对BR吊销时限的解读：digicert.com/blog/industry-timelines-for-certificate-revocation。
CISA：《DigiCert Certificate Revocations》（2024年7月30日，撤销通知期协调经验）：cisa.gov。
Let's Encrypt 2020 CAA事件报告（大规模吊销执行悖论的制度教训）：letsencrypt.org/2020/03/04/2020.02.29-caa-incident.html。
nginx ssl_stapling官方文档：nginx.org；openssl s_client -status 用法：docs.openssl.org。
Mozilla Hacks：CRLite博文（2025年8月19日，组织验证吊销可见性的实测方法参考）：hacks.mozilla.org。