浏览器内置的证书颁发机构列表是什么？— 理解根存储和HTTPS信任结构

当您访问网站时，地址栏会显示一个挂锁图标。浏览器会验证服务器发送的证书，以判断连接的域名是否正确、证书是否有效以及是否由受信任的证书颁发机构颁发。

这里产生了一个疑问。

浏览器如何知道应该信任哪些证书颁发机构？

其依据就是根存储（Root Store），即受信任的根证书颁发机构列表。虽然通常说“浏览器内置了证书颁发机构列表”，但实际结构更为复杂。浏览器可以使用自己的列表，也可以使用操作系统的列表，公司管理员还可以添加单独的私有证书颁发机构。

本文将探讨浏览器和操作系统中注册的证书颁发机构列表是什么，Chrome、Firefox、Safari之间有何不同，以及当证书颁发机构被列入或移除列表时会发生什么。

浏览器通过证书链验证根证书颁发机构信任的结构

首先需要区分的三种证书

要理解HTTPS证书，需要区分服务器证书、中间证书和根证书。

类别	作用	常见位置
服务器证书	将连接的域名与公钥关联	Web服务器发送给浏览器
中间证书	代表根CA颁发服务器证书	Web服务器作为链的一部分发送
根证书	证书链的最终信任锚点	浏览器或操作系统的根存储

例如，假设www.example.com的服务器证书由中间CA签名，并且该中间CA证书链接到根CA。

신뢰된 루트 CA
    └── 중간 CA
          └── www.example.com 서버 인증서

浏览器验证服务器发送的证书链，以确认它是否连接到浏览器信任的根。这被称为证书路径验证或信任链验证。

重要的是，根证书列表包含证书颁发机构的公钥和身份信息。证书颁发机构的私钥不存储在浏览器中。根CA的私钥由证书颁发机构单独保护，浏览器使用公钥验证签名的有效性。

根存储不仅仅是证书文件的集合

根存储本质上是作为信任锚点的根证书集合。然而，在实际产品中，除了证书之外，还会应用多种策略。

特定根CA的信任状态
是否可用于TLS服务器认证
证书适用的DNS名称或颁发时间的限制
被阻止的CA和证书
证书透明度要求
允许的密钥大小和签名算法
服务器证书的最大有效期
证书吊销信息

因此，即使拥有相同的根证书，也并非所有浏览器都会产生完全相同的结果。这是因为证书路径的构建方式、中间证书的选择、吊销检查、本地策略以及浏览器特定的附加安全规则可能有所不同。

将根存储理解为以下内容会更方便：

根存储不是一个“无条件信任此证书颁发机构”的列表，而是一个可以开始证书验证的信任锚点集合，以及应用于该信任的策略集合。

Chrome现在使用自己的根存储

过去的Chrome在很大程度上依赖于Windows和macOS等操作系统的证书存储和验证功能。这种方式下，即使是相同的Chrome版本，证书验证结果也可能因操作系统而异。

目前，Chrome在支持的主要平台上使用Chrome根存储（Chrome Root Store）和Chrome证书验证器（Chrome Certificate Verifier）。Google根据其公开运营的根程序管理公共CA列表，Chrome以统一的方式验证证书路径。

Chrome根存储的特点如下：

Chrome默认信任的公共根CA由Google管理。
根存储包含在Chrome二进制文件中。
更改后的列表可以通过组件更新器独立于浏览器整体更新进行分发。
通常，根存储更新大约每季度进行一次。
如果存在紧急安全问题，可以在常规周期之外进行更改。
Chrome除了基于RFC 5280的验证外，还应用证书透明度、证书有效期等附加策略。

Chrome根程序规定了CA被纳入公共根列表的最低要求。遵守CA/Browser Forum的基线要求、CCADB信息公开、定期审计和事件响应是重要的审查要素。

如果使用自己的根存储，公司的私有CA会被忽略吗？

不是的。

Chrome证书验证器除了用于公共网络的Chrome根存储外，还会考虑用户或组织管理员在本地配置的信任决策。例如，如果公司通过Windows组策略或macOS管理配置文件部署了内部根CA，Chrome在验证内部网站的证书时可以使用它。

但是，公共根和本地根的含义不同。

项目	公共根CA	本地·私有根CA
主要用途	公共互联网网站	内部系统、开发环境、安全代理
包含主体	浏览器·操作系统的根程序	用户或组织管理员
适用范围	使用该根存储的多数用户	安装了证书的设备和账户
验证标准	公共策略、审计、CCADB、行业要求	组织内部策略
错误信任的影响	全球证书误颁发风险	管理范围内的HTTPS劫持风险

Chrome官方文档还解释了一个详细的区别：在基于TCP的TLS连接中，本地信任决策会考虑信任的添加和移除；而在QUIC连接中，本地决策只考虑信任的移除。因此，在使用私有PKI的环境中，需要同时测试TCP和QUIC的行为、浏览器策略以及实际部署方式。

如何在Chrome中查看列表

