证书管理机构（CA）发展史：从密钥密码学到全球信任治理（上）

导论：为什么 CA 史值得读

大多数人与"证书管理机构"（Certificate Authority，简称 CA）相遇的方式都很偶然：某天浏览器地址栏的锁形图标消失，某个站点打不开，或者自己的网站突然提示"证书不受信任"。这类遭遇塑造了公众对 CA 的印象——它是一个隐藏在界面背后、偶尔出来添乱的官僚机构。

但这个印象恰好错过了 CA 史上真正重要的事实：CA 是互联网信任经济的制度载体。我们今天默认"这是一个 google.com"这件事成立，靠的从来不是 DNS，也不是 TLS 协议本身，而是一条由少数几家企业签发的、逐级担保的信任链。这条链的信用来自三个地方：密码学上的不可伪造性、浏览器厂商的集体背书、以及跨国监管框架下的法律责任。任何一条断裂，信任就归零。

回顾这半个多世纪，会发现一个反复出现的规律：技术问题最终都会变成治理问题，治理问题最终都会变成事故，事故最终都会变成制度。

• 1991 年 Phil Zimmermann 把公钥密码从政府机房里带到个人电脑，挑战密钥托管政策——这让公钥密码从国家机密变成了公民工具。
• 1994 年 Netscape 把 SSL 塞进浏览器，"浏览器里内置一份根证书列表"这个决定，奠定了此后三十年 CA 产业的权力结构。
• 2011 年 DigiNotar 被攻破，一家荷兰公司为 Google 签发了伪造证书，荷兰政府紧急从信任库中移除其根证书——这是欧盟境内首个被吊销的信任根，也是"根证书是主权级资产"这一认知的起点。
• 2015 至 2018 年 Symantec 系证书从各浏览器信任库中被系统性清除，涉及规模在当年占全网有效证书的三成左右；这被广泛视为史上规模最大的一次信任撤退。
• 2020 年 Let's Encrypt 因一个 CAA 复检逻辑缺陷，一度面临吊销约 170 万张证书的处置——自动化把一个单点缺陷放大到了产业级事故。

因此，写 CA 史并不是写一部"证书怎么签发"的操作手册，而是一部关于信任如何被生产、验证、破坏与修复的制度史。它同时是密码学史、互联网史、企业治理史和监管史的交汇点。

本文的写法上，有三条自我约束：其一，区分"法律监管"与"行业自律"两条线——美国的 CA 基本不受专门法律许可约束，靠的是根证书计划的"市场准入"；欧盟以 eIDAS 建立法定的合格信任服务提供者体系；中国以《电子签名法》与工信部许可为核心；印度则用《信息技术法》第 17 条直接授权一个法定机构（CCA）发牌照。这四种模式常被混为一谈，但它们的制度逻辑完全不同。其二，区分数据口径——"某 CA 签发的证书在受扫描网站中占多少"与"某 CA 签发了多少张证书"是两个指标，可以相差一个数量级，本文在第七章会专门展开。其三，不确定就标注不确定——机构沿革中的年份分歧、市场的份额口径差异、历史事件的规模估算，都会明确写出其来源与局限。

第一章 密码学前史：从对称密码到公钥基础设施

1.1 古典密码与对称密码的困境

现代 CA 制度的全部技术前提，是"公钥密码"这一概念的成立。而在它之前，密码学已经走过了数千年。

古典密码的核心假设是密钥共享：发送方与接收方必须事先持有同一把钥匙，第三方无法从中还原明文。这套逻辑在军事、外交场景中运行良好，因为它假定通信双方在物理上已被认证为"自己人"，而窃听者无法接触到密钥分发环节。

对称密码的工程化则从这条路径上生长出来。1970 年代，美国国家标准与技术研究所（NIST）推动数据加密标准（DES），试图用硬件化的 56 位密钥为商业数据提供统一保护。DES 的核心设计思想——把密钥空间与算法结构解耦、把加密强度问题转化为密钥长度问题——成为此后所有对称算法设计的模板。

但 DES 遭遇了两个致命问题：

其一是密钥长度不足。 56 位密钥在当时的算力下已经可被穷举，DES 在学术界与商业界迅速转向 Triple DES（3DES）过渡，但 3DES 的性能代价与 168 位有效密钥长度都难以令人满意。

其二是密钥分发的根本困难。 对称密码无法解决"如何在开放网络上安全地把密钥交给对方"这一前提性问题。N 位用户两两通信需要 N(N-1)/2 把密钥，任何规模化的网络都无法承受这种组合爆炸。公钥密码正是针对这一难题而生。

表 1：对称密码与公钥密码的分工

说明：本表为教科书通行结论之归纳，非某一特定标准原文。

!配图 1｜密码学谱系时间轴：从古典密码到 PKI 信任结构

“

配图 1｜密码学谱系时间轴：从古典密码到 PKI 信任结构

>
密钥共享难题催生公钥密码，CA 制度是后者最成功的工程化应用

1.2 Diffie-Hellman 与 RSA：公钥密码的诞生（1976–1977）

1976 年，Whitfield Diffie 与 Martin Hellman 提出了"Diffie-Hellman 密钥交换"的原创论文，其核心洞察是：不要求解密问题本身可逆，而是构造一个数学上可计算、但逆向计算在当前算力下不可行的单向函数。双方各自保有私钥，公开交换公开信息，即可协商出共享密钥，而窃听者即便获得全部公开信息也无法推出共享密钥。这一思想通常被称为"陷阱单向函数"思想。

两年后的 1977 年，Ron Rivest、Adi Shamir 与 Leonard Adleman 发表了 RSA 算法，标题为《A Method for Obtaining Digital Signatures and Public-Key Cryptosystems》。RSA 建立在"大整数分解困难"这一假设之上：公开钥可以由两个大素数快速算出，从公开钥反推分解在计算上不可行。同样值得注意的是，RSA 论文提出者中，Shamir 与 Adleman 当时在斯坦福，Rivest 在 MIT——这是典型的学术合作产物，也直接引出了后面会提到的"Stanford 授权"商业史。

“

来源：[来源：Diffie & Hellman, New Directions in Cryptography, IEEE Transactions on Information Theory, 1976]；[来源：Rivest, Shamir & Adleman, Communications of the ACM, 1977, Vol. 21 No. 2]

RSA 的意义不止于加密。它天然提供了数字签名能力：用私钥对消息摘要做签名，任意持有方可用公开钥验证。这是 CA 制度成立的技术前提——没有人能预测 CA 私钥，但 CA 私钥的持有者可以对外做出不可否认的、可被第三方验证的担保。请注意这里的关键性质：CA 签名的不是"这个域名是真的"这一事实本身，而是"我（作为受信方）按照我公开的规则，为这个域名的控制权做过验证"这一承诺。理解这一点，才能理解后文 DigiNotar、Symantec、Entrust 等一系列事故的共同性质：**这些事故几乎都不是密码学被破解，而是"担保规则被绕过"**。

1.3 PGP 与公钥密码的社会化（1991）

1991 年，Phil Zimmermann 发布 PGP 1.0。这是公钥密码史上最具社会影响的一步，原因不在算法——PGP 用的仍是 RSA 与 IDEA——而在于它把密钥管理从国家机构手中下放给了个人。

此前，公钥密码的实践基本限于政府与大型企业：要使用它，你需要去申请一份由某个国家机构控制的证书，或者接受一个组织内部 PKI 管理员的分配。PGP 第一次让一个普通人在自己的机器上生成密钥对、把它印在海报上贴在_usenet_ 公告板上、向全世界公开，并自己为朋友签署指纹。

PGP 的关键设计是分散的信任模型：没有中央 CA，信任来自"我认识的人认识的人"的密钥签名网络（web of trust），签名数量构成对该密钥的信心程度。Zimmermann 这么做有明确的政治动因——当时美国政府正在推动"密钥托管"（key escrow）立法，要求加密私钥可被政府访问。PGP 的存在成为反对该立法的技术与论据：在端到端加密已经可用、且普通人可以自行部署的前提下，密钥托管无法通过"让用户很难获得密钥"来达成目标。

PGP 对 CA 制度的意义是双重的。

一方面，它确立了"公钥密码是一种公民技术而非国家特权"的社会共识，为十年后 Web PKI 的普及准备了土壤。PGP 时代培育了一整代理解非对称加密、证书链与签名验证的技术人群，他们后来构成了 Netscape 早期工程师与开源社区的重要来源。

另一方面，它也划出了一条 CA 制度此后始终面对的边界线：信任的最终锚点是什么？ PGP 的答案是"人与人之间的认识"，代价是没有任何机制能强制执行"必须验证"；CA 的答案是"由少数被信任的机构集中担保"，代价是信任被集中，也就出现了被集中滥用、伪造与撤销的风险。三十年后 Mozilla、Chrome、Apple、Microsoft 推动的根证书计划演化、Web PKI 与 PGP/KP 生态的重新融合（MOFO、mailkeys 等尝试）本质上仍在处理这同一个问题。

1.4 X.509：从标准到体系（1988–2008）

密码学提供能力，标准提供语法。X.509 正是把"公钥 + 身份声明 + 签名"规范化为可互操作数据结构的协议。

X.509 标准由 ITU-T 制定，最初版本可追溯至 1988 年。此后它在 ITU-T 与 ISO/IEC 联合体系中以 X.509 命名发布，其公钥密码与签名相关部分被 IETF 采纳为 RFC 5280 的基础，PKIX（Public Key Infrastructure X.509）成为事实上的全球 PKI 规范。

图 1：X.509 证书与信任链的演化脉络（1988 → 2025）。X.509 从 ITU-T 的孤立的目录标准演化为支撑整个 Web PKI 的规范体系。演进主线是"结构标准化 → 扩展灵活化 → 与运行时（TLS）与自动化（ACME、CT）绑定"。（图源：ITU-T X.509 各版本、RFC 5280、RFC 9162）

X.509 v3（1996 年发布）是这条路上的分水岭。它的核心贡献是扩展机制（Extension）：在不影响基本结构的前提下，允许标准之外的字段承载新语义。此后几乎所有重要的 PKI 演进都寄生在 v3 扩展之上：

