图 15:CA 市场在 2026 年的四层结构。四层结构中,第一层(基础信任锚)由极少数机构掌握,第二层被免费与云化双向挤压,第三层是生态型 CA 的新位置,第四层是区域与行业型 CA 的生存空间。(图源:W3Techs、Cloudflare Radar、CA/Browser Forum 会员公开信息)
趋势三:非营利替代。 Let's Encrypt 的成功证明了一件事:在 TLS 证书这个特定品类上,"免费 + 自动化 + 单一使命"的非营利模式可以击败商业模式。 支撑这一模式的三个条件缺一不可:单一且低成本的自动化签发流程(ACME)、足够大的赞助与志愿者支持、以及不与付费业务竞争的组织结构。这个模式不可能复制到需要高强度人工核验的 EV 或政府 PKI 领域——那里恰恰是商业 CA 存续下来的原因。
> 后量子迁移不是一次算法替换,而是三个层次各自不同的工程。终端实体的迁移窗口最宽(2027–2035),中间 CA 次之(2026–2034),而根 CA 的窗口最窄(2026–2032)且不可逆——根密钥生成即锁定,无法续期,到期必须重新走四大根证书计划的准入流程。这一约束决定了根级迁移必须提前十余年启动。(图源:NIST FIPS 203/204/205、IETF LAMPS 与 PLANTS 工作组、CA/Browser Forum 根证书生命周期政策)
其中 EST 与 SCEP 的定位特别值得注意。 它们不是为"网站签证书"设计的,而是为大规模设备/用户证书的注册与生命周期管理设计的——从 SIM 卡到企业 Wi-Fi 认证到 IoT 设备。当证书签发量从"亿"走向"千亿"时,ACME 这类为 Web 设计的协议未必是最优解。
MPIC(多视角签发佐证) 是把"多视角验证"从 CA 内部流程提升为协议层可验证证据的构想。它的逻辑是:如果签发决策由多个地理隔离的视角共同完成,那么 CA 应当能够向客户端证明"这个签发经过了 N 个独立视角的验证"。这一构想的价值在于:它把"信任 CA 的流程"部分转化为"信任可验证的证据",正是 CT 精神的延伸。 Let's Encrypt 早在 2020 年前后就实现了功能类似的机制。
8.4 韧性设计:多 CA 冗余与根证书生命周期治理
多 CA 冗余 是从事故中学到的直接教训。如果一个站点只依赖一个 CA,那么该 CA 的任何事故都会立即中断该站点的服务——Symantec 事件中被波及的数十万网站,本质上都是单点依赖的受害者。
冗余的层次包括:
同一域名由不同 CA 签发(须注意 CAA 记录需允许多个 CA);
证书链跨越多个根(多信任锚路径),使任一根被移除时仍有回退路径;
同一组织运营多个 CA 并相互交叉签名(Entrust 保留 SecCom Trust 根名、Sectigo 收购 Entrust 公开 CA 业务后延续其根资产,都是此类安排的延续)。
根证书生命周期治理 是 Mozilla 政策中最能体现"制度化风险管理"的部分之一。其要点非常明确:TLS 根证书的密钥材料自生成起存续不超过 15 年,S/MIME 根不超过 18 年;到期即从信任库移除,不可续期,必须重新生成密钥对并重走四大根证书计划的准入流程。
图 19:Mozilla 根证书生命周期的硬约束。根证书生命周期的硬约束把"根信任的永久性"这个幻觉彻底消除了——「根是可以被更换的,只是更换的代价极高、周期极长。」 DigiNotar 案例证明这条路径可以在几天内走完(紧急移除),而 Mozilla 的 15 年政策则保证了在正常情况下根会「按计划」、可预期地被替换。(图源:Mozilla 根证书项目纳入标准与根密钥生命周期条款)
第七章 全球根证书服务商图谱
!配图 8|全球 CA 生态版图:区域分布与机构类型
7.1 三种市场口径的差异
在给出任何排名之前,必须先说明排名本身是口径的产物。同一个年份、同一批 CA,在不同统计口径下的排名可以完全不同。理解这些差异,比记住某个具体百分比更有价值。
口径 A:W3Techs「SSL Certificate Authority Market Share」
基于 W3Techs 对启用 HTTPS 的网站的扫描,统计的是"某 CA 签发的证书在受扫描站点中的占比"。这是一个"存量装机量"口径:它反映的是在公开可见的网站上,谁的证书正在被使用。
口径 B:Cloudflare Radar 证书透明度(CT)日志可见证书量
按证书签发到 CT 日志的记录计数,反映的是"签发量",而非装机量。它包含大量从未部署到公开网站的证书:云内部服务、IoT 设备、短期自动化证书、API 通信证书等。
口径 C:其它
如 Let's Encrypt 自身的累计签发量、CT 日志的绝对条目数等。
这三种口径的差异有多大? 一个最直接的例子:Google Trust Services 在 W3Techs 口径中低于 0.1%,在 CT 口径中约占 16.7%。 同一家机构,两个数字相差两个数量级。原因并不神秘:Google 的证书签发主要用于 Google Cloud、GKE、Firebase 等内部与开发者生态——这些场景大量使用自动化签发和短期证书,扫描器很难在公开网站上看到它们;而 Cloudflare Radar 基于 CT 日志,几乎能看到每一次签发。
表 22:三种市场口径的对比
口径
统计对象
反映的维度
主要偏差来源
W3Techs 站点扫描
启用 HTTPS 的公开网站
装机存量占比
忽略私有/内部/IoT 部署;忽略未启用 HTTPS 的站点
Cloudflare Radar CT
签发到 CT 日志的证书
签发流量占比
忽略未提交 CT 的签发;短期证书因续期频繁而被放大
机构自报累计量
单机构历史累计
规模感与趋势
口径与时间跨度不统一;不可横向比较
基于 W3Techs 口径(2026 年 10 月 4 日)的份额分布:
Let's Encrypt 67.4%、GlobalSign 21.9%、Sectigo 4.8%、GoDaddy Group 3.6%、DigiCert Group 1.7%、Actalis 0.7%、Certum 0.6%、Secom Trust 0.2%、SSL.com 0.1%(低于 0.1% 者不显示)。
[来源:W3Techs, 2026-10-04]
作为对照,2025 年 10 月 1 日的同一口径快照: Let's Encrypt 63.5%、GlobalSign 23.2%、Sectigo 6.7%、GoDaddy 4.0%、DigiCert 2.1%。
[来源:W3Techs, 2025-10-01]
这一年间的变化趋势是明确的:Let's Encrypt 上升约 3.9 个百分点,GlobalSign 下降约 1.3 个百分点,Sectigo 下降约 1.9 个百分点,GoDaddy 下降约 0.4 个百分点,DigiCert 下降约 0.4 个百分点。 这与第四章到第六章描述的三条趋势线完全吻合:自动化与免费化(LE 上升)、证书有效期收缩(低价值 DV 的商业空间压缩)、云厂商自营 CA 的挤压。
基于 Cloudflare Radar CT 口径(2026 年第一季度引用值): Let's Encrypt(ISRG)54.4%、Google Trust Services 16.7%、Sectigo/ZeroSSL 11.7%、DigiCert 6.6%、GoDaddy 5.9%、Amazon 3.8%、Microsoft 约 2%、Entrust 约 1%。
[来源:Cloudflare Radar 证书透明度数据, 2026 Q1]
图 14:同一市场在两种口径下的形状差异。把两个口径叠在一起的观察是——CT 口径更像"签发引擎市场",站点扫描口径更像"公开网站装饰品市场"。「前者反映基础设施,后者反映终端。」(图源:W3Techs(2026-10-04)与 Cloudflare Radar CT 口径(2026 Q1))
年度 CA 评选也是一个容易被误读的指标。 W3Techs「Web Technologies of the Year 2025」评出年度 SSL CA 为:GlobalSign 第一(增长更强)、Let's Encrypt 第二、Actalis 第三。历年冠军为:2013 GlobalSign、2014 GlobalSign、2015 Comodo、2016 GlobalSign、2017 IdenTrust、2018 IdenTrust、2019 IdenTrust、2020 IdenTrust、2021 Let's Encrypt、2022 IdenTrust、2023 Let's Encrypt、2024 GlobalSign、2025 GlobalSign。
[来源:W3Techs「Web Technologies of the Year」年度评选]
这个评选口径与市场份额口径不同——它衡量的是"增长与进步",而非"份额与规模"。 一个占 67% 份额的机构如果增速放缓,会在一个以增长为导向的评选中输给一个份额不到 1% 但增长迅速的机构。这是 CA 行业的一个缩影:在自动化与免费化的挤压下,"规模冠军"与"进步冠军"正在分离。 而 IdenTrust 在 2017–2022 年间连续六年获奖,是荷兰 DigiNotar 事件后本国重建信任基础设施的成果。
7.2 TOP 20 根证书服务商逐一介绍
以下按 W3Techs 份额、CT 签发量与行业影响力综合排序。
1. Let's Encrypt / ISRG(Internet Security Research Group)
所属:美国 · 性质:非营利机构 · 成立:2013 年 5 月(ISRG 注册成立)
背景:由 Josh Aas、Eric Rescorla、Peter Eckersley、J. Alex Halderman 发起,Aas 任首任执行主任。Halderman 是著名的加州大学伯克利分校安全研究者;Eckersley 是 EFF 专家;Rescorla 曾主导 Chrome 的 TLS 与 CT 策略工作——这支发起团队的构成本身就说明了 Let's Encrypt 的定位:它不是一家想卖证书的公司,而是一家想把证书签发变成免费公共基础设施的机构。
业务定位:免费 DV 证书,通过 ACME 协议实现完全自动化签发与续期。它不销售证书,而是提供 API——这一选择在商业上自我颠覆,却从根本上重塑了 DV 证书市场的价格结构。
里程碑:2014 年 11 月项目宣布;2015 年 1 月 28 日 ACME 草案提交 IETF;2015 年 9 月 14 日签发首张证书(helloworld.letsencrypt.org);2015 年 12 月 beta 公开;2016 年 4 月 12 日正式发布;2018 年 3 月支持 ACME v2 与通配符证书;2015 年成为首家提供预证书(pre-certificate)的 CA(Chrome 默认不将预证书计入 CT 配额);2019 年 5 月上线 Oak CT 日志(2020 年 2 月进入 Chrome/Apple 批准列表)。
根证书:ISRG Root X1(2020 年 6 月签发)与较新的 ISRG Root X2。
市场地位:W3Techs 口径 67.4%(2026-10-04),CT 口径 54.4%(2026 Q1),双双位居第一。另需注意 W3Techs 的另一组口径区分:在"可识别 SSL CA 的网站"中 Let's Encrypt 占 67.8%,而在全部启用 HTTPS 的网站中占 64.4%(2026-08 快照)——两个分母不同,数字自然不同,引用时须说明用的是哪一个。
规模里程碑:2020 年 2 月 27 日签发第 10 亿张证书;2025 年 9 月底单日签发量首次突破 1000 万张,并在 2025 年末频繁达到该量级;据 ISRG 公开信息,自 2015 年以来累计签发已超 22 亿张。
OCSP 退役是短证书时代最具体的一个案例。 Let's Encrypt 宣布分步退出 OCSP:到期邮件于 2025 年 6 月 4 日停止,OCSP 响应器于 2025 年 8 月 6 日关闭,此后签发的证书不再包含 OCSP URL,仅依赖 CRL 吊销信息。这在技术上是"撤销机制退位"的一个真实案例——在一个日签发千万张的世界里,维护一个高可用的实时状态查询服务,其成本与收益比已经不再成立。
证书生命周期的产品化演进同样值得关注。Let's Encrypt 于 2025 年 12 月 2 日宣布、2026 年 10 月 7 日复述其 2026 年生命周期计划:tlsserver profile 自 2026 年 5 月 13 日起 45 天;classic profile 自 2027 年 2 月 10 日起 64 天(配 10 天授权复用期),自 2028 年 2 月 16 日起 45 天(配 7 小时复用期);staging 环境 2026 年 10 月 14 日切换至 64 天;最后一张 90 天证书预计 2027 年 5 月 11 日到期,且已签发有效证书不予吊销;IP 地址证书必须使用 shortlived profile,而 tlsclient profile 自 2026 年 7 月 8 日起不可用。此外,6 天证书与 IP 地址证书已于 2026 年 1 月 15 日正式全面开放。这组参数是第三章"47 天时代"最具体的落地样本——它展示了一个 CA 如何用两年时间把自己的产品目录整个重排。
资金来源:ISRG 为非营利组织,赞助方包括 Google、AWS、Facebook、Cisco、Mozilla、EFF、OVHcloud、互联网协会基金会(Internet Society Foundation)、Alpha-Omega、Sovereign Tech Agency、Open Technology Fund。这个赞助名单本身就是一份 CA 史的名单——今天互联网基础设施的每一个主要玩家,都在资助一个免费 TLS 基础设施。
2. GlobalSign
所属:比利时注册,现属 GMO 集团(日本)· 成立:1996 年(源自 1995 年的相关业务起步)
业务定位:产品线覆盖 EV/OV/DV 全线证书、代码签名、S/MIME、IoT 与文档签名,是少数在所有类别都有成熟产品的 CA。在 eIDAS 体系下是重要且知名的合格信任服务提供者(Qualified TSP)。
市场地位:W3Techs 口径 21.9%(2026-10-04),位列第二;CT 口径份额相对较低(因其签发大量为企业与 IoT 场景的证书,但 Web 端存量占比高)。在年度评选口径上,GlobalSign 于 2013、2014、2016、2024、2025 年五次夺得年度 SSL CA,是该评选历史上获奖次数最多的机构之一,2013 与 2014 年冠军亦来自 GlobalSign。
值得注意的结构性特征:GlobalSign 属日本 GMO 集团,这使得它成为唯一一家总部与核心业务均在欧洲、但被日本企业集团控股、同时在欧洲与北美市场都占据重要位置的大型 CA。这种跨国资本结构在 CA 行业极为罕见,也让它在地缘政治上具备独特的缓冲位置。
3. Sectigo(含 Comodo、ZeroSSL)
所属:美国/英国 · 品牌沿革:Comodo 于 1998 年成立,2019 年启用 Sectigo 品牌
业务定位:价格带覆盖最广的 CA 之一,从免费 DV(ZeroSSL)到 EV、OV 均有覆盖,在中小站长与开发者市场占据显著份额。2025 年 2 月完成对 Entrust 公开 CA 业务的收购(详见下文第 9 条),使其在 EV 与政府/企业市场的布局显著加强。
市场地位:W3Techs 口径 4.8%(2026-10-04,2025-10-01 时为 6.7%,呈下降趋势);CT 口径 11.7%(Sectigo + ZeroSSL 合并计)——CT 口径下的份额是 W3Techs 口径的两倍以上,说明其签发大量用于非公开 Web 场景。
历史坐标:Comodo 是 2011 年 DigiNotar 事件中被攻击的下游方(其经销商遭攻击,DigiNotar 被利用签发伪造证书),在年度评选中,Comodo 曾获 2015 年年度 SSL CA。
4. DigiCert(含 Symantec、GeoTrust、Thawte、RapidSSL、VeriSign 品牌)
所属:美国 · 历史沿革:本谱系的起点是 RSA Data Security——1986 年开始开发发布面向终端用户的 PKI 产品与工具包,1991 年开始制定 PKCS 系列标准,1994 年与 Netscape 合作将整套 PKI 软件集成进第一版 Netscape Navigator。1995 年 4 月,VeriSign 从 RSA Data Security 分拆为独立公司(Jim Bidzos 主导孵化,投资者含 Visa、Intel、Mitsubishi、Ameritech、Bessemer 等);同年 6 月推出 Secure Server ID 与面向企业的 Digital ID;1996 年 1 月在旧金山 RSA 大会首次公开演示首个在线数字证书签发系统;1996 年为微软 Authenticode 计划提供 Software Developer Digital ID,这是代码签名业务的起点;1998 年 1 月在纳斯达克 IPO(代码 VRSN),成为第一家上市的 CA。1999 年 12 月以约 5.75 亿美元收购南非 Thawte,2000 年 3 月以 210 亿美元收购 Network Solutions 成为 .com/.net 注册局。2010 年 VeriSign 将安全业务(含 Thawte、GeoTrust)出售给 Symantec,2015 年 9 月出售域名注册业务(2016 年完成)。
DigiCert 的关键交易是:2003 年前后取得 Symantec 的证书业务;2015 年 Symantec 的公开 CA 业务由 DigiCert 承接;2017 年中 DigiCert 收购 Symantec 的 Web 安全业务,Symantec 由此降级为受 DigiCert 约束的下属 CA(详见 4.3)。2021 年 DigiCert 被 Thoma Bravo 收购;据公开的股权变更信息,其后由 Clearlake Capital 接手控股。
业务定位:代码签名领域的领导者,也是 EV SSL 的主要签发者之一,产品线覆盖 DV/OV/EV、代码签名、S/MIME、IoT 与文档签名。
市场地位:W3Techs 口径 1.7%(2026-10-04,2025-10-01 时为 2.1%),呈缓慢下降;CT 口径 6.6%。份额下降的原因值得注意——不是业务萎缩,而是行业结构的整体位移:DigiCert 的核心价值在代码签名与高端 EV,而这两块的存量价值在 Web 端并不体现。
5. GoDaddy Group(含 GoDaddy SSL)
所属:美国 · 成立:1997 年
业务定位:依托庞大的域名注册与主机托管用户基础,把 TLS 证书作为捆绑服务销售——这是 CA 行业中"域名+主机+证书"交叉销售模式的代表。客户结构以中小企业(SMB)为主。
市场地位:W3Techs 口径 3.6%(2026-10-04,2025-10-01 时为 4.0%);CT 口径 5.9%。它的份额变化精确对应了第四章到第六章描述的趋势:SMB 客户在 2020 年后大量迁移到免费 DV 证书,捆绑销售的商业优势被自动化签发抹平。
6. Google Trust Services
所属:美国(Alphabet)· 根证书:GTS Root R1–R4、R3、R4 等系列
业务定位:免费 DV 证书 + ACME 自动化 + 运营 CT 日志——它是唯一同时具备"签发方"与"日志运营方"双重身份的大型机构。证书服务于 Google Cloud、GKE、Firebase、开发者项目与企业内部服务。
市场地位:W3Techs 口径低于 0.1%,Cloudflare Radar CT 口径 16.7%——这是全文最能说明"口径决定结论"的一组数据。 真实原因是其签发绝大部分用于 Google 内部云服务与开发者生态,这类证书不出现在公开网站扫描中,而在 CT 日志中则清晰可见。
制度角色:Google 是 CT 机制的原始推动者(Ben Laurie、Adam Langley、Emilia Kasper),也是最早的 CT 日志运营方;Google 同时是 Mozilla、Google Chrome、Microsoft、Trustwave 等多家 CA 根证书计划的共同所有者与审计方——它既是规则的制定者,也是被规则约束的对象,这种双重身份是理解 CA 行业权力结构的关键。
7. Amazon Trust Services(AWS Private CA / ACME)
所属:美国 · 根证书:Amazon Root CA 1–5
业务定位:云原生 CA 服务。AWS 提供私有 CA(Private CA)服务以在企业内部建立 PKI,同时为外部应用签发公开信任证书;并通过 ACME 集成使云上应用可以像普通网站一样自动续期证书。
市场地位:CT 口径 3.8%——这几乎全部是 W3Techs 口径所看不到的部分,因为 AWS 签发的证书大量用于 ELB、API Gateway、IoT、ECS 等内部与平台场景。Amazon 是"云厂商自营 CA"这一结构性趋势最纯粹的样本(见 7.3)。
8. Microsoft
所属:美国 · 身份:Microsoft Identity 根证书体系(历史上亦大量使用 DigiCert 签发)
业务定位:代码签名的关键签发方——Windows 驱动、Office 插件、MSI 安装包、Authenticode 生态;Azure 服务与 Microsoft 365 生态的 TLS 证书;Windows 根证书程序是四大根证书计划之一。
市场地位:CT 口径约 2%。**微软的特殊性在于它同时是"CA"与"根证书计划"**——这种双重身份同样出现在 Google 身上。
9. Entrust Datacard
所属:加拿大/美国 · 沿革:1996 年 Entrust 创立,2013 年与 Datacard 合并为 Entrust Datacard
业务定位:政府、金融机构、HSM 与 PKI 组件(密码硬件、托管签名)领域的强势玩家,公开 CA 业务面向企业与政府客户。
市场地位与状态:2024 年 6 月 27 日 Google 宣布 distrust,2024 年 11 月 11 日 Chrome 生效、11 月 15 日 Safari 生效、11 月 30 日 Firefox 生效(完整时间线见表 13)。受影响的根证书同时包含 AffirmTrust 品牌(AffirmTrust Commercial / Networking / Premium / Premium ECC),因此这是一个根证书集团被整体移出信任库,而非单一 CA。2024 年 12 月 Entrust 宣布出售 CA 业务,2025 年 2 月 Sectigo 完成收购。 这是一次典型的"因长期合规问题导致资产折价"的处置:一家技术积累深厚、拥有大量企业与政府客户信任资产的机构,最终选择退出公开 CA 竞争。CT 口径下其份额约 1%(2026 Q1)。
这桩交易值得与 DigiCert 收购 Symantec、ConnectWise 案的连带效应一起看:公开 CA 业务正在经历一轮结构性整合与退出。
10. Actalis(Aruba 旗下)
所属:意大利
业务定位:意大利 eIDAS 体系下合格信任服务提供方的主力之一,拥有 Actalis Qualified CA,提供 OV、EV、代码签名与文档签名服务。
市场地位:W3Techs 口径 0.7%,位列第六;在 W3Techs「Web Technologies of the Year 2025」评选中位列第三。一个份额不到 1% 的机构能在"进步"维度上进入前三,这本身就是前文所述"规模冠军与进步冠军分离"的直接例证。
11. Certum(Asseco Data Systems)
所属:波兰 · 归属:Asseco 集团
业务定位:覆盖 DV/OV/EV、代码签名、SSL 客户端证书与电子签名的综合型 CA,服务大量欧洲与全球中小企业客户。Asseco 是中东欧地区最具规模的 IT 集团之一,Certum 的市场拓展与集团整体区域布局高度相关。
市场地位:W3Techs 口径 0.6%。
12. IdenTrust
所属:美国/荷兰 · 沿革:1997 年由荷兰 KPN、ING 等机构共同创立,后被 HID Global 收购,2023 年所有权发生变更
业务定位:荷兰国家级的信任基础设施方案提供者,服务于荷兰政府与金融机构。它的存在背景是 DigiNotar 事件后的直接产物——DigiNotar 破产后,荷兰需要一个由本国金融机构共同支撑的、可信的根认证机构来替代它。
市场地位与历史坐标:在 W3Techs 年度评选中,IdenTrust 连续夺得 2017、2018、2019、2020、2022 年五届年度 SSL CA,是 2017–2022 年间该评选的绝对主角。
这串冠军年份本身就是一部 CA 治理史。 2017–2020 是 Symantec 事件后行业重塑期,2021 与 2023 由 Let's Encrypt 两次获得,2022 由 IdenTrust 获得,2024 与 2025 由 GlobalSign 获得。在"进步"这一评价维度上,行业的注意力和投资重点,与最近几年最严重的治理危机、以及自动化替代的推进节奏,是高度同步的。
13. SSL.com
所属:美国 · 成立:2010 年
业务定位:SSL 证书之外,特色在于客户端证书与 IoT 证书领域,以及CT 监控服务(提供证书透明度的实时告警,是 CT 监控器的商业化代表之一)。其目标客户包括大量需要管理大规模证书清单的企业。
市场地位:W3Techs 口径 0.1%。
14. Buypass
所属:挪威 · 成立:1998 年 · 性质:挪威国家 CA(挪威最大的受信 CA 之一,由挪威主要银行与运营商共同持股)
业务定位:免费 DV 证书 + PostSign 远程签名服务(挪威电子signature服务),2025 年起主推 ACME 以支撑自动化。作为国家级 CA 提供者的同时向公众提供免费服务,这一模式在欧洲并不罕见(如 Buypass、SwissSign 等)。
市场地位:在 W3Techs 口径中未进入前列(低于 0.1%),但在欧洲公共部门与公民数字服务中扮演独特角色。
15. Trustwave / SecCom Trust
所属:Trustwave 为美国 · 特殊状态:SecCom Trust 于 2024 年从原 Trustwave 分离独立运营,并保留原根证书名称以维持既有信任关系的连续性。
这一安排本身是 CA 行业的一个经典操作:根证书的名称绑定在根密钥上,而根密钥是历史信任的载体。因此 CA 业务在出售、拆分或重组时,必须保留根证书名称,否则所有既有信任链会同时失效。这也是为什么 CA 行业的并购几乎总是"换东家不换根"。
W3Techs 口径 0.2%(Secom Trust)。
16. Chunghwa Telecom(中华电信)
所属:中国台湾 · 定位:台湾地区的根 CA 运营者,为本地企业与公众提供 SSL 证书与电子签章服务,并承担台湾地区 PKI 体系中的重要角色。
当前状态:2025 年 8 月被 Chrome 移除信任。 需要说明的是,该处置的动因为政治与地缘因素,而非可核查的技术合规缺陷(与表 12 中 Entrust、TrustCor 等因吊销延误、所有权披露等合规问题被移除的案例性质不同),因此其触发条件、申诉渠道与恢复路径均不遵循常规的合规争议处理流程。本条目的市场状态标记为"Chrome 已移除信任"。
17. Netlock
所属:匈牙利
业务定位:区域性 CA,面向中东欧市场提供 DV/OV 证书。
当前状态:2025 年 8 月被 Chrome 移除信任。 与 Chunghwa 同月被移除,说明 2025 年下半年存在一轮集中处置,动因为政治与地缘因素。其市场地位在移除后已大幅萎缩。
18. TWCA(台灣網路資訊中心)
所属:中国台湾
业务定位:在台湾地区电子签章法体系下运营的重要 CA,提供自然人电子签章、行动签章与企业签章服务。与 Chunghwa 的差别在于定位:TWCA 侧重电子签章与身份信任服务,Chunghwa 侧重电信与商业 SSL 证书。
历史坐标:2023 年 Chrome 移除了数家中国根 CA 的信任——需要说明的是,这一轮处置属政治与地缘因素,而非技术合规问题(对比同表中的 Entrust、TrustCor 等因可核查的合规缺陷而被移除的案例)。它使中国本土 CA 在全球公开信任体系中的位置进一步边缘化。
19. CFCA(中国金融认证中心)
所属:中国 · 成立:2000 年 · 背景:由中国人民银行牵头组建
业务定位:中国金融行业电子认证的权威机构,为中国银行业的网上银行、支付系统、证券交易等提供数字证书服务,是中国金融行业 PKI 体系的核心。其客户是各大商业银行本身——这在 CA 行业中极为罕见,因为绝大多数 CA 的客户是终端企业或开发者。
技术进展:2024 年起推进国密改造,即在金融认证体系中推进 SM2/SM3/SM4 算法的落地,与中国 CA 行业的整体双轨制趋势一致。
20. 中国本土 CA 代表
中国工信部许可的 CA 机构共 55 家(截至 2023 年 9 月)。在 TOP 20 名单中,除 CFCA 外的中国本土代表包括:
表 23:中国本土主要 CA 机构概览
机构
定位与背景
备注
上海 CA
**1998 年成立,国内第一家专业第三方电子认证服务机构**;覆盖电子签名、身份认证、政务与企业应用
行业资历最深的一批本土 CA 之一
DigiCert 上海
DigiCert 在中国的本地化业务主体
与上文所述 Certum 无关,注意区分同名不同源情形
天威诚信
数字证书与电子签名服务,覆盖金融、政务、互联网
中国 CA 市场中资本与业务规模居前
数字认证(浙江CA)
浙江省内领先的电子认证服务提供者
区域性 CA 的代表
格尔软件
PKI 与密码应用产品,**已完成抗量子密码算法改造**
与吉大正元同属中国密码产业重要力量
亚数信息 TrustAsia
**2026 年发布企业级数字信任服务 CaaS 2.0**
面向企业级数字信任的托管服务方向
说明:上表为结构性介绍,非完整排名。中国 CA 市场的完整名单以工业和信息化部许可公告为准。
7.3 结构性趋势:整合、云厂商自营 CA、非营利替代、免费化
把上面二十家的个体情况放在一起,可以看到四条清晰的趋势线。
趋势一:整合。 Symantec → DigiCert 的降级与收购、Entrust 公开 CA 业务 → Sectigo、Trustwave → SecCom Trust 的分拆独立、ConnectWise 案的处置——公开 CA 业务在过去十年经历了密集的所有权重组。驱动力有三:合规风险定价、规模经济、以及高端市场的集中化。
趋势二:云厂商自营 CA。 Amazon Trust Services、Google Trust Services、Microsoft,以及 Azure 与 AWS 各自的 PKI 服务,共同构成了一个"云内建 CA"层。这一层的存在从根本上改变了 CA 市场的边界:当企业把应用托管到云上,PKI 就成了云平台的内置能力,而不再是需要单独采购的第三方服务。这解释了两个数据反差:Google Trust Services 在 CT 口径 16.7% 却在 W3Techs 口径低于 0.1%;Amazon 在 CT 口径 3.8%。
图 15:CA 市场在 2026 年的四层结构。四层结构中,第一层(基础信任锚)由极少数机构掌握,第二层被免费与云化双向挤压,第三层是生态型 CA 的新位置,第四层是区域与行业型 CA 的生存空间。(图源:W3Techs、Cloudflare Radar、CA/Browser Forum 会员公开信息)
趋势三:非营利替代。 Let's Encrypt 的成功证明了一件事:在 TLS 证书这个特定品类上,"免费 + 自动化 + 单一使命"的非营利模式可以击败商业模式。 支撑这一模式的三个条件缺一不可:单一且低成本的自动化签发流程(ACME)、足够大的赞助与志愿者支持、以及不与付费业务竞争的组织结构。这个模式不可能复制到需要高强度人工核验的 EV 或政府 PKI 领域——那里恰恰是商业 CA 存续下来的原因。
趋势四:免费化与价格结构的坍塌。 从 2015 年 Let's Encrypt 的 beta 公开开始,DV 证书的单价经历了断崖式下跌。结果是市场结构的重新洗牌:技术门槛下降,使得中低端供给严重过剩;而有效期收缩(47 天计划)与自动化要求则抬高了技术门槛。这个"双向挤压"的结果是:低价值 DV 供给严重过剩,高信任高价值供给(EV、政府、代码签名)反而因为合规成本上升而更加集中。
图 16:DV 与高信任证书的分化趋势。免费化不是"让所有人都用得更好",而是"让低价值层彻底商品化,同时让高价值层更加集中"。这两个方向对 CA 行业的从业者而言,指向的是完全相反的战略选择。(图源:W3Techs 份额数据与 CA/Browser Forum Baseline Requirements v2.3.1)
第八章 未来趋势
8.1 短生命周期证书与「无吊销」设计
短证书已经在从边缘方案变为规范方向。SC-081v3 通过后,2026 年 3 月 15 日起 200 天、2027 年起 100 天、2029 年起 47 天的时间表已被写入 Baseline Requirements。 与之配套的"≤7 天证书豁免吊销"(同于 2026-03-15 生效)构成了制度闭环。
短证书带来的影响是全方位的:
"吊销退居二线"已经不是抽象推演,而是有了全球最大 CA 的实际动作。 Let's Encrypt 分两步关闭了 OCSP:到期提醒邮件于 2025 年 6 月 4 日停止,OCSP 响应器于 2025 年 8 月 6 日关闭,此后签发的证书不再包含 OCSP URL,仅依赖 CRL 吊销信息。这是全球签发量最大的 CA 主动关闭实时状态查询服务的标志性事件——它用行动确认了那个从 2016 年 GlobalSign 误吊销事故就已浮现的判断:当签发可以廉价且频繁地重做时,实时吊销查询的成本收益比已经不再成立,**吊销机制正在从"核心保障"退居为"异常处理通道"**。
"无吊销"(no-revocation)设计在更激进的形态下,意味着"只签发、不撤销、依赖短有效期与多视角签发"。这在 IoT 与设备证书领域已经有实践基础——设备数量以百亿计,为每张设备证书维护吊销状态在成本上完全不可行。IoT 领域可能是短证书与无吊销设计最先规模化的场景。
8.2 后量子密码迁移(PQC)与 CA 的密钥轮换压力
后量子密码对 CA 体系的冲击,其严重性常被低估。CA 的产品本质上是"签发签名的密钥",而根 CA 的密钥必须在生成时选定算法,寿命以十年计。
8.2.1 两条赛道的分野:密钥交换已在生产,证书签名仍在原地
PQ 迁移不是"还没开始",而是已经一半落地了——但落地的恰好是更容易的那一半。 这是本章最重要的判断,也是理解 2026 年 PKI 现状的入口:握手时的会话密钥已经是 PQ 安全的,但认证这次握手的那张证书仍由经典算法签名。
A. 已大规模落地的一侧——PQ 密钥交换。 Chrome 124(2024 年 4 月)起在桌面端默认启用 X25519MLKEM768(codepoint 0x11EC,draft-kwiatkowski-tls-ecdhe-mlkem),Firefox 132 跟进。Cloudflare 自 2022 年起在边缘支持混合 KEM,先用 X25519Kyber768Draft00,2024 下半年切换至标准化版本 X25519MLKEM768。Cloudflare Radar 2026 年初的遥测显示,混合 PQ 密钥交换已覆盖全球 30% 以上的 TLS 1.3 握手;Cloudflare 网络上超过半数的人类流量已启用 PQ 密钥协商。产业侧,OpenSSL 3.5(2025-04)原生支持 ML-KEM 与 ML-DSA,无需再依赖 oqs-provider;AWS KMS、S3、CloudFront 已实现 ECDH + ML-KEM 混合密钥建立,AWS KMS 与 AWS Private CA 支持 ML-DSA。
B. 仍然原地的一侧——PQ 证书签名。 现状可以概括为一句反差极强的话:公共根 CA 签发的、能链入 Mozilla / Apple / Microsoft / Chrome 四大信任库的 ML-DSA 根证书数量为零。主流 CA 签发的仍然是 ECDSA P-256 / RSA-2048 签名的证书。CA/Browser Forum 服务器证书工作组有 PQC 提案追踪器,但尚无合并入 Baseline Requirements 的正式提案允许在公开信任证书中使用 ML-DSA。IETF 的 draft-ietf-tls-mldsa 截至 2026 年 5 月仍在工作组 last call 阶段,无主流浏览器默认协商 ML-DSA 服务器证书。体积代价极为具体:ML-DSA-65 公钥约 1,952 字节、签名约 3,293 字节,而 RSA-2048 两者均为 256 字节——这意味着约 7.6 倍与 12.9 倍的膨胀,直接冲击握手包体与证书链传输。截至 2026 年 9 月 30 日的准确状态是:尚无面向普通浏览器使用场景的、公信可用的 PQ 证书服务。
表 24:PQC 迁移在密钥交换与证书签名上的部署状态差异(截至 2026 年)
维度
密钥交换(Key Exchange)
证书签名(Certificate Signature)
生产部署状态
**已大规模部署**:Chrome 124(2024-04)起默认启用 X25519MLKEM768,Firefox 132 跟进;Cloudflare 自 2022 年起支持(2024 下半年切换至标准化版本)
**仍停留在经典算法**:主流 CA 签发的仍是 ECDSA P-256 / RSA-2048 签名证书
覆盖规模
Cloudflare Radar 2026 年初遥测显示已覆盖全球 **30%+ 的 TLS 1.3 握手**;Cloudflare 网络上超半数人类流量已启用 PQ 密钥协商
**能链入 Mozilla / Apple / Microsoft / Chrome 四大信任库的 ML-DSA 根证书数量为零**
标准化状态
已有正式标准(RFC 9881 为 ML-DSA 的 X.509 算法标识符、RFC 9909 为 SLH-DSA)
CA/Browser Forum 服务器证书工作组有 PQC 提案追踪器,但**尚无合并入 Baseline Requirements 的正式提案**允许在公开信任证书中使用 ML-DSA
IETF 进展
已完成
`draft-ietf-tls-mldsa` 截至 2026-05 仍在工作组 last call 阶段,无主流浏览器默认协商 ML-DSA 服务器证书
核心障碍
混合模式可平滑过渡(经典 + PQ 并行),客户端无感
**签名体积**:ML-DSA-65 公钥约 1,952 字节、签名约 3,293 字节(RSA-2048 分别为 256 / 256 字节)
这个不对称性的成因值得说清。 密钥交换之所以跑得快,是因为它可以走混合模式——客户端与服务器同时协商经典算法与 PQ 算法,攻击者必须攻破两者才算成功,因此可以逐个部署、无需等待全网就绪。证书签名则没有这条平滑路径:一张证书的签名算法是单一选择,客户端若不预先内置 ML-DSA 的验证实现,整张证书就完全无法验证。混合签名的思路(复合签名)虽在推进(draft-ietf-lamps-pq-composite-sigs-19),但代价是体积进一步翻倍。
C. 架构路径的分歧。 Merkle Tree Certificates(MTC) 是目前最受关注的替代架构思路,由 Google 与 Cloudflare 推进,核心是用 Merkle 树结构摊薄签名开销,避免把大体积的 PQ 签名逐张塞进传统 X.509 链。Cloudflare 正在自建 CA,目标 2027 年初提供 MTC 签发并申请 Chrome 根计划准入(目前尚未签发);Let's Encrypt 于 2026 年 6 月宣布以 MTC 作为其后量子 Web PKI 路径,目标 2026 年底 staging、2027 年生产就绪;Google 方面在 2026 年公开描述了以 MTC 作为"避免 PQ 签名带宽成本"的可行路径。
另一处容易被忽略但极有信号量的细节是:Chrome 设有独立的「Quantum-resistant Root Program」,处于单独的草案政策状态。 这说明 PQ 证书不是对现有根证书计划的简单扩展,而是一次新的准入通道建设——根证书计划本身的规则、审计方法与迁移路径都需要重新设计。IETF 侧的分工是:LAMPS(Limited Additional Mechanisms for PKIX and SMIME)负责 X.509 与 CMS 的 PQ 扩展,PLANTS 负责 Merkle Tree Certificates。相关标准编号为 RFC 9881(ML-DSA 的 X.509 算法标识符)、RFC 9909(SLH-DSA 的 X.509 算法标识符)、draft-ietf-lamps-pq-composite-sigs-19(复合签名)。
D. NIST 标准时间表。 2024 年 8 月 13 日发布 FIPS 203(ML-KEM,源自 CRYSTALS-Kyber)、FIPS 204(ML-DSA,源自 CRYSTALS-Dilithium)、FIPS 205(SLH-DSA,源自 SPHINCS+);2025 年 FIPS 206(FN-DSA,原 Falcon)定稿,HQC 选定为备份 KEM;2027 年 HQC 标准定稿,作为备份 KEM 方案;2030 年 112 位强度算法进入弃用阶段;2035 年完成全量迁移。
图 17:PQ 迁移的两条赛道分野。密钥交换已借混合模式在生产环境大规模落地,证书签名则仍停留在经典算法——根证书数量为零、BR 无正式提案、浏览器不默认协商。(图源:Cloudflare Radar 遥测、CA/Browser Forum 服务器证书工作组、IETF LAMPS/PLANTS 工作组、RFC 9881 / RFC 9909)
图 17:PQ 迁移不是"尚未开始",而是"已经一半落地、但落地的恰好是更容易的那一半"。密钥交换靠混合模式平滑推进,证书签名则因体积膨胀(ML-DSA-65 签名约为 RSA-2048 的 12.9 倍)而卡在信任准入环节;MTC 与独立的 Quantum-resistant Root Program 是两条正在施工的出路。
8.2.2 三重压力与迁移基础设施
图 18:后量子迁移对 CA 体系的三重压力。后量子迁移在 CA 体系中最难的部分不是"算法够不够安全",而是"根密钥的不可逆性"。(图源:NIST 后量子密码标准化进程、RFC 5280、CA/Browser Forum 根计划政策)
压力一:根密钥的不可逆性。 根 CA 密钥对在其生命周期内不可更换(更换即意味着根证书替换、信任重走准入流程、全部路径重建)。这意味着如果一个根 CA 在 2020 年代中期生成了采用传统 RSA-4096 的根密钥,而这个根将存活到 2035 年——那么在 2030 年前后,量子威胁的实质化将直接威胁这条信任链的根基。
应对方式目前只有两条,且都代价高昂:
压力二:体积膨胀。 后量子签名(如基于格或基于哈希的方案)的公钥与签名体积显著大于 RSA/ECDSA。这会传导为:CA 链的字节数增加、TLS 握手包变大(尤其影响 0-RTT 与移动网络)、CT 日志条目与 SCT 显著变大(SCT 内含签名)、证书链在 HTTP 头中的传输成本上升。CT 生态在 2021 年因 RFC 9162 搁浅(部分原因正是对体积与复杂度的敏感),在后量子时代将面临更严峻的取舍。
压力三:验证侧。 客户端(浏览器、SDK、嵌入式设备)的算法支持能力参差不齐。一个普遍的现实约束是:大量嵌入式与 IoT 设备的 PKI 栈更新周期以年计,甚至以十年计——这使得"服务端先切、客户端跟上"的分阶段路径成为必然,而分阶段本身要求 CA 体系支持同一张证书链上的多重签名。
产业侧已有响应。 中国厂商格尔软件与吉大正元已完成抗量子密码算法改造;Cloudflare 等在 2024 年前后进行了 PQ 握手实验。但从"实验"到"根 CA 生产部署"之间的距离,仍远大于多数人的直觉。 这是 CA 史上第一次面对"无法通过等待算法自然淘汰来解决"的迁移问题。
最后是本章与 8.1、8.4 的呼应,也是短证书运动最容易被忽略的长期价值。 证书有效期越短,PQC 迁移窗口越短、算法切换越容易。已经习惯了高频轮换证书的组织,在 PQ 证书到来时只需要更换算法,而不需要重建体系——这正是 crypto-agility(密码敏捷性)的价值。 一套在 47 天周期下反复演练过签发、部署、轮换的体系,在算法被迫更换时具备极强的韧性;反之,一家十年未换过证书、密钥管理流程已经僵化的 CA,在算法被迫更换时将面临一次完整的体系重建。因此,短证书运动并非只关乎吊销成本与运维效率——它是后量子时代唯一可行的迁移基础设施。
!配图 9|未来趋势:短生命周期证书、后量子迁移、身份化证书与韧性设计
三个层次面对的是三种不同的工程:终端实体数量庞大但可随时更换,中间 CA 受限于交叉签名的复杂度,而根 CA 的窗口最窄且不可逆。根密钥一旦生成即被锁定,无法续期,到期必须重新走四大根证书计划的准入流程——这决定了根级迁移必须提前十余年启动。
!配图 10|后量子迁移时间轴与三层迁移阻力
8.3 身份化证书与 ACME 之外的新协议
身份化(identity-focused)证书 的核心变化是:证书承载的不再只是"对某域名的控制权",而是"关于某个法律实体或自然人的一组可验证属性"。这一转变由两条线共同推动:
ACME 之外的新协议:
表 25:PKI 自动化协议概览
协议
定位
状态
ACME(RFC 8555)
自动化证书签发与续期的核心协议
2019 年标准化,广泛部署
ACME Renewal Information(ARI)
提前告知证书到期,支撑可靠续期
2025 年发布的扩展
ACME Renewal Info(draft-aaron-acme-ari)
上述扩展的草案源流
已并入扩展讨论
ACME Challenges 扩展
引入 DNS-PERSIST-01 等新型挑战(Ballot SC-088)
2025 年通过
EST(Enrollment over Secure Transport, RFC 7030)
面向设备的证书注册协议,用于与 CA 建立注册通道
标准化较早,在部分设备场景使用
SCMP(Simple Certificate Management Protocol)
简化证书管理流程的协议提案
标准化推进中,生态有限
CMPv2(RFC 4210)
工业界成熟的证书管理协议
长期用于企业级 PKI
SCEP
系统引导与初始证书配置
遗留但仍在嵌入式场景使用
说明:上表中的"状态"为截至 2026 年 10 月的一般情况,部分协议在不同生态中的采用程度差异较大。
其中 EST 与 SCEP 的定位特别值得注意。 它们不是为"网站签证书"设计的,而是为大规模设备/用户证书的注册与生命周期管理设计的——从 SIM 卡到企业 Wi-Fi 认证到 IoT 设备。当证书签发量从"亿"走向"千亿"时,ACME 这类为 Web 设计的协议未必是最优解。
MPIC(多视角签发佐证) 是把"多视角验证"从 CA 内部流程提升为协议层可验证证据的构想。它的逻辑是:如果签发决策由多个地理隔离的视角共同完成,那么 CA 应当能够向客户端证明"这个签发经过了 N 个独立视角的验证"。这一构想的价值在于:它把"信任 CA 的流程"部分转化为"信任可验证的证据",正是 CT 精神的延伸。 Let's Encrypt 早在 2020 年前后就实现了功能类似的机制。
8.4 韧性设计:多 CA 冗余与根证书生命周期治理
多 CA 冗余 是从事故中学到的直接教训。如果一个站点只依赖一个 CA,那么该 CA 的任何事故都会立即中断该站点的服务——Symantec 事件中被波及的数十万网站,本质上都是单点依赖的受害者。
冗余的层次包括:
根证书生命周期治理 是 Mozilla 政策中最能体现"制度化风险管理"的部分之一。其要点非常明确:TLS 根证书的密钥材料自生成起存续不超过 15 年,S/MIME 根不超过 18 年;到期即从信任库移除,不可续期,必须重新生成密钥对并重走四大根证书计划的准入流程。
图 19:Mozilla 根证书生命周期的硬约束。根证书生命周期的硬约束把"根信任的永久性"这个幻觉彻底消除了——「根是可以被更换的,只是更换的代价极高、周期极长。」 DigiNotar 案例证明这条路径可以在几天内走完(紧急移除),而 Mozilla 的 15 年政策则保证了在正常情况下根会「按计划」、可预期地被替换。(图源:Mozilla 根证书项目纳入标准与根密钥生命周期条款)
这个设计同时也是后量子迁移的关键基础设施。 根的定期、可预期更换,是后量子密钥能够在根层级引入的唯一现实通道——非周期的紧急更换无法承载从容的迁移。这或许是 8.2 的压力与 8.4 的对策之间最重要的连接点。
结语
回看这半个多世纪,CA 制度的历史可以概括为三次范式转换。
第一次:从密钥托管到公民掌握密钥(1991)。 PGP 让公钥密码从国家机密的专属品变成个人的工具。这在技术上只是"软件发行",在政治上却是"信任归属"的重新分配——信任不再天然属于国家机构。
第二次:从 CA 自证到第三方见证(2013–2018)。 CT 把"CA 签发了什么"从私有信息变成公共记录,DigiNotar 与 Symantec 的代价最终催生了这套机制。这是 CA 史上最重要的一次制度进步,因为它把验证成本从"信任 CA 的清白"转移到了"任何人都能独立核验"。
第三次:从长周期信任到高频短周期信任(2025–)。 SC-081v3 的 47 天时间表、7 天内豁免吊销、MPIC 与 ARI,指向一个 CA 行业的形态重估:签发从重资产人工服务变成高频 API 调用,吊销从核心机制退居为异常处理通道,验证从单点判断变成多视角佐证。
这三次转换有一个共同的内在逻辑:信任的载体在不断下沉。 第一次让密钥下沉到个人;第二次让签发记录下沉到公共日志;第三次让验证动作下沉到持续、自动、分布式的执行网络。每一次下沉,都让少数机构的裁量空间缩小一分。
而这也正是 CA 制度最值得警惕的一面。 47 天证书、自动化签发、多视角验证、CT 全量强制,每一项都显著提升了系统效率与安全性,但每一项同时也把 CA 从"有判断力的专业机构"变成了"高速运转的自动化系统"。事故的形态随之改变:从人的错误转向代码的缺陷,从单一环节的失败转向规模放大效应。2020 年 Let's Encrypt 的 CAA 复检缺陷——一个只需一行就能避免的逻辑错误,在几周内影响了数百万张全球网站——正是这个新形态的第一次完整示警。
因此,CA 史给出的最终判断,不在于"信任可以去哪里获得",而在于"信任的检查成本必须持续下降"。 只要验证一次签发是否正当的成本,仍高于验证一门密码学是否安全的速度,CA 体系就会不断生产出远超其设计容量的风险。
这场竞赛尚未结束。 后量子迁移的根密钥轮换压力尚未有成熟的产业方案,身份化证书的信任模型尚在 eIDAS 2 的实施条例中逐条落地,而 47 天时代的第一批事故尚未完全展开。CA 制度的历史不是一部已经结束的编年史,而是一部仍在加速的实验记录。
附录 A 术语中英对照表
English
中文
简明释义
Certificate Authority (CA)
证书认证机构 / 证书颁发机构
负责签发、担保并管理数字证书的受信任实体
Certificate
数字证书
将公钥与身份信息绑定并由 CA 签名的电子凭证
Public Key Infrastructure (PKI)
公钥基础设施
由 CA、证书、密钥、吊销与策略构成的整体信任体系
Public Key Cryptography (PKC)
公钥密码
基于非对称密钥对的密码学体系
Diffie-Hellman Key Exchange
DH 密钥交换
1976 年提出的无需预共享密钥的会话密钥协商方法
RSA
RSA 算法
1977 年 Rivest-Shamir-Adleman 提出的基于大整数分解的公钥算法
Digital Signature
数字签名
用私钥对消息摘要签名、可用公钥验证的完整性证明
Trust Anchor
信任锚
信任链的起点,通常是一份自签根证书
Root CA
根证书颁发机构
自签顶层 CA,其根密钥直接嵌入终端信任库
Intermediate CA
中间证书颁发机构
位于根 CA 与终端实体之间,签发下级证书的 CA
Subordinate CA
下属 CA
由上级 CA 签发证书并受其约束的 CA
Cross-Signing
交叉签名
由一个根为另一个根签名,以维持过渡期信任的机制
Self-Signed Certificate
自签名证书
由主体自身签发、用于建立信任锚的证书
X.509
X.509 标准
由 ITU-T 制定的证书与目录信息结构国际标准
X.509 v3
X.509 第三版
1996 年发布、引入扩展机制的关键版本
Extension
证书扩展
在 X.509 基本结构外承载附加语义的字段机制
Subject Alternative Name (SAN)
主体备用名称
承载域名、IP、邮箱等身份信息的扩展
Common Name (CN)
通用名称
证书主体中的名称字段,已被弃用于域名标识
Key Usage
密钥用途
声明密钥可用于签名、加密等哪些操作
Extended Key Usage (EKU)
扩展密钥用途
声明证书适用于服务器认证、代码签名等场景
Name Constraints
名称约束
限制某 CA 仅可为特定名称签发证书的扩展
Certificate Policy (CP)
证书策略
声明签发规则与用途的策略 OID,法律效力判定的入口
Certificate Revocation List (CRL)
证书吊销列表
列出已吊销证书的定期发布签名列表
Online Certificate Status Protocol (OCSP)
在线证书状态协议
实时查询证书吊销状态的请求响应协议
OCSP Stapling
OCSP 装订
服务器预取并随证书一并发送吊销状态
Revocation
吊销
在证书有效期内提前终止其信任状态
Certificate Transparency (CT)
证书透明度
将证书签发记录于公开只增日志的可验证信任机制
Signed Certificate Timestamp (SCT)
签名证书时间戳
CT 日志为证书签发的可验证时间证明
CT Log
CT 日志
只可追加的公开证书签发记录日志
CT Monitor
CT 监控器
持续抓取 CT 日志并检出异常签发的程序
CT Auditor
CT 审计器
检查 CT 日志是否遵守只增不改承诺的角色
Pre-Certificate
预证书
为 CT 记录预留专用签发时间戳空间的中间证书
Merkle Tree
默克尔树
支持高效包含证明与一致性证明的哈希树结构
Inclusion Proof
包含证明
证明某条目确实存在于 CT 日志中的哈希路径
Tree Hash
树哈希
CT 日志的滚动根哈希值
Transparency Log
透明度日志
CT 的核心构件,记录所有被提交的证书签发
Certificate Revocation List (CRL) Distribution Point
CRL 分发点
证书中指向吊销信息获取位置的扩展
Authority Information Access (AIA)
授权信息访问
证书中指向 CA 信息与 OCSP 服务的扩展
Subject Key Identifier
主体密钥标识符
用于链构建的密钥指纹字段
Authority Key Identifier
授权密钥标识符
标识签发者公钥的字段
Domain Validation (DV)
域名验证
仅验证域名控制权的最基础验证等级
Organization Validation (OV)
组织验证
验证域名控制权并核验申请法人实体存在性
Extended Validation (EV)
扩展验证
在 OV 基础上加深度人工核验的最高验证等级
Certificate Policy OID
证书策略对象标识符
标识证书所属签发政策与用途的唯一编号
Public Key Pinning
公钥固定
客户端硬编码信任特定公钥或 SPKI 集合的机制
CAA
证书颁发机构授权
域名在 DNS 中声明的"允许哪些 CA 签发"的记录
Domain Validation Method
域名验证方法
CA/B Forum 定义的域名控制权证明方式集合
ACME
自动证书管理环境
自动化证书签发与续期的协议,2019 年标准化为 RFC 8555
ACME Challenge
ACME 质询
客户端证明域名控制权的具体方式
DNS-01 Challenge
DNS 质询
通过在 DNS 中添加 TXT 记录证明控制权的质询类型
DNS-PERSIST-01
常驻 DNS 质询
2025 年引入的、绑定 ACME 账户的常驻 TXT 记录挑战
ARI
证书续期信息
ACME 扩展,用于提前告知证书即将到期
MPIC
多视角签发佐证
把多视角验证结果作为可验证证据提供给客户端的构想
Multi-Perspective Issuance
多视角签发
要求从多个地理隔离网络视角独立完成验证的签发模式
MPIV
多视角签发与验证
多视角签发加签发后持续监控的完整机制
SSL
安全套接字层
Netscape 时代确立的传输层安全协议,后演化为 TLS
TLS
传输层安全
SSL 的标准化继任者,现行主流版本为 1.3
TLS Handshake
TLS 握手
建立会话密钥并完成服务器身份认证的过程
0-RTT
零往返时延
TLS 1.3 早期数据机制,速度优先但有重放风险
AEAD
带关联数据的认证加密
TLS 1.2 起主流的加密与完整性保护组合方式
POODLE
填充预言机漏洞
2014 年曝光的 SSL 3.0 CBC 填充攻击
CA/Browser Forum
CA/浏览器论坛
由 CA 与根证书计划组成的联合治理组织,2011 年成立
Baseline Requirements (BR)
基线要求
CA/Browser Forum 制定并强制执行的全球签发行为规范
Root Program
根证书计划
浏览器或操作系统厂商的根证书纳入与审计机制
Root Store
根证书存储
操作系统或浏览器内置的受信任根集合
WebTrust for CAs
CA 的 WebTrust 认证
针对 CA 的第三方审计认证标准
ETSI EN 319 411
合格信任服务提供者要求
欧洲电信标准协会的合格 TSP 电子签名服务要求
Certificate Transparency Policy
CT 政策
浏览器对 CT 提交与日志信任的具体要求规则
HSM
硬件安全模块
用于安全存储 CA 私钥并执行签名操作的加密设备
CVC
智能卡验证证书
欧盟体系下的身份与签名证书类型
QES
合格电子签名
经合格性评估、在欧盟具有等同手写签名效力的电子签名
eIDAS
电子身份与信任服务条例
欧盟 Regulation (EU) No 910/2014 及其 2.0 版本
EUDI Wallet
欧盟数字身份钱包
eIDAS 2 引入的数字化身份凭证钱包体系
TSP
信任服务提供者
提供电子签名、时间戳、网页认证等信任服务的主体
EUTL
欧盟信任列表
欧盟官方发布的合格信任服务提供方公开清单
UETA
统一电子交易法
美国各州关于电子交易与电子签名的法律范本
ESIGN Act
电子签名与全球商业安全法
美国 2000 年联邦电子签名立法
IT Act
信息技术法
印度 2000 年综合信息立法,含 CA 许可与 RCAI 条款
CCA
认证授权控制器
印度依 IT Act 第 17 条设立的 CA 许可与监管机构
RCAI
印度根认证机构
依 IT Act 第 18(b) 条设立,为持牌 CA 签署公钥的根机构
DSC
数字签名证书
印度体系中面向政府与法定用途的证书链
Commercial CA
商业 CA
以营利为目的、面向公开市场提供签发服务的 CA
Enterprise CA
企业 CA
仅服务于本组织内部 PKI 的自建 CA
Trust List
信任列表
列出受信主体的公开注册表,如 EU Trusted List
Public Suffix List
公共后缀列表
界定公共后缀边界的域名规则清单
Wildcard Certificate
通配符证书
覆盖同一层级多个子域名的证书
Short-Lived Certificate
短期证书
有效期在数天至数周量级的证书
Key Rollover
密钥轮换
定期更换 CA 密钥并重新建立信任的过程
Post-Quantum Cryptography (PQC)
后量子密码
抵抗量子计算机攻击的新型公钥密码体系
Quantum-Safe
量子安全
具备抵抗量子计算攻击能力的算法或系统属性
Code Signing
代码签名
用数字签名保证软件代码完整性与来源真实性的机制
Authenticode
Authenticode 代码签名
微软自 IE 3.0 起推行的代码签名体系
Object Signing
对象签名
Netscape 于 1990 年代中期推出的 Java Applet 权限签名机制
S/MIME
安全多用途互联网邮件扩展
邮件层安全标准,含证书与签名规范
TLS BR
TLS 基线要求
CA/Browser Forum 面向 TLS 服务器证书的基线要求文件
Audit
审计
由第三方对 CA 流程与记录进行合规检查的机制
Incident Reporting
事件报告
CA 向监管与行业组织报告安全事件的义务
Certificate Chain
证书链
由终端证书逐级指向根证书的有序序列
Path Validation
路径验证
依赖方验证证书链有效性与约束的过程
附录 B 关键事件年表
年份
事件
影响
1976
Diffie-Hellman 密钥交换论文发表
公钥密码思想确立,密钥分配难题获解
1977
RSA 算法公布
提供可验证的数字签名基础,CA 制度的技术前提
1985
Neal Koblitz 提出椭圆曲线公钥密码
ECC 谱系起点,后成为 TLS 主流算法之一
1987
Victor Miller 独立提出椭圆曲线密码
印证 ECC 的独立可发现性
1986
RSA Data Security 开始开发发布面向终端用户的 PKI 产品与工具包
VeriSign 官方史称之为「VeriSign 诞生前 9 年」
1988
X.509 标准制定(ITU-T)
证书结构与信任链的标准化起点
1991
PGP 1.0 发布
公钥密码社会化,挑战政府密钥托管政策
1991
DSA 发布(Digital Signature Standard)
与 RSA 并列的长期签名算法选项
1991
RSA Data Security 开始制定 PKCS 系列标准
公钥密码走向标准化的关键一步
1994
RSA 与 Netscape 合作,将整套 PKI 软件集成进第一版 Netscape Navigator
Web PKI 从论文走向产品
1994-11
Netscape 发布 SSL 1.0
浏览器信任模型确立,"内置根证书列表"成为权力结构
1995-04
**VeriSign 从 RSA Data Security 分拆为独立公司**
CA 商业化浪潮的起点;Jim Bidzos 主导孵化
1995
SSL 2.0 发布;后因缺陷严重被捐赠社区
私有协议缺陷向公共标准组织移交的原型
1995-06
VeriSign 推出 Secure Server ID 与面向企业的 Digital ID
首批在线销售的商业证书产品
1996-01
VeriSign 在旧金山 RSA 大会首次公开演示首个在线数字证书签发系统
在线签发模式的确立
1996
SSL 3.0 发布
首个公开 SSL 规范,确立握手框架
1996
X.509 v3 发布
扩展机制确立,支撑此后所有 PKI 演进
1996
微软随 IE 3.0 推出 Authenticode;VeriSign 获微软代码签名 Digital ID 业务
代码签名商业化起点
1996
GlobalSign 成立(源自 1995 年业务起步)
全品类 CA 与 eIDAS 合格 TSP 的代表
1998-01
VeriSign 在纳斯达克 IPO(代码 VRSN)
**第一家上市的 CA**;此后十年是 CA 行业的黄金期
1999-12
VeriSign 以约 5.75 亿美元股票收购南非 Thawte
Thawte 成为 VeriSign 品牌资产,2010 年随安全业务转入 Symantec
2000-03
VeriSign 以 210 亿美元股票收购 Network Solutions
成为 .com/.net 注册局,商业版图急速扩张
2010
VeriSign 将安全业务(含 Thawte、GeoTrust)出售给 Symantec
Thawte、GeoTrust、RapidSSL 进入 Symantec 品牌体系,埋下 2018 年信任撤退的伏笔
1996
Entrust 创立
政企 PKI 与 HSM 领域的重要玩家
1997
GoDaddy 成立
SMB 域名+证书捆绑销售模式的代表
1997
IdenTrust 由荷兰 KPN、ING 等共同创立
荷兰国家级信任重建方案的载体
1998
上海 CA 成立
中国第一家专业第三方电子认证服务机构
1998
Comodo 成立
覆盖全价格带的 CA,2019 年启用 Sectigo 品牌
1998
Buypass 成立
挪威国家 CA,提供免费 DV 与 PostSign 服务
1999
TLS 1.0(RFC 2246)
SSL 标准化为 TLS
2000
中华人民共和国电子签名法通过
中国 CA 许可制度的法律基础
2000
印度信息技术法(IT Act 2000)通过
第 17 条授权 CCA,第 18(b) 条设立 RCAI
2000
CFCA 成立(央行牵头)
中国金融行业电子认证权威
2000
ESIGN Act(美国联邦)通过
电子签名法律效力的联邦框架
2001
AES 成为对称加密标准
取代 DES/3DES 主流地位
2002
RFC 3280 发布
PKI 首次成文规范
2003
DigiCert 取得 Symantec 证书业务
代码签名领导者的形成起点
2004-08-28
中国电子签名法通过(2005-04-01 施行)
确立电子认证服务许可制
2005
SHA-1 碰撞构造研究取得突破
加速签名算法淘汰进程
2006
TLS 1.1(RFC 4346)
AEAD 支持引入
2007
CA/B Forum 制定 EV 代码签名规范
代码签名进入高信任阶段
2008
RFC 5280(PKIX)发布
现行 PKI 核心规范
2008
TLS 1.2(RFC 5246)
长期主力版本
2008
X.509 转换 / 根信任计划制度化
Chrome、Mozilla 等根证书计划成型
2009
中国《电子认证服务管理办法》施行
工信部监管框架建立
2010
SSL.com 成立
客户端证书、IoT 证书与 CT 监控特色
2010
Symantec 收购 VeriSign 安全业务
获得 GeoTrust、Thawte、RapidSSL 品牌
2011
DigiNotar 被攻破,荷兰政府移除其根证书
欧盟首个被吊销的信任根;信任体系首次系统性崩塌
2011
CA/Browser Forum 成立
行业自律联合治理体系建立
2011-09
Google 启动 CT 框架工作
透明机制的理论起点
2012
CT 以代号「Sunlight」提交 IETF 草案
标准化起步
2013
Google 上线首个 CT 日志
CT 落地生产环境
2013-03
Chrome 推出 EV 证书白名单机制
EV 时代的高信任标识体系
2013-04
EV 证书引入「地理验证」要求(2019 年正式纳入 BR)
应对海外空壳公司滥用
2013-05
ISRG 注册成立(Aas、Rescorla、Eckersley、Halderman 发起)
非营利 CA 模式的组织基础
2013-06
RFC 6962 发布
CT 成为正式标准
2013-09
DigiCert 成为首家实现 CT 的 CA
产业侧首批跟进
2013-12-03
某商业设备被入侵后用 ANSSI 中间 CA 私钥为 Google 域名签发伪造证书
Google 将 ANSSI 限制在法语区顶级域名(.fr/.gp/.gf/.mq/.re/.yt/.pm/.bl/.mf/.wf/.pf/.nc/.tf);「范围限制」手法的典型运用
2013-09
法国 ANSSI 所属 CA 误签发 Google 域名证书
政府 CA 人为错误型事故
2014-07
印度 NIC 签发系统被攻破(4 张域名证书)
Google 采取"范围限制而非移除"的处置
2014-11
Let's Encrypt 项目宣布
自动化免费证书模式启动
2015-01-28
ACME 草案提交 IETF
自动化协议标准化起步
2015-03
CNNIC 授权的 MCS Holdings 误签发 Google 域名证书
私钥未入 HSM 的密钥管理失效
2015-04-01
Google 不再认可 CNNIC Root 与 EV CA
地缘政治影响 CA 治理的标志性案例
2015
Chrome 对非 EV 证书撤除绿色安全标识
EV 高信任标识开始退场
2015
Chrome 要求新签发 EV 证书携带 SCT
CT 强制化第一步
2015-06
187 张未经域名所有者知情的证书被签发
促成对 Symantec 全量证书的 SCT 要求
2015-09
Symantec 承认 Thawte 误签发 google.com 证书(3 万张量级)
史上最大信任撤退的起点
2015-09-14
Let's Encrypt 签发首张证书
非营利 CA 正式投产
2015-10-31
Google 公布 CT 调查中期结果
推动 Symantec 系证书分阶段限制
2015-12
Let's Encrypt beta 公开
DV 证书免费化冲击价格结构
2016-01-01
行业禁止签发 SHA-1 证书的期限生效
WoSign 倒签以此为规避目标
2016-04-12
Let's Encrypt 正式发布
DV 证书规模化免费化
2016-06
Chrome 要求 Symantec 全部新证书携带 SCT
CT 强制化第二步
2016-08-17
GitHub 安全团队发现 WoSign 未授权签发
中等规模 CA 影响数十万网站的开始
2016-09-30
Apple 宣布不再信任 WoSign
多厂商协同处置启动
2016-10-21
Chrome 拒绝信任此后的 WoSign/StartCom 证书
处置时间线确立
2016-10-24
Mozilla 移除 WoSign 信任
Firefox 侧同步处置
2016-10
Comodo 自动化流程使用 OCR 读取邮件内容判定域名验证通过
攻击者据此为不属于自己的域名取得服务器证书;不可靠组件进入自动化流水线的典型反例
2016-10
GlobalSign 误吊销连接两个根的交叉证书
Wikipedia、Dropbox、FT、The Guardian 等大量站点信任链断裂,用户需手动清除浏览器 CRL 缓存,影响持续 1–4 天;吊销机制自身成为故障源
2017-03
Google 公布 Symantec 调查最终结果与分阶段 distrust 计划
信任撤退正式展开
2017-06
EV 代码签名私钥强制硬件化(FIPS 140-2 / CC EAL4+)
代码签名安全基线提升
2017-07
Chrome 61 移除 WoSign 过渡白名单
全面不信任(Stable 约 2017 年 9 月中)
2017-07 中
Symantec 同意由 DigiCert 作为 SubCA 代为签发
降级为下属 CA
2017-07 中
DigiCert 收购 Symantec Web 安全业务
品牌与根资产的重组
2018-03
Let's Encrypt 支持 ACME v2 与通配符证书
自动化能力大幅扩展
2018-04
Chrome 68 起对所有公开信任证书强制 CT
CT 强制化第三步,全量落地
2018-04-17
Chrome 66 对 2016-06-01 前签发的 Symantec 证书报错
惩罚轨道执行
2018-04
Cloudflare 上线 Nimbus CT 日志
CT 生态多中心化起步
2018-05
1024 位 RSA 与 SHA-1 淘汰时间表推进
算法迁移的强制执行
2018-08-01
CA/B Forum 废除域名验证方法 1 与 5
邮件类验证退出,自动验证成为主流
2018-10
Chrome 70 完全取消 Symantec 信任
史上最大信任撤退完成
2018
Apple 在 iOS 12 / macOS 10.14 的 Safari 移除地址栏 EV 公司名;Chrome 69 移除绿色地址栏与「Secure」标签
EV 标识退出地址栏这一唯一有效展示位
2019
CA/B Forum 宣布 EV 证书地理验证要求
身份核验的深度化
2019-09 / 2019-10
Chrome 77 将 EV 标识移入 Page Info 面板;Firefox 70 移入站点信息面板
EV 可见性溢价在主流浏览器中彻底取消
2019-03
ACME 正式标准化为 RFC 8555
自动化签发成为标准协议
2019-05
Let's Encrypt 上线 Oak CT 日志
2020-02 进入 Chrome/Apple 批准列表
2020-01-01
CA/B Forum 全面禁止签发 SHA-1 签名证书
算法规退完成
2020-02
Let's Encrypt 突破第 10 亿张证书里程碑
非营利 CA 规模标志
2020-02-27
Let's Encrypt 签发第 10 亿张证书
非营利 CA 规模里程碑
2020-02-29
Let's Encrypt CAA 复检缺陷暴露
自动化时代规模放大效应示警
2020-03-04
LE 分批吊销受影响证书
最终约 170 万张被吊销
2020-08
印度 CCA 发布 SSL 签发指南 v1.4
本地要求严于全球基线
2021
DigiCert 被 Thoma Bravo 收购
公开 CA 业务所有权重组
2021
Google 内部研究显示仅 11% 参与者正确理解挂锁图标含义
用户研究对信任标识有效性的直接否定
2021-12
RFC 9162(CT 2.0)发布
支持 Ed25519 与包含证明,业界未采纳
2022
TrustCor 因未披露所有权结构被移除信任
披露义务成为硬性条件
2022-02
Google 取消"必须含自家 CT 日志 SCT"要求
CT 生态从单中心走向多中心
2022-09
Mozilla Firefox 91+ 扩展以强制 CT 政策为前提
浏览器侧 CT 依赖加深
2023-06
ConnectWise CA 事故(Comodo 旗下品牌、13 个根)
品牌与运营实体的分离风险显性化
2023-09
工信部许可 CA 机构共 55 家
中国 CA 许可规模快照
2023
Chrome 117 用中性「调节(tune)」图标取代挂锁
浏览器视觉语言去信任分级化
2024-04-11
eIDAS 2(Regulation (EU) 2024/1183)通过
引入 EUDI Wallet
2024-07
Chrome 因 CA 域名验证错误移除 Entrust 信任
常态化不信任处置
2024-09-02
工信部发布《电子认证服务管理办法(征求意见稿)》
注册资本提至 7000 万元;禁止委托受理与签发;部省联动
2024-08-13
NIST 发布 FIPS 203(ML-KEM)、FIPS 204(ML-DSA)、FIPS 205(SLH-DSA)
后量子标准落地,为 CA 迁移提供终点线
2024-10-03
征求意见稿意见反馈截止
公众参与完成
2024-11-01
《电子政务电子认证服务管理办法》施行
政务领域叠加密码资质要求
2024-12-04
eIDAS 2 五项实施条例通过
钱包完整性、协议与接口等规范落地
2024-12
Entrust 宣布将 CA 业务出售给 Sectigo
公开 CA 业务整合加速
2025-02
Sectigo 完成对 Entrust 公开 CA 业务的收购
Entrust 退出公开 CA 竞争
2025-06-04 / 2025-08-06
Let's Encrypt 停止到期邮件、关闭 OCSP 响应器,证书不再含 OCSP URL
吊销机制退位的真实案例;短证书时代的典型取舍
2025-01
ISRG 完成 ACME v2 相关标准化(关联 2019 年 RFC 8555)
自动化生态持续演进
2025-02
Firefox 135 桌面版要求 Mozilla 根计划内 CA 全量 CT
CT 覆盖面扩展至 Firefox 全量用户
2025-03-15
SC-081v3 第一阶段生效:200 天有效期上限
有效期收缩运动启动
2025-04-04 至 04-11
Ballot SC-081v3 表决通过(CA 方 25 赞成 0 反对 5 弃权,四家根计划全赞成)
47 天时代制度化
2025-05-16
Baseline Requirements v2.1.5 生效
2025-07-30
eIDAS 2 七项新实施条例通过
2025-08-20 生效
2025-08
Chunghwa Telecom 与 Netlock 被 Chrome 移除信任
常态化处置的又一实例
2025-09-15
Ballot SC-067 生效:域名验证与 CAA 须从 2 个地理隔离视角执行
多视角签发制度化
2025-10-01
W3Techs 份额快照:LE 63.5%、GlobalSign 23.2%
收缩前夜的基线数据
2025-10-09
Ballot SC-088 通过:引入 DNS-PERSIST-01 挑战
自动化续期摩擦降低
2025-12-16
Baseline Requirements v2.2.1
2026-02
Let's Encrypt 累计签发超 22 亿张
规模里程碑
2026-03-15
SC-081v3 第二阶段:100 天上限;≤7 天证书豁免吊销;多视角增至 3 个
短证书时代核心制度落地
2026-04-04
Baseline Requirements v2.3.1
现行版本
2026-06-15
多视角要求增至 4 个
持续加压
2026-09-29
印度 CCA 持牌 CA 名单 23 家
印度 CA 许可规模快照
2026-10-04
W3Techs 份额快照:LE 67.4%、GlobalSign 21.9%
最新份额数据
2026-12-15
多视角要求增至 5 个
制度目标达成
附录 C 参考来源
C.1 标准与规范
来源
URL
说明
RFC 2246 — TLS 1.0
<https://www.rfc-editor.org/rfc/rfc2246>
TLS 1.0 协议规范
RFC 4346 — TLS 1.1
<https://www.rfc-editor.org/rfc/rfc4346>
TLS 1.1 协议规范
RFC 5246 — TLS 1.2
<https://www.rfc-editor.org/rfc/rfc5246>
TLS 1.2 协议规范
RFC 8446 — TLS 1.3
<https://www.rfc-editor.org/rfc/rfc8446>
TLS 1.3 协议规范
RFC 6962 — Certificate Transparency
<https://www.rfc-editor.org/rfc/rfc6962>
CT 核心标准
RFC 9162 — CT 2.0
<https://www.rfc-editor.org/rfc/rfc9162>
CT 扩展标准(业界未广泛采纳)
RFC 8555 — ACME
<https://www.rfc-editor.org/rfc/rfc8555>
ACME 自动化签发标准
RFC 5280 — PKIX
<https://www.rfc-editor.org/rfc/rfc5280>
PKI 核心规范
RFC 7030 — EST
<https://www.rfc-editor.org/rfc/rfc7030>
设备证书注册协议
RFC 4210 — CMP
<https://www.rfc-editor.org/rfc/rfc4210>
证书管理协议
IANA TLS Parameters
<https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml>
TLS 套件与密码套件登记表
Chrome 批准的 CT 日志列表
<https://www.gstatic.com/ct/log_list/v3/log_list.json>
浏览器认可的 CT 日志清单(动态更新)
CAB Forum Baseline Requirements
<https://cabforum.org/working-groups/server/>
BR 全文与修订历史;现行 v2.3.1(2026-10-04)
CAB Forum 表决记录
<https://cabforum.org/ballots/>
SC-081v3、SC-067、SC-088 等表决的官方文本与计票
Mozilla 根证书项目
<https://wiki.mozilla.org/CA:Inclusion_Criteria>
Mozilla 根证书纳入标准与根密钥生命周期政策
Chrome 根证书计划
<https://chromerootprogram.google/>
Google 根证书纳入、审计与移除政策
C.2 官方公告与政府文件
来源
URL
说明
欧盟 eIDAS 法规
<https://eur-lex.europa.eu/eli/reg/2014/910/oj>
Regulation (EU) No 910/2014 原文
欧盟 eIDAS 2 法规
<https://eur-lex.europa.eu/eli/reg/2024/1183/oj>
Regulation (EU) 2024/1183 原文
欧盟实施条例 2024/2979 等
<https://eur-lex.europa.eu/>
检索 EUDI Wallet 相关五项与七项实施条例
EU Trusted List
<https://ec.europa.eu/tools/lists/eutl>
官方合格信任服务提供方清单
印度 IT Act 2000 与 CCA
<https://www.indiacode.nic.in/>
印度 IT Act 2000 全文(含第 17、18(b)、3 条)
印度 CCA 持牌 CA 名单
<https://www.cca.gov.in/>
截至 2026-09-29 共 23 家持牌机构
中国《电子签名法》
<http://www.npc.gov.cn/>
全国人大法律文本库,检索"电子签名法"
中国《电子认证服务管理办法》
<https://www.miit.gov.cn/>
工业和信息化部规章与征求意见稿(2024-09-02 发布)
CFCA
<https://www.cfca.com.cn/>
中国金融认证中心
Google Security Blog
<https://security.googleblog.com/>
CT 公告、Symantec 调查、EV 标识调整等;本文引用条目包括 2015-10-31 关于 CT 调查的公告与 2016 年 Symantec 证书处置公告
Chrome Root Program 变更公告
<https://chromerootprogram.google/>
根证书移除公告(Chunghwa、Netlock、Entrust 等)
Mozilla Security Blog
<https://blog.mozilla.org/security/>
2025-02 起全量 CT 要求的说明
C.3 行业与研究机构
来源
URL
说明
W3Techs — SSL Certificate Authority Market Share
<https://www.w3techs.com/ssl-certificate-issuers>
口径 A:启用 HTTPS 的公开网站扫描
W3Techs — Web Technologies of the Year
<https://www.w3techs.com/technologies/>
年度 SSL CA 评选与历年冠军
Cloudflare Radar — Certificates
<https://radar.cloudflare.com/ssl>
口径 B:CT 日志可见证书量与 CA 份额
certificate-transparency.org
<https://www.certificate-transparency.org/>
CT 生态社区资源与监控器目录
Let's Encrypt 文档
<https://letsencrypt.org/docs/>
ACME 集成、证书生命周期与吊销政策
Let's Encrypt CAA 问题说明
<https://letsencrypt.org/caaproblem/>
2020 年 CAA 缺陷的受影响序列号全量清单
ISRG 站点
<https://letsencrypt.org/about/>
组织背景、赞助方与里程碑数据
BleepingComputer
<https://www.bleepingcomputer.com/>
2018 年前后关于 Symantec 系证书占比的报道
GitHub Security Lab
<https://github.blog/>
2016-08-17 披露 WoSign 事件的原始公告
RiskIQ
<https://www.riskiq.com/>
2017 年前后关于 WoSign/StartCom 影响面(762,649 站点)的估算
CAB Forum 会员与文档
<https://cabforum.org/>
治理结构、Baseline Requirements 与表决档案
附录 D 数据口径与局限说明
一、市场份额的三种口径不可混用。 本文第七章引用的两组数据来自不同统计方法:W3Techs 口径统计"启用 HTTPS 的公开网站中某 CA 证书的存量占比",Cloudflare Radar 口径统计"CT 日志中可见的签发量占比"。**Google Trust Services 在两者中分别为低于 0.1% 与 16.7%**,差异达两个数量级,原因是其签发主要面向云内部服务与开发者生态。凡引用本文数据时,必须连同口径与统计时点一并引用。
二、扫描类数据存在结构性偏差。 W3Techs 的扫描覆盖范围决定了:未启用 HTTPS 的站点、内部域名、非公开服务、纯 API 服务均不计入;短生命周期证书因续期频繁而在扫描中的存在时间占比被低估,Cloudflare Radar 口径则相反——它按签发计数,短期证书被显著放大。因此在 47 天时代,两个口径的差距预计会进一步扩大,而非收敛。
三、历史占比数字是"量级感"而非精确值。 关于 Symantec 系证书约占全网有效证书 30%、或"每 6 张 SSL 证书有 1 张来自 Symantec"的表述,出自 2017–2018 年的媒体报道,基于当时的扫描与统计方法。本文将其作为影响量级的参考,不作为可跨年份比较的精确指标。 影响面估算(如 RiskIQ 的 762,649 个站点)同样受限于估算方法。
四、CT 口径的覆盖也有边界。 Cloudflare Radar 的 CT 数据仅统计已提交到受信任 CT 日志的证书。所有公开信任 TLS 证书自 Chrome 68(2018-04)起已强制 CT,故对公开信任市场覆盖充分;但非公开信任 CA(企业自建、政务 PKI)签发的证书不进入该统计,且历史上少数豁免 CT 的签发亦不在其中。
五、历史事件规模数字为事后统计。 DigiNotar 影响的网站数、Symantec 涉及的证书数、WoSign 的 762,649 站点估算、Let's Encrypt 的 3,048,289 张受影响证书与最终约 170 万张吊销量,均为事件调查或事后统计的产物。其中精确数字(如 1,706,505 与 445 张的分项)来自 LE 官方公告,其余为业界估算。
六、机构沿革中的年份以官方记载为准。 VeriSign 的成立年份不存在需要并列的分歧:据 VeriSign 官方公司史,其于 1995 年 4 月自 RSA Data Security 分拆为独立公司,此前 1986 年的 PKI 终端产品与 1991 年的 PKCS 标准均属 RSA Data Security 时期,本文按此官方谱系叙述。Entrust 的 distrust 宣布日、生效日与业务出售节点,均以 Google 官方博客与各浏览器公告的具体日期为准(见 4.6 的时间线表)。
七、机构市场地位标记具有时效性。 文中对 Chunghwa Telecom、Netlock 的"Chrome 已移除信任"、Entrust 的"公开 CA 业务已出售"、TrustCor 的"已被移除信任"等标记,均为 2026 年 10 月的状态快照,后续可能变化。核查时请以 Chrome 根证书计划与 Mozilla 根证书存储的最新公告为准。
八、中国 CA 数量的统计时点。 "工信部许可 CA 共 55 家"为截至 2023 年 9 月的快照;"CCA 持牌 23 家"为截至 2026 年 9 月 29 日的快照。两者统计对象与制度不同,不可直接比较。
九、政策类信息的时点敏感。 2024 年 9 月 2 日发布的《电子认证服务管理办法(征求意见稿》)为征求意见稿,其最终生效版本以工业和信息化部正式公布为准;本文引用的注册资本门槛、禁止委托条款、部省联动监管等均为征求意见稿内容。本文中所有涉及未来的时间表(2026-03-15、2027-03-15、2029-03-15 的有效期收缩,2026 年多视角数量递增,2025-09-15 起 SC-067 生效等)均以 CA/Browser Forum 已通过并公布的表决为准,其执行情况可能因后续修订而调整。
十、"没有证据"与"证据表明没有"是两回事。 本文中多处使用"没有厂商公开数据""此处数据未公开核实"等表述,这些是对证据状态的陈述,而非对事实的否定。读者在引用时应保留这一区分。
十一、部分行业数据点为快照。 文中引用的年度份额数据、CT 份额数据、赞助方名单、持牌 CA 名单等均为特定时点快照。这些数字的典型半衰期以月计。 引用时请附时点。
附录 E 配图索引
编号
图名
对应文件
所在章节
配图 1
密码学谱系时间轴:从古典密码到 PKI 信任结构
fig01-cryptography-timeline.png
1.1 古典密码与对称密码的困境
配图 2
PKI 分层信任结构:根 CA、中间 CA、终端证书、注册机构与依赖方
fig02-pki-hierarchy.png
1.5 密码算法的谱系与更替
配图 3
SSL/TLS 协议演进时间轴与安全强度递增曲线
fig03-tls-evolution.png
2.4 浏览器根证书计划与“准入即信任”
配图 4
证书生命周期与自动化流水线:八环节流程、三级有效期阶梯与无吊销设计
fig05-cert-lifecycle.png
3.4 有效期收缩运动:SC-081v3 与 47 天时代
配图 5
信任撤退事件的规模与影响范围对比
fig04-symantec-distrust.png
4.5 Let's Encrypt CAA 缺陷(2020):规模放大效应
配图 6
证书透明度机制全景:预证书、Merkle Tree、监控器与审计器
fig06-ct-mechanism.png
5.2 CT 的运作机制:日志、Merkle Tree、SCT、监控器与审计器
配图 7
全球四种监管范式对比
fig07-regulation-models.png
6.7 全球监管模式对比表
配图 8
全球 CA 生态版图:区域分布与机构类型
fig06-global-ca-landscape.png
第七章 全球根证书服务商图谱(章首)
配图 9
未来趋势:短生命周期证书、后量子迁移、身份化证书与韧性设计
fig08-future-pqc.png
8.2.2 三重压力与迁移基础设施
配图 10
后量子迁移时间轴与三层迁移阻力
fig08-pqc-migration.png
8.2.2 三重压力与迁移基础设施