要查看Chrome实际使用的Chrome根存储内容，可以使用以下内部页面：

chrome://system

在该页面中，展开chromerootstore项即可查看Chrome当前识别的根存储信息。

证书管理可以通过以下页面访问：

chrome://certificate-manager

屏幕配置和提供功能可能因Chrome版本和操作系统而异。重要的是不要将公共根列表、本地添加的证书和操作系统管理的证书视为同一事物。

Firefox以Mozilla根存储为中心运行

Firefox长期以来一直使用Mozilla管理的自有根证书列表。要包含在Mozilla根存储中的CA必须遵守Mozilla根存储策略和CA证书程序的要求。

因此，曾出现过在同一台计算机上Chrome正常，但Firefox却显示SECERRORUNKNOWN_ISSUER错误的情况。典型的场景是操作系统中注册了公司的私有CA，但Firefox不使用它。

最近，Firefox在Windows、macOS和Android上默认提供了自动查找并信任操作系统中添加的第三方根证书的功能。从Firefox 120开始，相关功能已默认对普通用户启用。

在设置中，可以通过以下项目进行管理：

설정
  └── 개인정보 및 보안
        └── 인증서
              └── 설치한 제3자 루트 인증서를 Firefox가 자동으로 신뢰하도록 허용

在企业环境中，可以使用security.enterprise_roots.enabled设置或Firefox企业策略。在Linux上，需要单独检查发行版的PKI结构和p11-kit的集成情况。

Firefox的行为总结如下：

公共Web的基本信任标准是Mozilla根存储。
操作系统或组织添加的第三方CA也可以根据设置和平台使用。
Firefox的证书管理器也可以导入单独的CA。
公共根存储和组织的私有CA是不同的信任来源。

Safari使用Apple操作系统的信任存储

Safari使用Apple平台的根存储和证书验证体系。Apple管理并发布了在iOS、iPadOS、macOS、tvOS、visionOS和watchOS上使用的根证书列表。

Apple操作系统使用共享根存储，您可以在Apple支持文档中查看每个操作系统版本的受信任根和被阻止的证书。

在macOS上，可以通过“钥匙串访问”或“系统设置”查看证书。

응용 프로그램
  └── 유틸리티
        └── 키체인 접근
              └── 시스템 루트 / 시스템 / 로그인

这三个钥匙串的含义不同。

系统根证书: Apple默认提供的根证书
系统: 安装在整个设备上的组织·管理员证书
登录: 安装在当前用户账户下的证书

组织可以通过MDM配置配置文件分发私有根CA。用户手动安装的证书可能需要根据平台策略进行额外的信任设置。

iOS版Chrome也不例外。由于Apple的平台策略，iOS版Chrome无法使用Chrome根存储和Chrome证书验证器，而是依赖于Apple的证书验证体系。因此，尽管名称是Chrome，但其根存储行为不应被视为与桌面版Chrome相同。

Windows根存储和Edge有何不同？

Windows通过Microsoft受信任根证书计划分发受信任根和不受信任证书列表。Windows和应用程序利用证书信任列表（Certificate Trust List），即CTL，来判断证书信任。

Windows大致有以下证书存储范围：

本地计算机
当前用户
组策略
企业
受信任的根证书颁发机构
不受信任的证书

管理工具分为以下几种：

certmgr.msc   # 当前用户证书
certlm.msc    # 本地计算机证书

Windows可以通过基于Windows Update的自动机制更新受信任CTL和不受信任CTL。根据Microsoft文档，也可以禁用自动更新，但出于安全考虑不建议这样做。

需要注意的是，Windows证书管理界面中显示的所有公共根证书并不一定都以文件形式预先安装。通过CTL和自动根更新机制，可以在需要时提供信任信息和证书。

Edge虽然也基于Chromium，但不应断定其产品策略和平台集成点与Chrome完全相同。特别是在企业环境中，需要针对实际目标版本验证Edge策略、Windows证书存储以及公共根存储和本地CA的应用情况。

浏览器信任结果不同的原因

同一个网站，在某个浏览器中可能正常，而在另一个浏览器中则可能出现警告。

原因	说明
根存储差异	一个程序可能包含根CA，而另一个程序可能不包含
中间证书缺失	服务器未发送完整链，导致不同浏览器补全结果不同
路径构建差异	存在多个交叉签名证书时选择的路径不同
本地CA集成差异	读取添加到操作系统的私有CA的方式不同
吊销信息差异	CRL、OCSP、浏览器特定阻止列表的应用方式不同
附加安全策略	CT、算法、证书生命周期和名称限制的应用不同
产品·操作系统版本	根存储和验证逻辑的更新时间不同

发生错误时，立即安装根证书并非良好的首次应对措施。首先，应确认服务器是否提供了正确的证书链。

按照以下顺序进行调查更为安全：