• Key Usage / Extended Key Usage：区分密钥可用于签名还是加密、适用于服务器认证还是代码签名。
• Subject Alternative Name（SAN）：承载 DNS 名称、IP 地址、邮箱、URI。这一条是 CA 史中技术含量最高的细节之一——它把"名称"从证书里唯一的主体字段，变成了一个可扩展的列表，从而直接支撑了"一张证书覆盖多个域名"这一现代 Web 的基本需求，也直接引发了 CN 弃用（Common Name deprecation）这一长期议题。
• Name Constraints：限定某中间 CA 只能为哪些名字签发证书。这是历史上少数"约束"型扩展，对后来 Google CT 日志等"限定签发范围"的机制有直接思想影响。
• CRL Distribution Points / Authority Information Access：指向吊销信息与 CA 策略的获取位置。
• Certificate Policies：把 CA 的业务规则写入证书，用一个 OID 对外标识，是法律效力判定的关键锚点（详见第六章美国部分）。
• Subject Key Identifier / Authority Key Identifier：链构建的辅助字段。
• 预证书（pre-certificate）专用扩展：CT 机制要求为预证书分配一个独立的、预留的 CT 日志签名时间戳空间。

RFC 3280（2002）→ RFC 5280（2008） 标志着 PKI 从"事实惯例"变成"成文规范"。RFC 5280 定义了证书路径验证算法（Basic Certificate Path Validation）、各扩展的 profile、算法与密钥长度的建议基线，以及吊销检查（CRL、OCSP）的处理方式。今天几乎所有 CA 的产品实现、几乎所有浏览器与 TLS 库的路径构建器都以 RFC 5280 为准绳。

1.5 密码算法的谱系与更替

CA 史的另一半主线是算法的生命周期管理。一个 CA 的根密钥一旦签出，其寿命以十年计；这意味着一旦根密钥采用了某种算法，整条信任链的命运就被锁定在该算法的安全余量上。算法迁移因此永远是 CA 产业最昂贵、最缓慢的工程之一。

图 2：核心算法谱系的更替节奏。三条谱系——对称密码、签名算法、摘要函数——各自的淘汰节奏并不一致。CA 体系受算法迁移的约束最强，因为根密钥不可更换。（图源：NIST FIPS 197（AES）、FIPS 186（DSA）、RFC 5280 附录、RFC 6962）

各条谱系的关键节点：

• DSA（1991，NIST 数字签名标准）：与 RSA 并列的长期选项，也是美国政府在 1990 年代「Capstone 计划」的核心算法。但 DSA 存在密钥长度与安全强度的非线性问题（1024 位 DSA 与 1024 位 RSA 的实际强度不等），在 TLS 场景中长期处于边缘。实践上，RSA 在 Web PKI 中长期占据统治地位，ECDSA 随 TLS 1.2 与 1.3 的普及快速上量，Ed25519/Ed448 则以更简洁的实现与更好的性能在现代协议中取得一席之地。
• ECC（1985 年 Neal Koblitz、1987 年 Victor Miller 独立提出）：椭圆曲线上的公钥密码。相较同等安全强度的 RSA 密钥更短（256 位 ECC ≈ 3072 位 RSA），这对证书体积、TLS 握手带宽、云原生设备与 IoT 场景意义重大。ECC 已成为现代 TLS 的默认推荐之一。
• SHA-1：这是 CA 史上最重要的一次算法退休。2005 年起 SHA-1 碰撞构造研究持续取得进展，2017 年 Google 与 CWI 公开了实际的 SHA-1 碰撞（"SHAttered"），2019 年 CWI 展示了可行的"碰撞攻击"（chosen-prefix 攻击）用于伪造证书签名。CA/B Forum 自 2017 年宣布淘汰时间表，自 2020 年 1 月 1 日起全面禁止签发 SHA-1 签名证书。Shamir 在 2005 年的一篇著名论文中预见到攻击成本会随算力下降而崩塌，事实完全按其预期演进——这也是密码学史上"可扩展安全性"论证的一个经典案例。
• 1024 位 RSA：2013 年由 CA/B Forum 与浏览器厂商共同宣布在 2013–2014 年逐步淘汰，2017 年 Mozilla 进一步公布 SHA-1 与 1024 位 RSA 的完整淘汰时间表。

图 3：根证书密钥算法迁移的"不可逆性"结构。根密钥的不可续期性是 CA 治理中少数几个"物理约束"。这也是为什么 RSA 2048 → ECC 迁移无法自上而下"一键切换"，而必须依赖交叉签名、短期根并行与分阶段退役。（图源：Mozilla 根证书项目纳入标准（根密钥不可续期条款））

!配图 2｜PKI 分层信任结构：根 CA、中间 CA、终端证书、注册机构与依赖方

“

配图 2｜PKI 分层信任结构：根 CA、中间 CA、终端证书、注册机构与依赖方

>
算法淘汰的节奏各不相同，而根密钥的不可更换性使 CA 成为迁移链条中最刚性的环节

第二章 SSL/TLS 与 Web PKI 的建立（1994–2010）

2.1 Netscape 与 SSL 的诞生，浏览器信任模型的确立

1994 年 11 月，Netscape 发布 SSL 1.0。这是 Web PKI 的起点，也是整个 CA 产业格局的起点。

SSL 1.0 的核心贡献不是密码学（它用的是 RC4 与 RSA），而是把"服务器身份认证"写进协议本身。此前，HTTP 是明文且匿名对等的；SSL 引入了一条"服务器出示证书、客户端验证、随后协商对称会话密钥"的三段式流程。客户端的验证动作，实际上就是在验证一条证书链：叶子证书 → 中间 CA → 根 CA，而根 CA 来自浏览器内置的信任库。

这个设计决策的后果极其深远，它决定了此后三十年 CA 产业的权力结构：

1. 信任的锚点是软件发行者，不是协议规范。X.509 由 ITU-T 制定，但根证书列表由 Netscape、后来是 Microsoft、Apple、Google、Mozilla 各自维护。技术标准由标准化组织制定，信任由市场参与者授予。
2. CA 是"准入特许"的行业。任何人都可以运行一家 CA 并签发技术上完全合法的证书，但如果它的根证书不在主流浏览器的信任库里，这些证书对全球用户就等于无效。CA 的实际权力来自信任库中的位置，而不是来自密码学。
3. 信任管理成为持续性的政治议题。把一家公司"加进信任库"是一个低频、高影响的动作；把一家公司"踢出信任库"更是。这为第四章的一系列大规模信任撤退埋下了机制前提。

图 4：SSL/TLS 协议版本的演进。TLS 1.3 的核心成就不是"更强"，而是"更少"——把状态机从数十个消息缩减到 1-RTT，并移除了 RSA 密钥交换、静态 DH、CBC 模式与压缩等历史包袱。（图源：RFC 2246、RFC 4346、RFC 5246、RFC 8446）

表 2：主要 SSL/TLS 版本的技术要点与现状

说明：版本号与年份依据 RFC 原文与浏览器公告；"全面淘汰"指主流浏览器停止默认支持的时间窗，各家略有差异。

SSL 2.0 的捐赠是一个常被忽略却极具启发性的节点。 SSL 2.0 存在严重缺陷（包括不安全的长度字段处理等），Netscape 于 1995 年将 SSL 2.0 的相关权利捐赠给社区，后由 Apache 与 Netscape 前身合作开发并最终将 TLS 交给 IETF 标准化。这一"把有缺陷的私有协议交还给公共标准组织"的动作，恰好发生在公钥密码的标准化（X.509）尚未完成的时刻，构成了后来整个 Web 信任生态的原型：技术缺陷不靠单个厂商修复，而靠信任的重新分配来修复。

2.2 证书类型演进与验证模型

Web PKI 的第二个关键设计是验证等级的分类，它把一个技术问题转化为一个商业与法律问题。

表 3：DV、OV、EV 三类 TLS 证书的对比

说明：EV 证书的浏览器标识已在多数主流浏览器中被撤除，详见 2.3。有效期上限以 CA/B Forum Baseline Requirements 现行与已通过的未来生效版本为准。

验证模型的形成背景，与电子商务的信任需求直接相关。在 2000 年前后，"如何让消费者相信网上商店是一家真实公司"是一个真实的商业问题。OV 与 EV 提供了介于"完全匿名"与"线下同等核验"之间的中间地带：OV 用可自动化核验的登记信息（工商登记、域名 WHOIS、DNS 记录）换取有限度的可信度；EV 则用人工核验换取了当时浏览器厂商愿意给予的额外视觉标识。

在技术上，DV/OV/EV 三者的差别只在于验证强度，而不在于签发技术。三者都是 X.509 证书，都可由同一根签发，区别在于 CA 在签发前投入的核验流程深度。这也是为什么 2020 年 Let's Encrypt 的 CAA 缺陷会波及约 170 万张证书——事故原因与验证等级无关。

2.3 EV 证书的兴衰

EV 证书的历史是一条"被赋予神圣意义、被市场用脚投票、最终失去可见性溢价"的曲线。

