01 · 中间CA的功能定位与风险结构
1.1 为什么需要中间CA
中间CA的存在有充分的技术与运营理由：①根密钥保护——根离线保存，日常签发全部由在线中间CA承担，根私钥暴露面最小化；②业务分域——大型CA按品牌、地域、产品线拆分中间证书，单点失守可精准吊销；③算法过渡——新算法（如ECDSA、未来的PQC）通过新中间证书引入，无需触碰根；④技术受限子CA——为托管、企业代管等场景签发带名称约束的受限证书。换言之，中间CA是信任链的"分布式执行层"，其存在本身是架构设计的必然。
1.2 风险结构：委托等于信任复制
中间CA证书在密码学能力上与根CA等价（可签发任意域名的可信证书），区别仅在"委托记录"：谁批准签发、受什么约束、向谁披露。风险正来自委托记录与密码学能力的脱节——一张未申报、无约束的中间CA证书就是一枚"休眠核弹"：可能沉睡多年，一旦启用即为任意钓鱼站点签发浏览器全绿的证书。CCADB披露的已申报中间CA证书数量级为数千张，而学术研究通过全网TLS全链收集持续发现未申报中间证书——申报率虽随CT强制与BR执法显著提高，历史存量与跨国CA的属地披露差异仍是盲区。
| 风险维度 | 说明 | 典型后果场景 |
|---|---|---|
| 委托失控 | 中间证书被用于声明之外的用途（为第三方域名签发） | 钓鱼/监控基础设施获得批量可信身份 |
| 运营失守 | 签发系统、RA流程或域名验证被绕过 | 欺诈证书批量签发（Comodo 2011式） |
| 可见性缺失 | 未申报中间证书游离于CCADB与CT之外 | 事件发生时才被被动发现 |
| 约束缺位 | 无名称约束，失控即全域风险 | DigiNotar式全网中间人攻击 |
02 · 委托管控机制全景
中间CA管控是"治理手段为主、技术手段为辅"的组合体系。下表对照两类手段的机制、依据与局限：
| 类别 | 机制 | 机制说明与依据 | 局限 |
|---|---|---|---|
| 治理手段 | 强制披露（CCADB） | BR要求CA将其全部下属CA证书（含交叉证书）申报至CCADB；未披露即违规，可被根程序处罚 | 历史存量清理不彻底；跨国CA属地披露口径不一 |
| 审计覆盖 | WebTrust/ETSI审计与BR合规检查覆盖中间CA签发流程 | 年度抽样性质；对"沉睡证书"的实体检查有限 | |
| CT可见性 | 中间CA证书出现在站点证书链中即被CT日志记录——Chrome CT政策使未披露中间证书在实战中快速暴露 | 仅覆盖"被实际使用"的证书；休眠证书仍不可见 | |
| 退出机制 | 根程序可吊销CA资格（DigiNotar破产、Symantec退场为极端案例） | 事后性；对国家级/大型CA动用门槛高 | |
| 技术手段 | 名称约束 | 上级CA对下级实施dNSName空间锁定（RFC 5280 §4.2.1.10） | 公网部署率极低（见第04节） |
| 路径长度约束 | 限制下级层级数 | 不限制签发范围 | |
| EKU收缩 | 中间证书携带EKU限定下游用途 | 浏览器对中间证书EKU的执行一致性曾存差异 |
机制演进的因果链：BR强制披露（2015年后强化）＋CT强制（2018年）→ 未申报中间证书的实战存活窗口大幅缩短 → 管控重心从"发现"转向"预防与约束"。这正是"治理手段在公网替代技术手段"的现实路径——不是因为技术手段无效，而是因为技术手段的部署成本与兼容风险在多方生态中难以协调。
03 · 中间CA失控标志性事件
2011—2016年是中间CA失控事件的密集爆发期，六起标志性事件共同勾勒出委托管控的失败模式：
| 时间 | 事件 | 根因 | 治理后果 |
|---|---|---|---|
| 2011.3 | Comodo欺诈证书 | 经销商（RA）账户被盗用，绕过CA主流程签发9张google.com/yahoo.com等欺诈证书 | 证书数小时内吊销；暴露RA链条管控缺口，浏览器开始审视RA授权模式 |
| 2012.12 | Turktrust误发 | 误将本应限制用途的证书签发为具备CA能力的中间证书（2张），其中一张*.google.com证书在公开网络被观测到用于流量拦截 | 证书吊销；引发对"中间证书误签"流程控制的全球排查 |
| 2013.12 | 法国ANSSI事件 | 政府网络监控体系中的中间CA为*.google.com签发证书（监控用途流出至外部网络） | Google通知后吊销；引发"国家监控型CA"信任的长期讨论 |
| 2014.7 | 印度NIC事件 | 国家信息中心（NIC）CA签发google.com/yahoo.com/skype.com等域名证书 | Google宣布不再接受NIC签发的Google域名证书；Chrome对NIC实施Google域名白名单限制，Mozilla跟进处理 |
| 2015.3 | CNNIC中间证书事件 | CNNIC委托的中间证书被埃及MCS公司用于为Google域名签发未经授权证书 | Google/Mozilla不再信任相关中间证书；经整改协商，CNNIC其后改用带名称约束的技术受限中间证书——公网名称约束罕见的规模化实践（详见下文） |
| 2016 | WoSign系列违规 | 未授权为github.com等域名签发证书、SHA-1证书倒签规避政策、隐瞒收购StartCom等 | Mozilla启动不信任程序，Apple/Google分阶段移除——根程序退出机制再次执行 |
失败模式归纳：六起事件可归并为三类根因——①委托链条管控缺失（Comodo的RA、CNNIC的中间证书）：权限下放而无持续监督；②内部流程错误（Turktrust误发、NIC签发）：把"签发能力"当作普通操作处理；③治理违规（WoSign）：有意规避规则。三类根因对应的防线不同：①靠披露+审计+CT，②靠签发系统强校验（如证书模板的EKU/BasicConstraints白名单），③靠退出机制威慑。
04 · 名称约束的工程局限
名称约束被普遍视为约束中间CA的"正确技术手段"，但其在公网Web PKI的部署率接近于零。局限主要来自四个层面：
- 历史兼容风险：将名称约束标记为critical后，解析失败的旧客户端会直接拒绝整条链——CA不愿为部分陈旧环境承担可用性风险；标记为non-critical又可能被部分实现忽略，约束形同虚设。
- 通配符与匹配歧义：*.example.com与约束子树example.com的交互遵循RFC 6125规则，跨实现一致性差；国际化域名（IDNA A-label/U-label）的等价匹配进一步放大歧义。
- 治理与商业结构：名称约束意味着上级对下级的硬控制，而Web PKI的中间证书大量存在于"同一集团内部"或"交叉签名伙伴"关系中，缺乏强约束的动机方。
- 责任错配：约束由签发中间证书的上级设置，而出险成本由浏览器/用户承担——设置约束的成本与收益在不同主体间错配。
4.1 罕见的规模化例外：CNNIC整改案
2015年CNNIC中间证书事件后，Mozilla在与CNNIC的协商中要求：CNNIC恢复业务须改用技术受限中间证书（名称约束+EKU）——这是公网Web PKI史上罕见的、由浏览器根程序强制推动的名称约束规模化部署。该案例证明三点：①名称约束在工程上完全可行；②其落地需要根程序级别的强制力（市场支配地位作为杠杆），单靠CA自觉无法实现；③"约束+白名单监督"的组合，可作为国家级/大型CA委托管控的参考模板。其可复制性受限于地缘与商业现实，但机制本身已被验证。
4.2 未来的可能突破
近年行业讨论的新方向包括：①浏览器强制支持声明——Chrome Root Program要求新纳入根的使用场景逐步披露下属证书，为约束机制创造需求；②短寿命中间证书——与短寿命终端证书改革（SC-081v3）联动，缩短失控窗口；③企业侧先行——内部PKI（如Kubernetes服务网格、mTLS体系）已普遍使用名称约束，企业场景的工程积累可能反向推动公网采用。
4.3 未申报中间证书的量化证据（学术测量）
学术界基于全网TLS全链收集的多次测量给出量化证据：CT强制与BR披露执法之前，全网存在相当数量的未申报中间CA证书，其中相当比例为历史遗留的"沉睡证书"——长期未被使用、游离于CCADB之外，只在被意外启用时才暴露；强制披露与CT合规之后，增量问题显著收敛，但存量清理、并购带入与新兴市场申报缺口仍持续存在。对CA运营方的启示：申报完整性不是一次性工程，而是持续义务——并购整合、系统迁移与区域业务调整都会在不经意间制造新的披露缺口，需将"CCADB申报核对"纳入每次组织变更的检查单。
05 · 未申报中间CA的发现方法
即使治理完备度持续提升，"发现未申报中间证书"仍是防御方与监管方的刚需能力。可行方法组合：
- 全网TLS全链收集：对全网443端口发起TLS握手并收集服务端返回的完整证书链，提取链中的CA证书——这是学术界测量未申报中间证书的标准方法（多篇USENIX/IMC测量论文采用）。
- 与CCADB比对：将收集到的CA证书指纹与CCADB公开数据比对，不在库中即为"未申报"候选；进一步区分"历史遗留"与"新签发"。
- CT日志反查：站点证书的SCT与链式结构可在CT日志中回溯其签发CA；Chrome的CT政策使未申报中间证书在实战使用中被快速记录。
- AIA线索扩展：部分中间证书AIA扩展指向未公开的CA证书，可沿链递归发现。
组织侧简化版：一般企业无需全网测量——对自有域名，用CT日志服务（如crt.sh）检索所有证书并检查其链上级是否在CCADB；对自有终端，用MDM/EDR导出信任库比对厂商基线。这两步即可覆盖绝大多数本地风险面（详细操作见第7页防御基线）。
06 · 运营方自查基线与参考来源
6.1 中间CA运营方自查清单（签发CA视角）
| # | 自查项 | 依据/工具 |
|---|---|---|
| 1 | 全部下属CA证书（含交叉证书）是否已按时限申报CCADB | BR披露条款；CCADB申报接口 |
| 2 | 是否存在BasicConstraints.cA=true但已停用未吊销的"沉睡证书" | 内部证书台账 + CRL状态核查 |
| 3 | 对外委托的中间证书是否带名称约束/EKU收缩（非强制项，建议评估） | RFC 5280 §4.2.1.10 |
| 4 | 证书模板是否强制校验EKU与BasicConstraints（防Turktrust式误发） | CA软件模板配置审计 |
| 5 | RA/经销商权限是否最小化并定期复核（防Comodo式账户盗用） | BR第1.6节治理要求 |
| 6 | 中间证书密钥是否存于HSM并启用双人授权激活 | WebTrust密钥管理原则；第5页 |
6.2 参考来源
CA/B Forum Baseline Requirements（下属CA证书披露与技术约束相关条款）：cabforum.org。
Mozilla安全博客《Revoking Trust in one CNNIC Intermediate Certificate》（2015年4月）及后续政策执行记录：blog.mozilla.org/security。
Google Security Blog关于CNNIC中间证书事件的公告（2015年3月）与NIC India限制措施（2014年7月）：security.googleblog.com。
CCADB（Common CA Database）：ccadb.org。
IETF RFC 5280 §4.2.1.10 Name Constraints：rfc-editor.org/rfc/rfc5280#section-4.2.1.10。
Turktrust、ANSSI、WoSign等事件的公开记录（各组织事后声明与主流安全媒体报道汇编）：en.wikipedia.org/wiki/Certificate_authority（含事件索引）。