检查连接的主机名是否与证书的SAN匹配。
检查服务器证书的有效期。
检查服务器是否发送了所有必要的中间证书。
确定证书链连接到哪个根CA。
验证该根CA是否存在于浏览器的公共根存储或已批准的本地存储中。
检查安全代理或杀毒软件是否在中间重新签名HTTPS。
检查浏览器、操作系统和根存储的更新状态。

公司PC中添加私有根CA的原因

在企业环境中，仅靠公共CA难以解决问题的情况有很多。

为内部域名和内部服务颁发证书
在开发·测试环境中应用TLS
设备认证和相互TLS
安全代理的HTTPS检查
DLP、恶意软件分析和访问控制

特别是HTTPS检查设备会在客户端和外部站点之间将TLS连接分成两个。

브라우저 ← TLS 1 → 보안 프록시 ← TLS 2 → 외부 웹사이트

安全代理在验证外部网站证书后，会实时为访问的域名创建新证书并提供给浏览器。为了让浏览器无警告地接受此证书，安全代理的根CA必须安装在客户端的信任存储中。

这可能是运营上必要的控制，但它赋予了非常强大的权限。因为拥有该根CA私钥的系统可以在受管设备上生成各种HTTPS网站的证书。

分发私有根CA时，至少需要以下控制：

在HSM或离线环境中保护根CA私钥
实际颁发由受限的中间CA执行
审计证书颁发和管理员操作
最小化目标设备和使用目的
回收离职人员·丢失设备·报废设备的证书和策略
制定过期和替换计划
定义TLS检查排除对象和个人信息处理标准
故障时同时检查根存储和代理策略

根CA被列入列表的过程

公共CA向浏览器公司发送一个证书并不会立即获得信任。

通常需要以下程序和持续的义务：

满足根程序的包含要求。
公开证书策略（CP）和证书操作声明（CPS）。
接受WebTrust或ETSI系列的独立审计。
在CCADB中公开根和中间CA信息。
回应公开审查和查询。
遵守CA/Browser Forum基线要求。
报告并响应证书误颁发和安全事件。
即使被包含后，也要持续进行定期审计和政策遵守。

信任并非永久的权利。如果发生策略违规、证书误颁发、审计失败、私钥泄露或事件响应不足，根CA可能会被限制或移除。

即使根CA被移除，所有已颁发的证书也不会在同一时刻以相同方式全部失效。结果可能因浏览器版本、根存储更新状态、交叉签名路径、证书颁发时间限制和本地策略而异。

根存储更新是安全更新的原因

根存储的更改不仅仅是简单的证书列表整理。

添加新的CA意味着该CA颁发的证书可以默认被信任。反之，移除有问题的CA可以防止攻击者即使使用错误颁发的证书，浏览器也不会信任它。

停止更新的浏览器或操作系统可能会出现以下问题：

无法访问使用新根CA的正常网站
继续信任已被移除的CA
未应用新的证书限制和阻止策略
使用过时的算法和验证逻辑
与私有PKI更改不一致

在封闭网络中，浏览器自动更新和Windows CTL更新很容易被阻止。此时，需要单独确认仅分发浏览器可执行文件是否足够，或者根存储组件和不受信任的证书列表是否也得到了更新。

操作员需要检查的关键问题

处理根存储问题时，仅仅问“证书是否已安装？”是不够的。

要检查的问题	原因
此浏览器的公共信任列表由谁管理？	Chrome、Mozilla、Apple、Microsoft的程序不同
当前平台使用自己的存储还是操作系统存储？	同一浏览器在不同平台存在差异
组织添加的本地CA安装在哪个范围？	用户、设备、组策略的适用范围不同
该CA是否被信任用于TLS服务器认证？	即使有证书，也可能因用途限制而失败
根存储和阻止列表如何更新？	在封闭网络和更新受阻环境中很重要
服务器是否正确发送中间证书？	最常见的链错误之一
HTTPS检查设备是否重新签名证书？	浏览器看到的颁发者可能与原始CA不同
根CA私钥和颁发系统是否安全？	私有CA泄露会影响整个组织的TLS信任

## 结论：浏览器的挂锁是信任列表和策略的结果

浏览器并非预先知道世界上所有的证书。它以被判断为可信的根CA为起点，验证连接到服务器证书的链。

Chrome使用自己的Chrome根存储和证书验证器，同时也会考虑组织部署的本地信任。Firefox以Mozilla根存储为中心运行，但也可以利用操作系统中添加的第三方根证书。Safari和iOS版Chrome依赖于Apple平台的信任存储和验证体系。Windows通过Microsoft根证书计划和CTL更新机制管理系统的信任信息。

最终，HTTPS的挂锁并非仅由一种加密算法构成。

它是决定信任哪些证书颁发机构的根程序、部署在设备上的根存储、服务器提供的证书链、浏览器的验证策略以及组织的本地信任决策共同作用的结果。

解决证书错误时，不应盲目安装根证书，而应首先确认正在使用哪个根存储以及为什么证书链不受信任。特别是在私有CA和HTTPS检查环境中，必须同时管理为方便而添加的信任所具有的权限范围。