• 2013 年 4 月，Chrome 推出 EV 证书白名单机制：只有出现在 CA/B Forum 认证的 EV 证书与特定根证书中，才被赋予特殊的视觉标识（当时是特定的浏览器界面元素），并引入 Certificate Policy OID 的可点击展示。
• 2015 年，Chrome 移除地址栏中的 OV/EV 主体名称显示，证书被降级为与 DV 同级的"域名验证"呈现；并对非 EV 证书隐藏绿色安全标识，撤除"Shop with confidence"（放心购物）字样。逻辑是：EV 标识本应用于区分"高信任"与"普通"证书，但既然绝大多数证书都是 DV，这个标识对普通用户不再传递任何有效信息，反而制造了虚假的安全感。
• 2015–2018 年，EV 证书成为 Symantec 信任撤退事件的最大受害者。由于 Chrome 强制 EV 证书必须携带来自受信任 CT 日志的 SCT，而 Symantec 系证书在撤销过程中无法满足该要求，其 EV 证书的移除对用户可见影响远大于普通 DV 证书。
• 2018 年，Apple 在 iOS 12 / macOS 10.14 的 Safari 中移除地址栏 EV 公司名；Chrome 69 移除绿色地址栏与"Secure"标签。
• 2019 年 9 月，Chrome 77 将 EV 标识从地址栏移入 Page Info 面板；2019 年 10 月，Firefox 70 将 EV 标识移入站点信息面板。至此，EV 标识在所有主流浏览器中彻底退出了地址栏这一唯一有效展示位。
• 2019 年，CA/B Forum 宣布 EV 证书需执行"地理验证"——需核实申请者的公司地址在物理上确实位于其所在国家，以应对批量注册海外空壳公司获取 EV 证书的滥用。
• 2021 年，Google 内部研究显示仅 11% 的参与者正确理解挂锁图标的含义。
• 2023 年，Chrome 117 用中性的"调节（tune）"图标取代了挂锁图标。

用户研究给出了同样的结论。 Google 安全 UX 团队的现场实验结论是"EV UI 未能按预期保护用户"——移除 EV 标识并未改变用户的安全决策指标；Mozilla 的研究则得出，公司名显示"未增加任何额外安全参数"。

商业后果是 EV 与 DV 在技术能力上完全等价：两者均可使用 RSA-2048 + SHA-256 + AES，EV 溢价所买到的只是身份审核的 paperwork，对钓鱼攻击没有额外防护价值。

这里必须给出一个准确的结论，因为"EV 已死"是常见的误读。 EV 证书并未消失，CA 仍在销售，各国的金融与政务采购清单上它仍然是指定项。准确的说法是：浏览器已取消其可见性溢价，EV 在多数公开网站上退化为合规采购项而非信任信号。 它的溢价空间来自采购流程的合规要求（招标、审计、供应商准入），而非终端用户的可见信任——这是一个关键区分：EV 曾经是一个面向消费者的信任产品，现在是一个面向采购方的合规凭证。

这背后有一层更深的启示：CA 产业的产品形态，本质上被终端的信任模型反向塑造。终端说"标识无用"，整个品类就萎缩；终端说"CT 强制"，整个产业就重写签发流水线。CA 从来不是自变量。

2.4 浏览器根证书计划与"准入即信任"

随后的演进把第四章的"根证书计划"概念推到了前台。严格地说，早期的 Netscape 与 Microsoft 各自维护根证书列表，但从 2000 年代起，Google 与 Mozilla 相继建立并制度化了自己的根证书计划（Root Program），加上 Apple 与 Microsoft，到今天形成了四大根证书计划（Google Chrome Root Program、Mozilla Root Store、Apple Root Certificates、Microsoft Trusted Root Program）。CA/Browser Forum 的成员构成亦由此形成：CA 侧与浏览器/根证书计划侧。

表 4：四大根证书计划与 CA/B Forum 的角色对照

图 5：CA 行业的"两极"权力结构。公开信任是一条自上而下的、极窄的入口通道。任何未被四大计划接纳的 CA，无论技术多强，都只能在封闭信任域内运作——这正是各国"政府/政务 PKI"体系与"公开信任 PKI"体系长期并存却互不流通的根本原因。（图源：CA/Browser Forum 章程与四大根证书计划公开政策）

"准入即信任"逻辑的直接后果，是 CA 行业出现了一种罕见的双头垄断结构： 在供给端，CA 数量被根证书计划严格控制（全球受信任 CA 数量长期维持在数十家量级）；在需求端，签发需求来自全世界的网站，而其中新增需求的最大来源——HTTPS 全网普及——高度自动化、极度价格敏感、极度规模化。

这个结构在 2015 年之前长期由商业 CA 垄断，代价是价格高、流程慢、签发需逐个核验。而它最终被打破的方式，不是技术突破，而是一个新的组织形态的出现：一家不销售证书、只提供 API 的非营利机构，撬动了这个市场的价格结构。下一章与第五章会分别讲述这个机构背后的自动化协议（ACME）与透明机制（CT）。

!配图 3｜SSL/TLS 协议演进时间轴与安全强度递增曲线

“

配图 3｜SSL/TLS 协议演进时间轴与安全强度递增曲线

>
公开信任是一条自上而下的窄入口通道，未被接纳的 CA 只能在封闭信任域内运作

第三章 治理体系的形成：CA/Browser Forum 与基线要求

3.1 从各自为政到联合治理

2011 年之前，CA 行业的规则来源是分散的：每个 CA 各自制定政策，浏览器厂商各自决定信任与不信任，标准组织各自出规范。当 DigiNotar 事件发生时，这个松散结构的问题暴露无遗——没有一份全行业共同签署的、可强制执行的最低行为规范。

2011 年，CA/Browser Forum 成立。它不是政府机构，不是标准组织，而是一个由 CA 与根证书计划共同签署的行业自律联合体。这一性质决定了它的全部能力边界，也决定了它在治理中的独特位置：

• 它制定的是合同法意义上的规则，而非法律。Baseline Requirements 是 CA 与根证书计划之间的强制协议条款：CA 签署加入时承诺遵守，根证书计划保留审计与移除的执行权。
• 它的执行不依赖国家执法机构，而依赖"准入资格"这一私法上的杠杆。违规的最终制裁是失去全球信任——这在实践中的威慑力往往超过罚款。
• 它因此成为全球 CA 治理的事实上枢纽，包括那些没有 CA 立法准入的国家（美国、日本、韩国部分市场）也都适用其规则，因为根证书计划是这些市场唯一的信任入口。

表 5：CA/Browser Forum 成立背景与构成

说明：CA/Browser Forum 成立于 2011 年是行业公认事实；其成立与 DigiNotar 事件的直接因果关系为业界普遍认知，具体表述各来源略有差异。

3.2 Baseline Requirements 的结构与约束力

Baseline Requirements（BR，基线要求）是这份体系的宪法文件，现行版本为 2.3.1（2026 年 10 月 4 日），此前为 2.2.1（2025 年 12 月 16 日），更早的 2.1.5 于 2025 年 5 月 16 日生效。版本号的小步快跑本身就是治理节奏的体现：BR 几乎每年都有修订。

其约束条目覆盖范围之广，超出多数人的想象。除大家熟知的证书签发流程外，还包括：

• 证书签发前的信息收集与核验要求（各类验证方法、授权联系人、域控制权证明）
• 订阅者证书的签发前必须完成 CAA（Certification Authority Authorization）检查——CA 必须先查域名的 CAA 记录，若该域名的 CAA 指定了某 CA，则其他 CA 不得为其签发证书
• 域名验证方法（Domain Validation Method）的强制约束
• 算法强度与密钥长度基线
• 证书有效期上限
• 吊销机制（CRL/OCSP）要求
• 审计（WebTrust for Certification Authorities）、年度合规审计、日志留存年限、自评抽查比例
• CT 日志记录要求
• 事件报告（Incident Reporting）义务——CA 必须在 24 小时内向论坛报告重大安全事件
• 订阅者证书唯一标识（Unique Identifier）要求
• 预证书与 SCT 的处理

BR 的约束力来自三个杠杆的叠加：审计（WebTrust for CAs，叠加 ETSI EN 319 411、EN 319 411-2、EN 319 412-4/5 等标准作为审计依据）、公开根证书计划（不合规即失去全球信任）、行业声誉与集体诉讼风险（Symantec 事件的民事诉讼金额是这一杠杆威力的直接体现）。

3.3 密码算法与强度迁移时间表

CA 产业处理算法迁移的机制，是一套"多方公告 → 论坛表决 → 分阶段强制 → 追溯惩罚"的流水线，其典型案例就是 SHA-1。

表 6：主要算法与强度淘汰时间线

表 7：CN 弃用与 SAN 强制的时间节奏

说明：各浏览器具体生效日期略有差异，此处为 Chrome 主导的时间节奏，具体实施以各家根证书计划公告为准。

这里有一个值得强调的机制特征：算法淘汰的"惩罚"往往追溯生效。已签发但尚未过期的旧算法证书会被要求提前作废，这直接触发了 2018 年 Chrome 对 Symantec 系证书的分阶段缩短有效期（从 33 个月逐步压到 Chrome 64 的 9 个月）——一个算法政策被用来执行一次信任惩罚。这种政策工具的复合使用，是 CA 治理走向成熟的标志，也是 CA 运营方合规成本上升的主要来源。

3.4 有效期收缩运动：SC-081v3 与 47 天时代

Ballot SC-081v3 是 CA/Browser Forum 历史上影响最深远的一次表决。

表决于 2025 年 4 月 4 日至 11 日进行：CA 方 25 票赞成、0 票反对、5 票弃权；Apple、Google、Microsoft、Mozilla 四方全部赞成。这一票型分布本身就是产业政治的一个缩影——推动方是全球信任的守门人，承受方是全球签发能力的持有者，而 CA 侧以弃权表达了"技术上可行但商业上难办"的保留态度。

表决通过的内容是公信 TLS 服务器证书最长有效期的分阶段收缩：

表 8：SC-081v3 有效期收缩时间表

图 6：证书有效期收缩的政策传导链条。47 天不是终点，而是把"签发"从重资产人工服务变成高频 API 调用的转折点。自动化与短生命周期的组合，反而可能比长证书时代的整体系统成本更低。（图源：CA/Browser Forum Ballot SC-081v3（2025-04 通过））

与之配套的关键设计，是"短期证书豁免吊销"：自 2026 年 3 月 15 日起，有效期 ≤7 天的证书，CA 可豁免吊销要求。这看似是一个小小的技术性豁免，实则是整个制度的枢轴——它承认了一个此前被回避的事实：在证书存续期只有七天的情况下，"吊销"这一机制在物理上很难有意义地执行。短证书没有机会被泄露后仍在有效期内被大规模滥用的窗口，与其为这七天维护吊销基础设施并承担误吊销风险，不如把资源投向签发侧的严格控制。

