01 · 组织信任面盘点
防御的前提是可见。组织侧的信任面由四类资产构成，盘点方法各异：
| 资产类别 | 风险 | 盘点方法 |
|---|---|---|
| 对外服务证书与私钥 | 私钥泄露、过期断服、影子证书（CT中出现在他人申报下的本品牌证书） | CT日志反查（crt.sh等）+ 网络扫描 + 配置审计三源合一 |
| 自有/上级签发的中间CA | 未申报、失控、沉睡证书被启用 | 台账核查 + CCADB比对 + 模板签发记录审计 |
| 客户端信任库基线 | 未授权本地根（恶意软件、违规预装、越权代理） | MDM/EDR导出信任库与厂商基线比对 |
| 上游CA依赖 | 所购CA的合规水位与退市风险传导 | 跟踪根程序处置记录与CA事件报告（年审报告、CCADB记录） |
最优先动作：对自有品牌域名执行一次完整的CT日志反查——历史上多次发生"员工/承包商用个人账号为组织域名申请证书"形成的影子证书，以及"伪造本品牌的钓鱼证书"（子课题02的监测对象）。CT反查一次即可同时覆盖两类风险，是性价比最高的信任面盘点动作。
02 · 防护基线清单
以下八项控制项构成组织侧信任链防护的最低基线，依据均为现行标准或根程序要求：
| # | 控制项 | 标准依据 | 实施要点 | 常见缺陷 |
|---|---|---|---|---|
| 1 | CAA部署 | RFC 6844/8657；BR强制CA检查 | 发布issue/iot授权声明，用accounturi与validationmethods参数锁定授权账户与验证方式 | 仅配置顶层域名，遗漏通配与多级子域；DNS迁移时记录丢失 |
| 2 | CT监控 | RFC 6962/9162；Chrome/Apple强制 | 订阅CT日志流或使用监测服务，覆盖自有域名全量证书+品牌仿冒模式 | 只监测主品牌，漏掉常见拼写变体与新兴TLD |
| 3 | 私钥保护 | WebTrust密钥管理原则 | 服务器私钥进HSM/KMS；禁止私钥经邮件/即时通讯传输；生成-使用-销毁全程留痕 | 开发环境私钥与生产混用；证书随镜像分发 |
| 4 | 域名验证通道加固 | BR；MPIC要求 | 固定ACME账户与验证方式（CAA参数）；DNS API凭据最小权限+轮换 | DNS服务商全权API凭据长期不轮换 |
| 5 | 吊销通道验证 | RFC 6960/5280 | 每季度实测一次CA应急吊销流程（含OCSP/CRL生效验证），记录SLA | 证书签多年却从未测试过吊销 |
| 6 | 证书自动化治理 | RFC 8555 | 续签成功率与剩余有效期纳入监控；自动化失败熔断预案 | 告警阈值过短，人工介入时间不足 |
| 7 | 中间CA约束 | RFC 5280；BR披露要求 | 对外委托的中间证书评估名称约束/EKU收缩；全部申报CCADB | 历史中间证书从未复核 |
| 8 | 信任库基线审计 | 平台安全基线实践 | 终端信任库变更告警；企业代理根限定受管范围+审计日志 | 代理根默认全设备推送且无日志 |
03 · 证书固定策略的取舍
证书固定（pinning）曾被视为防御流氓证书的利器，但实战教训深刻：
| 方案 | 机制 | 结局/现状 |
|---|---|---|
| HPKP（RFC 7469） | HTTP头钉扎站点证书公钥，违背即拒绝连接 | 误配可致站点自我拒绝服务，部署率始终低迷；Chrome于2019年初（Chrome 72）移除支持，事实退场 |
| 浏览器内置钉扎 | 浏览器硬编码高价值域名指纹 | 发现过DigiNotar等事件；维护成本高，Chrome已转向以CT替代钉扎 |
| DANE/TLSA（RFC 6698/7671/7672） | DNSSEC保护下的证书/公钥指纹声明 | 依赖DNSSEC普及度，Web场景部署有限，邮件（DANE for SMTP）落地较好 |
| 移动应用 pinning | App内置服务端证书/公钥指纹 | 仍在广泛使用，但必须配置备份针（backup pin）以防证书更换自锁 |
| CT监测（事实替代品） | 不阻止连接，但签发即告警 | 成为公网证书滥用的主流防御：把"阻止"换成"分钟级发现+处置"，代价远小于钉扎 |
取舍结论：HPKP的失败说明"让千万站点各自承担钉扎运维"的模型不成立——可用性风险抵消了安全收益。现代组合的答案是：CAA（签发侧授权）+ CT监测（使用侧发现）+ 短寿命（窗口压缩）三者叠加，覆盖固定方案想覆盖的风险而避免其可用性陷阱。移动App等客户端可控场景保留pinning时，务必备份针并演练轮换。
04 · 检测能力建设
4.1 CT监测流水线
对多数组织，CT监测是唯一可获得的"全网证书视野"。标准流水线：CT日志流订阅（或第三方监测服务）→ 证书解析（CN/SAN/签发CA/时间戳）→ 匹配引擎（自有域名全量 + 品牌仿冒模式：编辑距离、同形字符、组合仿冒、高风险TLD加权）→ 风险分级 → 告警与处置联动。分级建议：高（高相似度+金融/支付品牌+已解析活跃）——分钟级告警并启动处置；中（模式命中但未活跃）——日报跟踪；低（长尾匹配）——周度汇总复核。
4.2 本地信任锚检测
- 终端侧：EDR/MDM导出各平台信任库，与基线比对新增项；对本地根的出现执行"授权核查流程"（谁装的、为什么、有无审计）；
- 网络侧：对关键业务流量抽检TLS服务端证书链——若链中出现组织从未采购过的CA（典型于代理拦截或恶意中间人），即触发调查；
- 国密双体系场景：同时维护国际/国密两套信任链的监测——国密证书透明度实践尚处早期，国密链的伪造证书发现更依赖网关侧抽检与CA侧对账（与子课题05联动）。
检测能力建设的排序建议：先CT监测（覆盖公网仿冒，见效快）→ 再信任库审计（覆盖本地植入）→ 最后网络抽检（覆盖中间人与代理滥用）。三者数据汇入同一告警平台，形成"证书情报"单一事实源。
4.3 公开工具与数据源清单
| 工具/数据源 | 定位 | 使用要点 |
|---|---|---|
| crt.sh | CT日志公开查询服务（Sectigo运营） | 免费检索任意域名的历史与在册证书，含证书链与SCT详情 |
| Censys | 全网主机与证书搜索引擎 | 按证书指纹/域名/组织属性检索，支持主机侧关联分析 |
| SSLmate Cert Spotter | CT监测订阅服务 | 对自有域名与品牌变体的证书签发实时告警（有免费档） |
| CCADB公开数据 | 根与中间证书权威申报库 | 可导出比对，配合CT数据发现未申报中间证书 |
| certificate.transparency.dev | Google维护的CT生态文档与合规日志清单 | 查询合规CT日志列表与日志运行状态 |
05 · 应急演练剧本
基于第6页事件档案归纳的通用处置剧本（发现"本品牌伪造证书"场景）：
演练要点：①真实演练一次"CA应急吊销"——多数组织从未走过该流程，首次实战必然是演练；②把"签发CA是谁"做成预置知识——伪造证书签发CA不同（免费DV CA为主），其应急通道与时延差异巨大；③演练记录即审计证据，纳入合规留痕（第8页合规映射）。
06 · 本节参考来源（第7页）
RFC 6844（CAA，2013）与RFC 8657（CAA属性标签扩展，2019）：rfc-editor.org/rfc/rfc6844；rfc-editor.org/rfc/rfc8657。
RFC 7469（HTTP Public Key Pinning，2015）及Chrome移除HPKP的公开说明（Chrome 72，2019年初）：rfc-editor.org/rfc/rfc7469。
RFC 6698（DANE/TLSA）、RFC 7671与RFC 7672：rfc-editor.org/rfc/rfc6698。
RFC 6962（CT）与RFC 9162（CT v2）；crt.sh公共查询服务：crt.sh。
CNNIC域名投诉举报处理平台（公开服务入口）：tsi.cnnic.cn/cnnic。
Google Safe Browsing：safebrowsing.google.com；Microsoft SmartScreen：微软官方文档。