由此产生的连锁反应是：签发频率提高数倍到数十倍，自动化能力从"加分项"变成"生死线"，CAA 复检、吊销状态检查、CT 日志提交等每一个环节的自动化缺陷，其影响面都被同步放大——这正是 2020 年 Let's Encrypt CAA 事故的机制土壤。

签发流程的全链条可以概括为八个环节：申请、CAA 检查、域名验证、签发、SCT 嵌入、部署、续期，以及到期或吊销。这条链上每一个环节如今都由机器执行——而机器不会犯“疏忽”的错，只会犯“逻辑”的错。

!配图 4｜证书生命周期与自动化流水线：八环节流程、三级有效期阶梯与无吊销设计

“

配图 4｜证书生命周期与自动化流水线：八环节流程、三级有效期阶梯与无吊销设计

>
证书签发的完整链路：从申请、CAA 检查、域名验证到签发、SCT 嵌入与部署续期，每一环都由机器执行——因此每一环的缺陷都会被同步放大。有效期阶梯（200 天→100 天→47 天）与「≤7 天豁免吊销」的分界线，标出短证书时代治理逻辑的转向。（图源：CA/Browser Forum Baseline Requirements v2.3.1、Ballot SC-081v3、ACME RFC 8555）

3.5 自动化与多视角签发：SC-067、ACME、ARI

多视角签发（Multi-Perspective Issuance and Post-Validation Monitoring） 是与短证书配套的另一种风控思路：不追求"CA 单点判断绝对正确"，而是要求从多个地理隔离的网络视角独立完成验证，使得单个 CA 系统被攻破时，攻击者仍需同时攻破多个独立视角。

Ballot SC-067（TLS 领域，2024 年 8 月 5 日通过，2025 年 9 月 15 日生效）与 SMC-010（S/MIME 领域，2024 年 12 月 22 日通过）共同规定：域名验证与 CAA 检查必须从至少 2 个地理隔离（相距 ≥500 公里）的网络视角执行，并按下列节奏递增：

表 9：多视角要求的递增节奏

图 7：多视角签发的验证拓扑。多视角的核心不是"多一次检查"，而是"把验证的信任假设从单一 CA 系统的正确性，转移到多个独立执行点的不可同时攻破性"。（图源：CA/Browser Forum Ballot SC-067（TLS）与 SMC-010（S/MIME））

Ballot SC-088（2025 年 10 月 9 日通过）则引入了 DNS-PERSIST-01 挑战类型：通过在目标域名的 DNS 中长期驻留一条与 ACME 账户绑定的 TXT 记录来证明控制权。传统 DNS-01 挑战需要每次签发都动态更新 TXT 记录，这意味着每次签发都要改动域名的 DNS 区域记录；而常驻 TXT 记录在自动化续期的场景下显著降低了操作复杂度与失败率——在 47 天时代，续期是常态而非例外，这类优化的价值被成倍放大。

ARI（ACME Renewal Information） 是 2025 年发布的 ACME 扩展，其作用是让 CA 能够提前告知证书即将到期，从而让客户端不必等到证书已过期才被动发现，并在自动化的续期链条中消除"证书已过期但客户端尚未感知"这一常见故障源。相关方向还有 MPIC（多视角签发佐证） 的概念化工作——值得注意的是，Let's Encrypt 早在 2020 年前后就已实现了功能类似的机制，早于标准化讨论。

3.6 域名验证方法的演进与废除

CA/Browser Forum 的域名验证方法编号体系，是制度演进的微观标本。

2018 年 8 月 1 日起，域名验证方法 1（Domain Validated via Organization Email）与方法 5（Domain Validated via Traditional Email）被废除。这两个方法都依赖电子邮件确认：方法 1 依赖域名联系人邮箱，方法 5 依赖类似 WHOIS 管理员邮箱的路径。它们被废除的核心原因是责任链脆弱——攻击者只要能劫持一个与目标域名相关的邮箱，就可能完成对第三方域名的控制权证明，而这条路在 2013 年 Target 事件（一家第三方公司的证书被用于劫持其合作伙伴的支付域名）之后被公认为不可接受。废除它们，同时推动了行业向基于 DNS 与 HTTP 的自动化验证全面迁移。

同期被推动的还有一项关键安全机制：CAA（Certification Authority Authorization）。CAA 记录由域名持有者在其 DNS 中发布，声明"哪些 CA 有权为我签发证书"。CA 在签发前必须查询并遵守。这项机制把"谁能为我签发证书"的决定权还给了域名持有者，是整个体系中少见的由终端用户直接行使的授权约束——它不依赖 CA 的自觉，也不依赖浏览器的信任库，而依赖域名控制权本身。正因如此，2020 年 Let's Encrypt 的 CAA 缺陷才格外刺眼：一个本应由用户直接行使的控制权，在自动化流程中因为一行逻辑错误而失效。

第四章 事故、吊销与信任的重构

4.1 DigiNotar（2011）：信任体系的第一次系统性崩塌

2011 年 7 月，Comodo 的一家经销商遭遇攻击。攻击者利用该经销商与 Comodo 内部 CA 之间的信任关系，通过 CA 签发的中间证书，为包括 Google.com 在内的多个知名域名签发了包含额外受信任根的伪造证书。

荷兰公司 DigiNotar 是这次事件的主角——它为经销商提供了实际签发能力。事件迅速升级：2011 年 9 月，Google Chrome 与 Firefox 用户开始遭遇证书错误提示（Google 全网范围的证书警告一度使部分用户无法正常浏览），矛头直指 DigiNotar。荷兰政府随后采取史无前例的行动——紧急从其信任库中移除 DigiNotar 的根证书。这是欧盟境内首个被吊销的信任根，一个此前被认为只面向企业商业失败的技术事件，升级为涉及国家网络主权的国家安全事件。荷兰政府同时宣布对 DigiNotar 的吊销进行独立调查，DigiNotar 最终破产。

DigiNotar 事件的历史意义有四层：

1. 它证明了根证书的签发能力可以被间接滥用。攻击者不需要攻破根 CA 私钥，只需要攻破一家受信任的 CA 或其授权的下游机构。信任链的强度取决于链上最弱的一环，而这条链上有数百环。
2. 它把"根证书不可撤销"这一幻觉打破。此前普遍认为根证书一旦进入信任库就近乎永久有效；DigiNotar 证明国家可以在数日内做出移除决定。
3. 它直接催生了 CA/Browser Forum 的成立（2011 年）与最初的审计强化。
4. 它也间接催生了 CT 机制的构想——即"让所有证书签发都被第三方记录并可被公众监督"。DigiNotar 事件暴露的核心问题是：CA 的签发行为是私有且不可见的，除了受害方主动报告，无人知道一张伪造证书已被签发。CT 的思路是把签发行为从私有变为公开。

4.2 CNNIC 与政府 CA 事故（2013–2015）：授权链的责任真空

这一组事件的特殊性在于，它们的主角不是商业 CA，而是政府或国家背景的认证机构。

2013 年 9 月，法国政府机构 ANSSI 所属的 CA 因人为错误，为多个 Google 域名签发了伪造证书。这是一起典型的内部人员失误型事故，ANSSI 随后公开承认并撤回了相关证书。

2013 年 12 月 3 日，同一机构再现第二起事故：某商业设备被入侵后，攻击者使用 ANSSI 中间 CA 的私钥为 Google 域名签发伪造证书。Google 采取的处置不是移除 ANSSI 根证书，而是将其信任范围限制到法语区顶级域名——.fr / .gp / .gf / .mq / .re / .yt / .pm / .bl / .mf / .wf / .pf / .nc / .tf。这是"范围限制"手法的一次典型运用，也是法国主权根在技术上仍被广泛信任、但被限定了活动边界的范例。

2014 年 7 月，印度政府下属的 NIC（National Informatics Centre）签发系统被攻破，攻击者为其控制的 4 个域名签发了证书——其中 3 个是 Google 域名、1 个是 Yahoo 域名。Google 采取的应对措施极具示范意义：并未移除印度根证书，而是将 India CCA 根证书的信任范围限制到一张明确的白名单——仅涵盖 gov.in、nic.in、ac.in、rbi.org.in、bankofindia.co.in、ncode.in、tcs.co.in 及其子域。

这种"范围限制而非整体移除"的处置手法，是 CA 治理中一种被低估的精细工具。它的逻辑是：信任的粒度不必等同于机构整体的合格性。移除一个根意味着全球范围内数百个使用该根签发证书的正常站点同时失效（这正是 2015 年 WoSign 事件的痛点），而限制范围则可以在不伤及无辜的前提下切断攻击者的路径。在 2020 年后的短证书与自动化时代，范围限制的可行性大幅提高——因为撤销的粒度更细、影响面更小。

2015 年 3 月，CNNIC 授权的中间 CA——MCS Holdings——为多个 Google 域名签发了未授权证书。技术根因值得记住：MCS 未将 CA 私钥置于 HSM（硬件安全模块）中，而是装载在一台中间人代理设备上。Chrome 与 Firefox 33+ 因公钥固定（public-key pinning）机制拒绝了这些证书。最终，Google 于 2015 年 4 月 1 日宣布不再认可 CNNIC Root 与 CNNIC EV CA。

这是 CA 治理受地缘政治影响的标志性案例，也必须承认这是 CA 史上少数几次由企业单方面决定切断一个主权国家根证书信任的案例。技术上，Chrome 拒绝接受这些证书的直接原因其实是公钥固定而非对 CNNIC 的整体判定——但结果相同。

这组事件暴露了政府 CA 生态中的结构性责任真空：在商业 CA 体系中，CA 承担明确的合同义务并面对可量化的商业后果；而在政府或公共机构体系中，签发错误往往同时涉及机构免责、内部追责困难与跨境追责无门。一个根因被反复出现的模式是：当授权链上存在多层委托（政府授权中间 CA，中间 CA 再委托商业 CA）时，责任认定会随链条延长而模糊，而攻击者会精确地攻击这条最模糊的环节。

4.3 Symantec Distrust（2015–2018）：史上规模最大的信任撤退

这是 CA 史上规模最大的一次信任撤退，其影响范围之广、处置周期之长、涉及主体之众，在公开信任体系建立以来前所未有。

表 10：Symantec Distrust 事件时间线

图 8：Symantec 信任撤退的分阶段执行结构。注意图中的两个并行轨道——一条是"惩罚轨道"（逐步收紧），一条是"吸收轨道"（DigiCert 接管签发能力）。二者共同构成了一种"不摧毁企业、但摧毁信任"的处置范式。（图源：Google Security Blog 2017-03 调查结论、CA/Browser Forum 公告）

规模与影响。 Symantec 系品牌包括 Symantec 自身及其 2010 年收购 VeriSign 安全业务后获得的 GeoTrust、Thawte、RapidSSL。据早期统计口径，Symantec 系证书一度约占全网有效证书的 30%；BleepingComputer 当时报道称约每 6 张 SSL 证书中就有 1 张来自 Symantec。需要说明的是，这类占比数字随统计方法与时间点差异很大——按扫描口径、按 CT 签发口径、按装机量口径得到的结论可以相差数倍，本文引用其作为"量级感"而非精确值。

根因与教训。 这次事件的根因不是密码学失效，而是质量控制流程的整体失效：内部审计机构发现问题后未上报、被收购整合后管理混乱、颁发 EV 证书的流程中缺少有效的独立复核。Google 公布调查结论时，专门讨论了从内部举报、审计发现到最终报告之间的时间跨度——这个跨度本身就是行业病灶的量化指标。

Symantec 事件的三个结构性后果：

1. **它把 CA 治理的重心从"签发正确性"移到了"签发可审计性"**。此后所有关于 CA 的争论，焦点都不再是"你会不会签错"，而是"你能不能证明你签对了、以及你能不能在签错后及时自查"。
2. 它加速了 CT 从"可选"到"强制"的进程（详见第五章）。
3. 它确立了大规模信任移除的标准处置流程：分阶段缩短有效期 → 分阶段报错 → 完全移除，配合过渡名单与政策公告。这套流程在后来的 Entrust、TrustCor、Chunghwa、Netlock 等案例中被反复复用，成为 CA 治理的标准动作。

4.4 WoSign/StartCom（2016–2017）：隐瞒与倒签

2016 年 8 月 17 日，GitHub 安全团队发现 WoSign 未经域名所有者授权，为 GitHub 的域名签发了包含额外受信任根的证书。

Mozilla 的调查记录了至少 14 项安全问题，其中最关键的三个是：

其一是倒签（backdating）。 WoSign 签发了声称在 2016 年 1 月 1 日之前签发的证书，而 2016 年 1 月 1 日正是行业禁止签发 SHA-1 证书的期限。倒签的动机非常明确：用形式上的合规掩盖实质上的违规。通过把签发时间标注为禁用生效日之前，可以让 Chrome 等已实施 SHA-1 淘汰的浏览器继续接受这些本不应存在的证书。

其二是隐瞒所有权。 WoSign 隐瞒了对 StartCom 的全资收购，而 Mozilla 政策明确要求 CA 披露所有权变更。问题在于，StartCom 拥有自己的基础设施、人员、政策与签发系统，与 WoSign 的体系是两套并行资产。

其三是主体资格问题。 这类"表面合规"的操作之所以可行，恰恰是因为行业缺乏对 CA 内部签发记录的独立可验证通道——在没有 CT 的时代，一个 CA 完全可以签发一张自己伪造的、声称属于任何域名的证书，而外部只能通过受害者报告才发现。

处置时间线：

表 11：WoSign/StartCom 信任移除时间线

影响面。 据 RiskIQ 当时估计，约 762,649 个网站使用 WoSign 或 StartCom 证书。这个数字之所以重要，是因为它揭示了信任移除的杀伤半径：一个中等规模 CA 的失误，可以一次性让数十万正常运营的网站亮起警告。

这与 DigiNotar 形成了鲜明对比：DigiNotar 影响的网站数以千计，WoSign 影响数十万。而 CA/Browser Forum 由此建立的过渡机制——白名单、逐步收缩、提前公告——正是在这两次事件之间演进出的一整套"信任拆除工程"方法论。今天读者在浏览器中看到的"此证书的颁发机构不受信任"以及根证书移除时的长尾过渡期安排，其制度原型就在这里。

4.5 Let's Encrypt CAA 缺陷（2020）：规模放大效应

2020 年 2 月 29 日暴露的 Let's Encrypt CAA 复检缺陷，是自动化时代 CA 事故的教科书案例。

缺陷本身。 Boulder（Let's Encrypt 的 CA 软件）在处理一个包含 N 个域名的证书请求时，只挑选其中一个域名做 N 次 CAA 检查，而不是对每个域名各做一次检查。这是一个看起来极其微小的循环逻辑错误，但它在语义上等价于：只要请求中有一个域名被 CAA 允许签发，其余所有域名就会被搭便车获得证书。

后果。 约 3,048,289 张证书受到影响，其中约 100 万张为针对同一域名集合的重复签发（对应 2020 年 3 月初 LE 为应对事态而临时将同一账户的重复签发上限从 300 张/3 小时提升至 10000 张/3 小时的应急措施）。当时 Let's Encrypt 在网证书总数接近 1.2 亿张。

违规认定。 该行为违反 CA/B Forum Baseline Requirements §3.2.2.8——CAA 检查必须在签发前 8 小时内完成。之所以影响窗口比直觉更长，是因为 Let's Encrypt 的域名验证有效期为 30 天，这意味着一旦 CAA 检查被跳过，受影响的时间跨度会远超"8 小时"这个单次窗口。

处置。 LE 一度考虑"不吊销、任其自然过期"的方案，但最终选择吊销。自 2020 年 3 月 4 日 03:00 UTC 起分批吊销，至 3 月 5 日已吊销超过 170 万张——其中包含 1,706,505 张已确认完成替换的证书，以及 445 张因 CAA 记录明确禁止 LE 签发而被优先吊销的证书。其后逐步吊销，最终约 170 万张证书被吊销。LE 同时提供 checkhost.unboundtest.com 查询工具与 letsencrypt.org/caaproblem/ 的全量序列号清单。

这个案例的教诲有三层：

1. 自动化把单点缺陷放大为产业级事故。在手工签发的时代，一个 CA 员工一天签发几百张证书，一个笔误的影响以百张计；在自动化时代，同一行错误代码一天影响数百万张。签发流水线的软件质量，已经成为 CA 的第一等风险。
2. 它验证了 CT 与公开审计的价值——这次事故之所以能被完整量化（精确到受影响证书数与序列号清单），前提是所有签发都留下了公开可检索的记录。如果没有 CT，业界可能永远不会知道这个缺陷的存在。这从反面证明了 CT 的必要性。
3. 它揭示了"严格合规"与"最小化损害"之间的张力。吊销 170 万张证书给大量正常用户带来不便，理论上等待自然过期可以避免这种阵痛；但选择吊销的理由是——在这些证书的有效期内，它们对应域名的 CAA 授权状态可能随时变化，而 CA 记录的是"签发时刻"的事实，无法反映"当前时刻"的状态。在信任模型里，签发时刻的事实不足以支撑持续性的授权。这条推理线在后来 MPIC（多视角签发佐证）与持续监控的讨论中反复出现。

!配图 5｜信任撤退事件的规模与影响范围对比

“

配图 5｜信任撤退事件的规模与影响范围对比

>
八起信任撤退事件的规模与影响范围对比——横轴为对数标度，从数千张证书的个案处置到波及全球的根信任崩塌；四色区分商业 CA 事故、政府 CA 事故、自动化缺陷与披露治理

4.6 Entrust、TrustCor、Chunghwa、Netlock：常态化时代的不信任

2018 年之后，浏览器厂商对 CA 的不信任处置进入常态化，其特征是：单次事件的新闻价值下降，但处置的制度化程度上升。

表 12：2018 年后的典型信任移除案例（按移除动因分类）

“

说明：本表刻意区分两类动因。Entrust、TrustCor、ConnectWise 的信任移除源于可核查的技术或合规缺陷（吊销延误、字段缺失、所有权披露、签发事故），处置依据是 CA/Browser Forum 的基线要求；而 2023 年 Chrome 移除部分中国根 CA、2025 年 8 月移除 Chunghwa 与 Netlock，则属政治与地缘层面的决定，不宜与前者混为一谈——后者的触发条件、申诉渠道与恢复路径均不遵循常规的合规争议处理流程。

Entrust 案是这一时期处置流程最完整的一次公开记录，值得展开。 它的完整时间线如下：

表 13：Entrust distrust 事件时间线（2020–2025）

三点值得注意。 其一，受影响的根证书包含 AffirmTrust 品牌——Entrust Root Certification Authority – EC1 / G2 / G4、Entrust.net Certification Authority (2048)、Entrust Root Certification Authority，以及 AffirmTrust Commercial / Networking / Premium / Premium ECC。这不是一家 CA 的问题，而是一个根证书集团被整体移出信任库。 其二，Google 在宣布当日的官方表述是："过去六年，我们观察到 Entrust 存在一系列令人担忧的行为，这些行为未能达到我们对 CA 的预期……"——注意这里的定性是"六年"，意味着处置对象是一个长期模式，而非单次事故。 其三，2024 年 3 月 Mozilla Bugzilla 社区评论中的一句话，可作为对整个行业最直白的概括："A CA that cannot revoke certificates in a timely manner is a CA that cannot be trusted. Full stop."（一家无法及时吊销证书的 CA，就是一家无法被信任的 CA。句号。）

2016 年还有两起值得并列的案例，它们展示了完全不同类型的 CA 失误。

其一是 Comodo 的自动化流程缺陷。 2016 年 10 月，安全研究者发现 Comodo 的自动化流程使用 OCR（光学字符识别）读取邮件内容来判定域名验证是否通过。攻击者只需精心构造一封邮件内容，就被系统误判为已完成验证，从而为并不属于自己的域名取得服务器证书。这个案例的深刻之处在于：失误不在密码学，也不在人的疏忽，而在"把非结构化输入交给 OCR 这类本就不可靠的自动化组件"这一架构选择上。 它与 2020 年 Let's Encrypt 的 CAA 复检缺陷同属一类问题——自动化流水线的每一环都会把上游的微小缺陷放大到全网规模。

其二是 GlobalSign 的误吊销事故。 2016 年 10 月，GlobalSign 错误地吊销了一张用于连接两个根证书的交叉证书（cross-certificate），导致大量站点的信任链断裂——包括 Wikipedia、Dropbox、Financial Times、The Guardian 等知名站点。用户端的典型症状是浏览器持续报错，且必须手动清除浏览器缓存的 CRL 数据才能恢复，实际影响持续 1 至 4 天。这起事故的讽刺之处在于：CA 的"吊销"这一安全机制本身，成了制造大面积不可用的原因。 它也是第四章所述"吊销机制在短证书时代将退居为补充手段"这一判断的重要前例——当签发可以廉价且频繁地重做时，误吊销的破坏力远大于其收益。

ConnectWise 案例值得单独一述，因为它揭示了现代 CA 产业一个结构性特征：品牌、根证书与运营实体三者已经彻底分离。Comodo 品牌下的 13 个根，实际由 ConnectWise 运营。这意味着"某 CA 出了事故"的归因，需要穿透品牌层追到实际运营主体；而当运营主体被收购或转型（如 Entrust 出售给 Sectigo、Symantec 降级为 DigiCert 下属 CA）时，责任归属与合规连续性就成了需要专门处理的问题。

常态化时代的三个特征：

• **处置从"紧急响应"变为"程序化执行"**——触发条件、公告流程、过渡名单规则都被标准化。
• 从"移除信任"到"范围限制"的精细化处置逐渐增加（Google 2014 年限制 India CCA 是早期样本）。
• CA 的身份本身成为资产——TrustCor 因所有权不透明而被移除，Entrust 的公开 CA 业务被出售，都说明"根证书位置"是有价资产，其价值直接绑定合规记录。
• 动因开始分化——处置机制在 2024 年之后同时服务于合规争议与地缘决策，二者的触发条件与恢复路径截然不同，读者引用时须分别对待。

4.7 从事故中提炼的七条治理规律

把上述事故并置，可以提炼出七条规律。它们构成了 CA 治理的"负面知识"。

规律一：事故几乎不源于密码学失效，而源于流程被绕过。 从 DigiNotar 到 Entrust，没有任何一起核心事故是"RSA 被攻破"或"签名被伪造"。它们是流程失效、密钥管理失效（CNNIC 案例中私钥未入 HSM）、控制失效（WoSign 倒签）、或披露失效（TrustCor）。这意味着 CA 安全的重心在运营，不在数学。

规律二：授权链越长，事故越可能发生，责任越难认定。 DigiNotar 案中的经销商、Comodo 案中的下游机构、WoSign 案中的 StartCom、CNNIC 案中的 MCS Holdings——事故总发生在链条的中间环节。每一层委托都在转移风险，也在稀释责任。

规律三：CA 的实际权力来自信任库，而非技术能力。 这决定了 CA 行业的一切治理都必须经由浏览器厂商才能落地，也解释了为什么 CA/Browser Forum 这个"私法联盟"能发挥准公共权力。

规律四：规模化是双刃剑——它既是价值的来源，也是风险的分母。 DigiNotar 影响数以千计的网站，WoSign 影响数十万，Let's Encrypt 的 CAA 缺陷影响数百万。规模放大的倍数远大于效率带来的收益。

规律五：可验证性比正确性更可持续。 在没有 CT 的年代，一个 CA 的清白只能靠自证；在有 CT 的年代，清白可以由任何第三方独立验证。这就是为什么 CT 在 CA 治理中的地位高于任何单一技术改进。

规律六：合规的最终执行者是浏览器，不是法院。 CA/Browser Forum 制定规则、CA 签署承诺、审计机构检查执行，但违反规则的实际后果是由根证书计划即时剥夺全球信任。这种"私法制裁"的即时性与执行力，超过了多数国家的行政执法。

规律七：制度改进总是滞后于事故，但滞后幅度在缩小。 DigiNotar（2011）到 CA/B Forum 成立（2011）几乎零时滞；WoSign（2016）到 CT 全面强制（2018）是两年；Let's Encrypt CAA 缺陷（2020）到 MPIC 讨论（2022–2025）是两到五年。从"事故驱动"到"前瞻预防"的转变正在发生，但主动机制的采纳速度仍慢于事故发生的速度。

图 9：CA 事故的共同根因结构。五类不同的表层原因收敛到同一个结构性问题——签发行为缺乏独立可验证性。这解释了为什么 CT、MPIC、CAA 这些看似不相关的机制，最终都指向同一件事。（图源：本文依据第四章所列各案例归纳）

第五章 证书透明度与可验证信任

5.1 CT 的设计动机：从「CA 自证」到「第三方见证」

第四章反复出现的一个模式是：在没有 CT 的时代，一个 CA 签发了什么，只有它自己知道。这造成三个结构性问题：

• 受害者之外无人知情。DigiNotar 伪造了 Google 的证书，Google 是从用户投诉中发现的；WoSign 的倒签行为是在被公开检视后才浮出水面的。
• 无法自证清白。一家 CA 被指控违规时，唯一的证据来自它自己的日志，而这份日志恰恰是争议标的。
• 无法发现系统性问题。即便 DigiNotar 事件被妥善处置，也没有人能说出"还有多少张这样的证书存在"。

证书透明度（Certificate Transparency, CT） 的设计目标，就是把 PKI 从"CA 自证"范式迁移到"第三方见证"范式。它的核心机制可以用一句话概括：每张证书的签发都被记录在一个公开的、只能追加（append-only）的日志中，任何人可以实时查询、监控并审计这些日志。

CT 的构想源头是 2011 年 DigiNotar 事件之后的反思，但把 CT 变成现实的是一支并不寻常的团队：Google 的 Ben Laurie、Adam Langley 与 Emilia Kasper。Kasper 的背景是 Tor 开发者、ChaCha20 密码设计者与隐私倡导者，这使 CT 从一开始就带有强烈的"公共监督"属性——它的目标不是帮助 CA 自我改进，而是让 CA 的行为对所有人可见。

图 10：CT 生态的四方结构。CT 的四个角色中，日志是唯一的真相源，监控器与审计器是两种不同强度的观察方式——监控器发现"有异常"，审计器证明"没有隐瞒"。（图源：RFC 6962、certificate-transparency.org 社区资源）

5.2 CT 的运作机制：日志、Merkle Tree、SCT、监控器与审计器

!配图 6｜证书透明度机制全景：预证书、Merkle Tree、监控器与审计器

“

配图 6｜证书透明度机制全景：预证书、Merkle Tree、监控器与审计器

>
CT 的完整链路：CA 先构造预证书再向日志申请 SCT，取得后方可嵌入正式证书并签发，顺序不可颠倒；日志以 Merkle Tree 组织条目，监控器检出异常签发、审计器验证日志未被篡改，浏览器最终依 SCT 白名单逐项校验

CT 的技术核心是 Merkle Tree（默克尔树） 与 SCT（Signed Certificate Timestamp，签名证书时间戳）。

日志运作流程：

1. CA 提交一份"证书预提交条目"（pre-certificate submission）给 CT 日志。
2. 日志将其纳入一个按时间顺序的 Merkle Tree，并计算树哈希（tree hash）——一种只增不改的滚动哈希值。
3. 日志为该条目签发一个 SCT，其中包含：该条目的序号、日志 ID、日志的当前树大小（作为"时间锚"）、以及该条目的包含证明（inclusion proof）——即从叶子到根的一条哈希路径。
4. CA 把 SCT 嵌入证书中（作为独立扩展携带），或通过 SCT 列表（在证书中携带一个指向其他日志的 SCT 列表）分发。
5. 浏览器在建立 TLS 连接时验证 SCT：计算证书的日志条目哈希、验证 SCT 签名、验证包含证明能将条目连到当前树大小所承诺的根。

图 11：CT 包含证明与树哈希的验证路径。包含证明让验证者无需下载整棵树即可确认"这张证书确实在某个日志里"。SCT 中的树大小字段则提供了时间维度：树大小是单调递增的，因此 SCT 同时是一个"签发时刻不晚于此"的证明。（图源：RFC 6962 第 2 节（SCT 与包含证明定义））

"只能追加"是 CT 的安全基石。 一旦某个条目被纳入树并被 SCT 引用，日志就无法再把它移除，因为任何后续的树哈希都依赖于这个叶子的存在。这带来两个直接后果：其一，事后删除证据是不可能的——这正是 DigiNotar 类事故最需要的性质；其二，CT 日志本身成为高价值攻击目标——如果攻击者能向日志插入伪造条目，就可能为非法证书"洗白"。日志实现必须极端谨慎，历史上 DigiNotar 也正是通过滥用证书、进而被用于获取日志写入权限。

监控器（Monitor） 是持续抓取日志并比对"应该存在但不存在"或"不该存在却存在"的条目的程序。它们的运行方既包括 CA 自身（自查），也包括独立研究者与社区志愿者。**监控器是 CT 的"报警器"**：它不需要知道攻击者的意图，只需要知道"这个域名不应该由这个 CA 签发"。

审计器（Auditor） 则更强：它持续检查日志是否遵守了 append-only 承诺，方式包括让 CA 提交接受证明（acceptance proof）——即证明某个特定条目仍在树中。若日志曾删除条目，相应的接受证明就会失败。审计器回答的是"日志有没有说谎"，而不是"有没有坏事发生"。

表 14：CT 机制中各角色的职责与失效模式

5.3 CT 的强制化进程：EV → Symantec → 全部证书

CT 从一个"可选的最佳实践"变成"准入门槛"，经历了三步强制化，每一步都由一次事故或一次信任事件驱动。

第一步：EV 证书先行（2015）。 Chrome 开始要求新签发的 EV 证书必须携带来自受信任 CT 日志的 SCT。EV 证书数量少、验证严格、风险高，因此是最容易先行的试点对象。这一步的意义在于：它让 CT 日志在真实生产环境中跑了将近一年，在没有全量压力的情况下暴露了实现问题。

第二步：Symantec 系证书（2016 年 6 月）。 起因是 Symantec 旗下 CA 签发了 187 张未经域名所有者知情的证书（相关调查还牵涉到 DigiCert 的一次误签发）。Google Chrome 随即宣布，自 2016 年 6 月起，Symantec 签发的所有新证书都必须携带有效 SCT，否则不予信任。

第三步：全量强制（2018 年 4 月）。 自 Chrome 68（2018 年 4 月）起，对所有公开信任的 TLS 证书强制要求 CT。这标志着 CT 从"高端证书的附加要求"变成了"整个公开信任体系的地基"。

表 15：CT 强制化的关键节点

第四步：政策演进与日志生态的多中心化。

• 2018 年 4 月，Cloudflare 上线 Nimbus CT 日志。
• 2019 年 5 月，Let's Encrypt 上线 Oak 日志；2020 年 2 月 Oak 进入 Chrome 与 Apple 的批准日志列表。
• 2022 年 2 月，Google 更新其 CT 政策，取消了"必须包含来自 Google 自家 CT 日志的 SCT"的要求，与 Apple 的政策对齐。这一调整是 CT 生态成熟的标志：从"要求必须经过我"转为"要求必须经过被共同认可的若干家之一"，CT 从单一巨头的控制点变成了多中心生态。
• 2025 年 2 月起，Mozilla Firefox 135 桌面版要求 Mozilla 根证书计划内的所有 CA 签发的证书均须携带 CT。

日志生态的现状可以从 Google 批准日志列表（https://www.gstatic.com/ct/log_list/v3/log_list.json）中直接观察。 值得注意的是，并非所有日志都获得浏览器信任——一个未被列入批准列表的 CT 日志，即使在技术上是完全合规的，其 SCT 也不会被主流浏览器接受。这引出了一个重要的治理问题：**CT 生态本身也需要"信任的信任"**，这构成了一个层级化的信任链。

表 16：CT 日志生态的参与者类型

说明：上表为结构性分类的举例，具体的日志名称、归属与批准状态随时间变动，以浏览器公布的批准日志列表为准。

5.4 CT 的局限与 CT 2.0 的搁浅

CT 并非万能。理解其局限，是评估后量子时代与短证书时代治理方案的前提。

局限一：CT 证明"存在"，不证明"正当"。 CT 记录了签发行为，使签发者无法隐藏；但它不判断这次签发是否合规。CT 揭示问题，不解决问题。 误签发依然发生，WoSign 与 Symantec 的问题都是在 CT 之外的机制（审计、处罚）中被处理的。

局限二：隐私与规模。 公开日志意味着每张证书的域名、有效期、签发者都是公开可检索的。这在促进透明的同时，也带来了两类问题：一是可被用于构建域名清单的规模效应；二是对个人类证书（如某些 S/MIME）场景下，公开域名与邮箱映射的敏感性。为此 Mozilla 等浏览器计划在日志层引入"名称加密"（name encryption）与"加密日志"（encrypted log）方向的技术探索。

局限三：日志本身成为关键基础设施。 一旦 CT 成为全量强制，CT 日志就成为整个 PKI 的单点依赖。日志的可用性、正确性与治理中立性，直接影响全网 HTTPS 的可用性。

局限四：CT 2.0 的搁浅。 2021 年 12 月发布的 RFC 9162（CT 2.0） 支持 Ed25519 签名（用于 SCT 的签名算法现代化）与包含证明（inclusion proof）之外的额外机制。然而 RFC 9162 在业界并未被广泛采纳，被业内普遍视为"落地即死"（dead on arrival）。

这个结局本身极具信息量，值得展开：

**CT 2.0 的核心设想是"一个日志可以同时向多个客户端以不同方式提供证明"**——例如对支持 Ed25519 的客户端提供 Ed25519 签名的 SCT，对不支持的提供 ECDSA 签名的 SCT，对不需要包含证明的客户端只提供签名。这样，日志的条目只需记录一次，却能被多样化的客户端消费。

它之所以搁浅，恰恰是因为它解决的问题已经被别的方案解决了。 现实中的 CT 日志普遍采用"一日志一算法"或"一日志多实例"的方式满足多样需求；日志数量的增加在 Web PKI 的语境下并非灾难，反而有助于分散信任。同时，CT 2.0 定义的"证明多态"能力在实践中缺乏强烈的使用场景。加上 RFC 9162 发布时恰逢 RFC 6962 的现网部署已经极为庞大且运行良好，切换动力严重不足。

这是技术标准演进中的一个普遍现象：一个理论上更优的设计，可能因为现网惯性、缺乏迁移激励、或问题已被旁路解决，而永远停留在纸面。 CT 2.0 的命运提醒我们，评估标准演进不能只看技术优雅度。

第六章 各国监管与市场准入

本章的核心区分：在全球范围内，"CA 受到何种约束"这个问题有两条彼此独立的答案线。

第一条线是法律监管线：国家通过立法设立许可、认证、登记与监督制度，对 CA 的设立与业务资格直接施加公法约束。美国、日本、韩国的私人商业 CA 市场基本不存在这条线；欧盟、中国、印度则各有成体系的法律安排。

第二条线是行业自律线：通过 CA/Browser Forum 与根证书计划的私人协议实现约束。这条线实际上是全球性的，包括在有 CA 立法准入的欧盟、中国、印度也同时存在——一个在中国合法经营的 CA，如果其根证书未进入四大根证书计划，其签发的证书对全球互联网用户仍然无效。

两条线的关系是互补而非替代：法律线解决"谁有资格经营"与"用户如何获得救济"，行业线解决"如何让全球浏览器相信你"。这个双重结构，是理解全球 CA 治理的钥匙。

6.1 美国：市场准入 + 行业自律的双轨制

美国没有联邦层面的 CA 许可法。 这是一个经常被误认为"监管缺失"的事实，实际上反映了一种制度选择：美国的信任体系完全建立在"市场准入"机制之上。

其运作逻辑是：一家 CA 无需获得任何政府许可即可开展业务，但它必须被四大根证书计划（Google Chrome Root Program、Mozilla Root Store、Apple Root Certificates、Microsoft Trusted Root Program）接纳，才能在全球范围内被信任。 这就是所谓"准入即信任"。

表 17：美国 CA 治理的四层约束

关于 ESIGN Act 与 UETA。 联邦《电子签名与全球商业安全法》（ESIGN Act, 2000）与各州的《统一电子交易法》（UETA）共同确立了电子签名的法律地位。但要注意：这些法律并非 CA 许可法——它们规范的是"电子签名在何种条件下具备法律效力"，而不是"谁可以签发证书"。判定一份证书所承载的电子签名是否构成法律意义上的"可靠电子签名"，通常需要检查若干技术条件，例如证书策略 OID（Certificate Policy OID）是否为约定的"认可政策"标识、签名私钥是否不可导出、签名是否由订阅者控制、证书是否仍在有效期内、是否未被吊销等。

这组条件是 CA 治理中"技术标准与法律效力直接挂钩"的少见样本。 它解释了为什么 CA/Browser Forum 的 BR 中关于 Certificate Policy 的要求不只是"行业规则"，而具有法律相关性——因为 BR 定义的证书策略 OID 正是各国法律判定"可靠电子签名"的入口。

美国市场的组织结构。 除 CA/Browser Forum 外，美国 SSL 行业生态还包含几个关键节点：CA Security Council（CA 企业的行业组织，后并入 PKI Consortium）、以及以财报与 SSL Labs 测试体系为代表的技术评价生态。SSL Labs 的 SSL Server Test 因其公开的评级体系，事实上成为了衡量 TLS 部署质量的行业公共基础设施。

美国模式的核心特征可以概括为一句话：信任是私法授予的，责任是公法分配的。 CA 通过私人合同取得全球信任，通过公法体系面对用户索赔与监管。

6.2 欧盟：eIDAS → eIDAS 2，法律趋同与信任清单

欧盟是全球唯一为 CA 建立了完整成文法体系的司法辖区，且其框架的完整性远超一般认知。

eIDAS（Regulation (EU) No 910/2014） 自 2016 年 7 月 1 日起在全部欧盟成员国生效，取代了此前的 Directive 1999/93/EC。这一法规的制度贡献主要有三方面。

其一，它定义了三级信任服务（Trust Services）的法律类别：

表 18：eIDAS 框架下的信任服务分类

其二，它区分"合格（Qualified）"与"非合格（Non-qualified）"TSP。 只有获得成员国主管机关批准、并通过合格性评估的 TSP 才能签发合格电子签名。合格电子签名（Qualified Electronic Signature, QES）在欧盟范围内与手写签名具有同等法律效力——这是全球范围内法律效力最强的电子签名类别之一。

其三，它用 EU Trusted List（EUTL）作为官方的信任服务提供方清单。 EUTL 公开可查，是欧盟版的"根信任目录"，任何人都可以查询某个 TSPL 编号对应的 TSP 是否合格、其资质范围与状态。这是一个重要的制度设计：欧盟把"哪些机构有权提供合格服务"变成了一个可公开验证的注册表问题，而不是一个隐含在根证书信任库中的技术事实。

eIDAS 2（Regulation (EU) 2024/1183） 于 2024 年 4 月 11 日通过，引入 European Digital Identity Wallet（EUDI Wallet，欧盟数字身份钱包）。这是 eIDAS 十年来的第一次结构性升级，其关键配套立法包括：

• 2024 年 12 月 4 日通过的五项实施条例，其中包括钱包完整性与核心功能条例（2024/2979）、钱包协议与接口条例（2024/2982）。
• 2025 年 7 月 30 日通过的七项新实施条例，涵盖合格电子登记送达参考标准条例（2025/1944）、属性电子证明的管理、rQSCD（远程合格签名设备）通知机制、合格信任服务的启动、监管机构年度报告要求、电子身份方案的同行评议程序，以及签发合格证书时的身份与属性验证等，自 2025 年 8 月 20 日生效。

对 CA 行业的直接影响是：CA 的业务边界从"网站认证"扩展到了"数字身份"。 EUDI Wallet 意味着未来的合格信任服务不仅要签发网站证书，还要签发个人属性证明（如学历、地址、资质）与钱包相关的合格证书。这在技术上要求 CA 支持更复杂的身份核验流程（对应 2025 年实施条例中的"身份与属性验证"条目）、支持新的证明类型、支持与钱包的互操作协议。

这构成了一个重要的趋势观察：CA 行业正在从"网站身份服务"向"泛数字身份服务"转型，而 eIDAS 2 是这一转型目前在法律层面最明确的推动力。

6.3 中国：电子签名法体系、国密双轨与 2024 年监管新规

中国的 CA 体系是全球最完备的公法准入体系之一，其特点是许可制 + 目录化管理 + 密码合规要求 + 国产算法并行。

法律与规章框架：

• 《中华人民共和国电子签名法》 于 2004 年 8 月 28 日通过，2005 年 4 月 1 日施行，并于 2015 年、2019 年两次修正。
• 该法第十六条明确：从事电子认证服务的主体，需取得工业和信息化部颁发的《电子认证服务许可证》。
• 《电子认证服务管理办法》 自 2009 年施行（2015 年修订），由工业和信息化部负责监管，规定了许可条件、业务规范、监督检查与法律责任。

许可规模。 截至 2023 年 9 月，工业和信息化部许可的 CA 机构共 55 家。这个数字相对美国与欧盟的市场结构是极高的——它反映了中国 CA 行业"牌照化 + 目录化"的制度传统，也塑造了一个与全球公开信任体系完全不同的市场结构。

2024 年的监管新规是理解中国 CA 制度走向的关键节点。 2024 年 9 月 2 日，工业和信息化部发布《电子认证服务管理办法（征求意见稿）》，意见反馈截止 2024 年 10 月 3 日。相较现行办法，征求意见稿的变化方向明确：

表 19：2024 年征求意见稿的主要修订方向

"不得委托"条款是其中最具结构性影响的一条。 现行实践中，CA 普遍将域名验证、证书申请受理等环节委托给代理商或技术服务商完成——这是行业惯例，也是大规模市场得以运转的现实基础。征求意见稿若最终落地，CA 必须自行完成受理与查验、签发与交付，将实质性抬高大中型机构的运营成本，同时压缩小型代理型机构的空间。

《电子政务电子认证服务管理办法》 自 2024 年 11 月 1 日起施行。其中一项关键要求是：采用商用密码为政务领域提供电子签名认证服务的机构，还需经国家密码管理局认定并取得相应资质。这实际上在电子认证服务许可之外，开辟了政务领域的一套叠加准入。

国密双轨并行。 SM2（椭圆曲线公钥密码）、SM3（杂凑）、SM4（分组密码）等国产商用密码算法体系与 RSA/ECDSA 并行运行，形成中国特有的"双轨制"。这一格局在技术上带来真实的挑战：TLS 栈、浏览器、CDN、WAF 等全产业链都需要同时支持两套算法栈；在政策上，双轨也为迁移提供了缓冲，使国密推广不至于一步切断全球互操作性。

地缘政治维度。 2015 年 3 月 CNNIC 授权的中间 CA MCS Holdings 事故（详见 4.2）之后，Google 于 2015 年 4 月 1 日决定不再认可 CNNIC Root 与 CNNIC EV CA。这是 CA 治理受地缘政治影响的标志性案例，也是中国 CA 体系走向"自主可控"的重要推力之一。

产业侧的两个动态（据公开报道，此处为快照信息）：TrustAsia（亚数信息）于 2026 年发布企业级数字信任服务 CaaS 2.0；格尔软件与吉大正元已完成抗量子密码算法改造。

6.4 日本与韩国：产业主导型与政府主导型

日本没有独立的 CA 立法准入制度。 市场上活跃的主要 CA 包括现属 GMO 集团旗下的 GlobalSign，以及 Cybertrust、SIGNET 等本土厂商。所有面向公众的 CA 都必须通过 CA/Browser Forum 规则与四大根证书计划取得全球信任——日本模式在法律层面几乎是"空白"，完全依靠行业自律与根证书准入运转。

这一模式的一个显著特征是本土 CA 品牌的独立生存能力：在几乎没有国内法律壁垒保护的情况下，日本 CA 仍能在全球公开信任市场占有一席之地，这本身说明"准入即信任"机制下的竞争是全球性的、规则是统一的。

韩国的结构更接近"双轨"。

• 政府与公共部门轨道：韩国信息安全认证机构 KISA（Korea Information Security Agency） 运营「Korea Root CA」体系，服务于韩国政府与公共部门的电子签名。这一体系由国家机构主导，面向公共部门，不参与公开商业市场竞争。
• 私人商业轨道：由各商业 CA 运营，并遵循 CA/Browser Forum 规则与四大根证书计划。

韩国的独特之处在于国家根 CA 与商业 CA 体系并行且相互独立，前者服务公权力与内部行政事务，后者服务公开互联网市场。

6.5 印度：IT Act 下的法定 CA 体系

印度是全球最独特的 CA 监管模式——它把 CA 许可直接写进一部综合性信息立法。

《信息技术法》（Information Technology Act, 2000）》 的两条核心条款构成了整个印度 CA 体系的法理基础：

• 第 17 条：授权 CCA（Controller of Certifying Authorities，认证授权控制器） 许可与监管 CA。
• 第 18(b) 条：设立 RCAI（Root Certifying Authority of India，印度根认证机构） 作为根认证机构，为被许可的 CA 签署公钥。
• 第 3 条：赋予数字签名与手写签名同等法律效力。

图 12：印度 RCAI 体系的两条信任链。印度把"数字签名证书"与"SSL 证书"分为两条并行的信任链——这与浏览器生态中"所有公开信任证书最终收敛到同一批根"的格局形成鲜明对比。（图源：印度《信息技术法》2000 第 17、18(b) 条；印度 CCA 公告）

持牌 CA 名单。 截至 2026 年 9 月 29 日，CCA 持牌 CA 共 23 家，其中包括 Safescrypt、IDRBT、(n)Code Solutions、e-Mudhra、CDAC、Capricorn、Protean、Verasys/Vsign、Indian Air Force、CSC、RISL(RajComp)、Indian Army、IDSign、CDSL Ventures、Panta Sign、xtra Trust、Indian Navy、ProDigiSign、SignX、Care 4 Sign、IGCAR、Speed Sign、Assam Rifles。

这份名单本身就是一个耐人寻味的样本：其中既有商业公司，也有印度空军、印度陆军等军事机构，以及 CDAC（印度开发的高级计算中心）、IDRBT（印度储备银行相关机构）、CSC（Common Service Centres，乡村服务(common service)网络）等公共或准公共机构。印度的 CA 许可同时承担了产业政策与公共服务的双重功能。

CCA SSL 签发指南 v1.4（2020 年 8 月） 规定了比 CA/B Forum 更严格的本地要求：

表 20：印度 CCA SSL 签发指南的额外限制（v1.4, 2020-08）

其中"禁止通配符跨越注册控制标签"是一条比 CA/B Forum 更严的规则。 根证书计划中通行的是"通配符不得覆盖公共后缀"（基于 Public Suffix List），而印度的规则进一步收紧了边界——这是各国监管可以比全球行业基线更严格的典型例证。

6.6 其他市场简述

新加坡：设有国家认证机构（Government Technology Agency, GovTech 体系下的新加坡认证机构）提供公共部门信任服务，商业市场则由 Comodo/Sectigo、GlobalSign 等国际 CA 及本土机构参与，同时受 CA/Browser Forum 规则约束。

中国香港：设有香港邮政局主导的公开信任根体系（Hong Kong Post Root CA），并有商业 CA 如 DigiCert Hong Kong、GlobalSign 等并行；商业 CA 同样遵循 CA/Browser Forum 规则。

中国澳门：设有澳门特区政府电子认证体系（由行政公职局下属机构运营的 e_CA 体系），为公共部门提供电子签名服务。

俄罗斯：以国家主导的 PKI 体系为特色，俄罗斯受信任证书颁发机构（Российский удостоверяющий центр）体系在政府与金融领域占据主导地位；同时自 2022 年起，俄罗斯的根证书与浏览器信任关系出现明显调整，国际浏览器对部分俄罗斯 CA 的信任状态发生变化。

巴西：ICP-Brasil 体系是拉美最成熟的国家级 PKI，由国家信息科技研究所（Instituto Nacional de Pesquisas da Computação）运营，签发的 ICP-Brasil 证书在政府与法律事务中具备法律效力；商业市场则由 GlobalSign、Certum、DigiCert 等参与。

印度尼西亚：拥有 PSE（elektronik govt）体系下的国家级根 CA 体系，同时在 2018 年前后曾成为全球受信任 CA 数量增长最快的单一市场之一，随后因多起签发事故与合规问题经历了信任收缩——这与第四章所述的"规模化与合规能力不匹配"模式一致。

土耳其：Ulaştırma ve Altyapı Bakanlığı 体系下的国家根 CA 与土耳其政府主导的信任体系并行。

6.7 全球监管模式对比表

表 21：主要司法辖区的 CA 监管模式对比

图 13：四种监管范式的信任来源结构。四种范式并非优劣关系，而是不同的制度选择。它们的共同点是：「法律只处理"责任与救济"，"全球可互信的信任"始终由根证书计划这个技术—商业联盟授予」。（图源：Regulation (EU) 910/2014 与 2024/1183；中国《电子签名法》；印度 IT Act 2000）

!配图 7｜全球四种监管范式对比

“

配图 7｜全球四种监管范式对比

>
全球四种监管范式的信任来源结构：私法准入型、公法认可型、许可目录型与法定机构型，与表 21 的逐项对比互为图解