Google Maps Platform 根 CA 迁移常见问题解答

本文档包含以下几个部分:

如需详细了解持续不断的 Google 根 CA 迁移,请参阅“发生了什么?”部分。

术语

我们在下方列出了本文涉及的最重要的术语。如需深入了解相关术语,请参阅 Google Trust Services 常见问题解答

SSL/TLS 证书
证书会将加密密钥绑定到某一身份。
SSL/TLS 证书用于验证身份以及建立与网站之间的安全连接。证书由称为证书授权机构的实体颁发并采用加密签名。
浏览器通过受信任的证书授权机构颁发的证书确保将信息传输到相应服务器且传输时已加密。
安全套接字层 (SSL)
安全套接字层是部署最广泛的一种协议,用于加密互联网通信。SSL 协议已不安全,应停止使用。
传输层安全协议 (TLS)
传输层安全协议的前身是 SSL。
证书授权机构 (CA)
证书授权机构就像是设备和人员的数字护照办公室。它会颁发受加密保护的文档(证书),以证明某实体(例如网站)是其自称的身份。
在颁发证书之前,CA 需要确认证书中的名称与请求证书的人员或实体相关联。
“证书授权机构”可指 Google Trust Services 等机构以及颁发证书的系统。
根证书存储区
根证书存储区包含一组受应用软件供应商信任的证书授权机构。大多数网络浏览器和操作系统都有其根证书存储区。
要纳入根证书存储区,证书授权机构必须满足应用软件供应商规定的严格要求。
通常包括遵守 CA/浏览器论坛要求等行业标准。
根证书授权机构
根证书授权机构(更确切地说是其证书)是证书链中位于顶层的证书。
根 CA 证书通常是自签名证书。与其关联的私钥存储在高度安全的设施中,且在离线状态下维护,以防止遭到未经授权的访问。
中间证书授权机构
中间证书授权机构(更确切地说是其证书)用于为证书链中的其他证书签名。
中间 CA 主要用于在根 CA 证书保持离线状态时实现证书的在线颁发。
中间 CA 也称为“从属 CA”。
颁发证书的证书授权机构
颁发证书的证书授权机构(更确切地说是其证书)用于为证书链中的最底层证书进行签名。
最底层的证书通常称为订阅者证书、最终实体证书或叶证书。在本文档中,我们还会用到“服务器证书”一词。
证书链
证书与其颁发机构相关联(以加密方式签名)。证书链由叶证书、其所有颁发机构证书和根证书组成。
交叉签名
应用软件供应商的客户端必须更新其根证书存储区,以包含其产品所信任的新 CA 证书。包含新 CA 证书的产品需要一段时间才能得到广泛使用。
为提升与旧版客户端的兼容性,CA 证书可由另一个创建时间较早的 CA“交叉签名”。这样可以有效地为同一身份(名称和密钥对)创建第二个 CA 证书。
根据根证书存储区中包含的 CA,客户端将构建不同的证书链,具体取决于其信任的根证书。

一般信息

发生了什么?

概览

2017 年,Google 开始了一个持续多年的项目,旨在颁发并使用自己的根证书,即加密签名,这是 HTTPS 使用的 TLS 互联网安全性的基础。

第一阶段结束后,Google Maps Platform 服务的 TLS 安全性得到了 GS Root R2 的保证,GS Root R2 是 Google 从 GMO GlobalSign 收购的一个非常知名且广受信任的根证书授权机构 (CA),可让 Google 轻松过渡到自己的自签名 Google Trust Services (GTS) 根 CA。

实际上所有 TLS 客户端(例如网络浏览器、智能手机和应用服务器)都信任此根证书,因此能够在迁移过程的第一阶段建立与 Google Maps Platform 服务器的安全连接。

不过,CA 可以设计而非颁发证书,且证书的有效时间早于其证书的过期时间。GS Root R2 将于 2021 年 12 月 15 日到期,因此 Google 将使用自己的根证书授权机构 GTS Root R1 颁发的证书将其服务迁移到新的证书授权机构 GTS Root R1 Cross。

虽然绝大多数现代操作系统和 TLS 客户端库都已信任 GTS 根 CA,但为确保大多数旧版系统都能顺利完成过渡,Google 从 GMO GlobalSign 收购了 GlobalSign Root CA - R1(目前最早且最受信任的根 CA),实现了交叉签名。

因此,大多数客户的 Google Maps Platform 客户端已可以识别其中一个受信任的根 CA,或已可全部识别,因此完全不受迁移过程中第二阶段的影响。

这一点也适用于在 2018 年迁移过程的第一阶段采取措施的客户,他们当时应该已按照我们的说明通过我们的受信任的 Google 根 CA 文件包安装所有证书。

您应在以下情况下验证系统:

  • 您的服务在非标准平台或旧版平台上运行,且/或您自行维护根证书存储区
  • 您在 2017 至 2018 年的 Google 根 CA 迁移过程的第一阶段未采取任何措施,或者您未安装受信任的 Google 根 CA 文件包中的一整套证书

如果符合上述情况,您可能需要通过建议的根证书对客户端进行更新,以在迁移过程的这一阶段确保 Google Maps Platform 的使用不会中断。

如需了解更多技术详情,请参阅下文。如需了解通用说明,请参阅如何验证我的根证书存储区是否需要更新部分。

我们还建议您继续将根证书存储区与上述精选根 CA 文件包保持同步,以便证明您的服务日后能够适应根 CA 的变更。不过,相关变更会提前公布。如需进一步了解如何掌握最新动态,请参阅"如何接收有关此迁移阶段的最新动态?"和"如何提前收到有关未来迁移的通知?"部分。

技术摘要

如 2021 年 3 月 15 日在 Google 安全博客上公布的内容所述,Google Maps Platform 自 2018 年初以来一直使用的根证书授权机构 GS Root R2 将于 2021 年 12 月 15 日到期。因此,Google 将在今年迁移到新的证书授权机构 GTS Root R1 Cross。这意味着我们的服务将逐步过渡到此新 CA 颁发的 TLS 叶证书。

几乎所有现代 TLS 客户端和系统都预先配置了 GTS Root R1 证书,或者已通过常规软件更新接受该证书,GlobalSign Root CA - R1 甚至在旧版系统上也可用。

不过,如果满足以下两个条件,您至少应验证您的系统:

  • 您的服务在非标准平台或旧版平台上运行,且/或您自行维护根证书存储区
  • 您在 2017 至 2018 年的 Google 根 CA 迁移过程的第一阶段未采取任何措施,或者您未安装受信任的 Google 根 CA 文件包中的一整套证书

如何验证我的根证书存储区是否需要更新部分提供了有关如何测试系统是否会受到影响的通用指导。

如需了解完整详情,请参阅问题为什么我应确保将根证书存储区与受信任的 Google 根 CA 文件包保持同步?

如何接收有关此迁移阶段的最新动态?

为公开问题 186840968 加注星标,以获取最新动态。在迁移过程中,每当我们遇到用户可能普遍感兴趣的主题时,都会相应更新此常见问题解答。

如何提前收到有关未来迁移的通知?

建议您关注 Google 安全博客。此外,我们还将尽快更新特定于产品的文档,具体请参阅该博客上的公告内容。

另请订阅 Google Maps Platform Notifications,因为我们会在该论坛上定期发布有关可能会对更多客户造成影响的变更的最新动态。

我们使用了多项 Google 服务。根 CA 迁移会影响所有这些服务吗?

会,所有 Google 服务和 API 都会进行根 CA 迁移,但具体的迁移时间可能因服务而异。但是,确认您的 Google Maps Platform 客户端应用使用的根证书存储区包含受信任的 Google 根 CA 文件包中列出的所有 CA 后,您的服务应该不会受到持续进行的迁移的影响,而且保持同步也有助于您日后适应根 CA 的变更。

请参阅问题为什么我应确保将根证书存储区与受信任的 Google 根 CA 文件包保持同步?哪些类型的应用有服务中断的风险?,了解更多实用信息。

下文中的如何验证我的根证书存储区是否需要更新部分提供了有关测试系统的通用说明。

如何验证我的根证书存储区是否需要更新

根据下面列出的测试端点测试您的应用环境:

  • 如果您能够与 GTS Root R1 Cross 测试端点建立 TLS 连接,说明您在 GS Root R2 到期后也不会受到影响。
  • 如果您能够与 GTS Root R1 测试端点建立与 TLS 连接,说明您的应用甚至可能在 2028 年 GTS Root R1 Cross 和 GlobalSign Root CA - R1 到期后仍受到保护。

在以下情况下,您的系统通常可与这一根 CA 变更兼容:

  • 您的服务在受维护的主流操作系统上运行,您修复了您的服务所使用的操作系统以及库,且您不自行维护根证书存储区;或者
  • 您完全遵循了以前的建议,且安装了受信任的 Google 根 CA 文件包中的全部根 CA

可能会受影响的客户应立即安装受信任的 Google 根 CA 软件包中的证书,以免将来出现服务中断的情况。

如需了解完整详情,请参阅问题为什么我应确保将根证书存储区与受信任的 Google 根 CA 文件包保持同步?

是否有可用于验证根证书存储区的简单工具?

您可能会发现 curlopenssl 这两个命令行工具很适合您的调查。这两个命令行工具均适用于大多数平台,且提供了用于测试您的设置的各种选项。

如需了解如何获取 curl,请参阅下文的获取 curl 部分。

如需了解如何获取 openssl,请参阅下文的获取 OpenSSL 部分。

您还可在下文的在哪里可以获取所需工具?部分找到更多实用工具。

如需了解具体的测试说明,请参阅如何验证我的根证书存储区是否需要更新部分。

测试默认的根证书存储区

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.r1demo.pki.goog/; \
openssl s_client -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.r1xdemo.pki.goog/; \
openssl s_client -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;

验证受信任的 Google 根 CA 文件包

下载受信任的 Google 根 CA 文件包,然后按照以下步骤操作:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.r1xdemo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;

如何以及何时继续进行 Google 根 CA 迁移?

  1. 第一阶段(迁移到 GS Root R2)于 2017 年 1 月宣布,始于 2017 年底,结束于 2018 年上半年。
  2. 第二阶段(迁移到 GTS Root R1 Cross)已于 2021 年 3 月宣布,将于未来几个月内(即 GS Root R2 于 2021 年 12 月 15 日到期之前)进行。

我们会公布最终的后续迁移阶段的时间安排,但该时间会远远早于将来的证书到期时间。

不过,如果您确保将根证书存储区与受信任的 Google 根 CA 文件包中精选的根 CA 列表保持同步,您的应用便可适应将来的变更。

另请参阅问题为什么我应确保将根证书存储区与受信任的 Google 根 CA 文件包保持同步?,了解更多背景信息。

各项 Google 服务的一般部署计划

  1. 此分阶段部署从单个数据中心开始。
  2. 部署会逐步扩展到更多数据中心,直到实现全面覆盖。
  3. 如果在任何阶段检测到严重问题,可能会在问题解决时暂时回滚测试。
  4. 根据来自之前迭代的输入,我们会将更多 Google 服务纳入到部署计划中,直到所有 Google 服务都逐步迁移到新证书。

哪些位置的哪些人会在什么时候受到影响?

随着新数据中心的迁移,越来越多的 Google Maps Platform 开发者将开始接收新证书。由于客户端请求往往会被转发到地理位置上临近的数据中心内的服务器,因此这些变更的影响可能会因本地情况而异。

我们不能预先断定哪些位置的哪些人会在什么时候受到影响,因此建议所有客户在 Google 根 CA 迁移阶段开始之前早早确认其服务已为未来做好准备。

如需获取更多指导,请参阅如何验证我的根证书存储区是否需要更新部分。

需要注意的地方

如果客户端未配置必要的根证书,将无法验证与 Google Maps Platform 的 TLS 连接。在这种情况下,客户端通常会发出证书验证失败的警告。

客户端可能会继续发出 Google Maps Platform 请求,也可能拒绝继续处理该请求,具体取决于其 TLS 配置。

要与 Google Maps Platform 通信,TLS 客户端需满足哪些最低要求?

Google Maps Platform 证书使用 DNS 持有者备用名称 (SAN),因此客户端的证书处理必须能够支持包含单个通配符作为名称中最左侧标签的 SAN,例如 *.googleapis.com

如需了解其他要求,请参阅 GTS 常见问题解答中的要与 Google 通信,TLS 客户端需满足哪些建议的要求?部分。

哪些类型的应用有服务中断的风险?

使用系统根证书存储区、无任何开发者施加的限制的应用

Google Maps Platform 网络服务应用

如果您使用的是仍在维护并接收定期更新的主流操作系统(例如,Ubuntu、Red Hat、Windows 10 或 Server 2019、OS X),那么您的默认根证书存储区应该已包含 GTS Root R1 证书。

如果您使用的是不再接收更新的旧版操作系统,那么您不一定有 GTS Root R1 证书。但是,您的根证书存储区很可能包含 GlobalSign Root CA - R1,这是最早且最受信任的根 CA 之一。

对于直接从最终用户设备调用 Google Maps Platform 网络服务的移动应用,应遵循问题移动应用是否有服务中断的风险?中的准则。

Google Maps Platform 客户端应用

Maps JavaScript API 应用通常依赖于运行应用的网络浏览器的根证书。如需进一步了解相关信息,请参阅 JavaScript 应用是否有服务中断的风险?部分。

对于使用 Maps SDK for Android、Maps SDK for iOS、Places SDK for Android 或 Places SDK for iOS 中的任何一种的原生移动应用,这些规则均适用于调用 Google Maps Platform 网络服务的应用。

如需进一步了解相关信息,请参阅问题移动应用是否有服务中断的风险?

使用自己的证书文件包或使用高级安全功能(如证书固定)的应用

您必须自行更新证书文件包。如问题为什么我应确保将根证书存储区与受信任的 Google 根 CA 文件包保持同步?中所述,我们建议您将受信任的 Google 根 CA 文件包中的所有证书导入您自己的根证书存储区。

如果您要为应用连接到的 Google 网域固定证书或公钥,应该将证书和公钥添加到应用中受信任的实体列表。

如需详细了解证书或公钥固定,请参阅问题需要更多信息?下列出的外部资源。

为什么我应确保将根证书存储区与受信任的 Google 根 CA 文件包保持同步?

受信任的 Google 根 CA 文件包中的精选根 CA 列表包含可供 Google 服务在可预见的未来使用的所有 CA。

因此,如果您想让自己的系统为未来做好准备,强烈建议您验证自己的根证书存储区是否包含该文件包中的所有证书,并养成将二者保持同步的习惯。

如果您的服务在不受维护的操作系统版本上运行,或者您自行维护根证书存储区,这一点尤为重要,因为其他原因可能会导致操作系统和库无法修补。

请参阅问题如何提前收到有关未来迁移的通知?,了解如何接收有关未来根 CA 迁移的最新动态。定期将您的根证书存储区与精选列表保持同步,从而防止您的服务因 CA 变更在将来出现服务中断,同时使您的服务在 GTS Root R1 Cross 和 lobalSign Root CA - R1 到期后仍可正常运行。

另请参阅问题我正在构建一款与 Google 服务相关联的产品。我需要信任哪些 CA 证书?GTS 常见问题解答中),获取更多建议。

为什么不应安装任何叶证书或中间 CA 证书?

这样做会让您的应用在我们部署新证书或更改中间 CA 的任何时间面临服务中断的风险。上述情况随时都可能发生,恕不事先通知,单个服务器证书(例如由 maps.googleapis.com 提供的证书)以及我们的任何中间 CA(例如 GTS Root R1 Cross)也是如此。

如需使您的服务免受这种情况的影响,您应仅安装受信任的 Google 根 CA 文件包中的根证书,且仅并依赖根证书来验证锚定至整个证书链的可信度。

只要根证书授权机构可信,任何及时更新的 TLS 库实现应该都能自动验证此类受信链。

JavaScript 应用是否有服务中断的风险?

大多数现代浏览器都已嵌入 GTS 根证书且信任该证书,而且 GMO GlobalSign 中的交叉签名可确保顺利完成迁移,即使是针对大多数旧版浏览器上的最终用户的迁移。其中包括适用于 Maps JavaScript API 的所有官方支持的浏览器

每个现代浏览器都应允许最终用户验证通常还可修改浏览器所信任的证书。尽管确切位置因每个浏览器而异,但您通常可以在设置下的某个位置找到证书列表。

移动应用是否有服务中断的风险?

仍在接收设备制造商提供的定期更新的 Android 设备和 Apple iOS 设备应该也为未来做好准备。虽然受信任的证书列表可能会因手机制造商、设备型号和 Android 版本而异,但是大多数旧款 Android 手机都至少包含 GlobalSign Root CA - R1 证书。

不过,对 GTS 根 CA(包括 GTS Root R1)的支持在 Android 10 之前的版本中可能仍然受到限制。

对于 iOS 设备,Apple 在其支持页面上维护了一个列表,针对每个最新 iOS 版本列出了受信任的根 CA。但是,所有 iOS 5 及更高版本均支持 GlobalSign Root CA - R1。

GTS 根 CA(包括 GTS Root R1)自 iOS 12.1.3 开始受支持。

如需了解详情,请参阅问题如何在手机上查看受信任的根证书?

我的浏览器或操作系统何时会包含 Google Trust Services 根证书?

在过去的数年里,Google 一直与那些负责维护广泛使用且受信任的根证书文件包的所有主要第三方密切合作。这些第三方的示例包括操作系统制造商(例如 Apple 和 Microsoft 以及 Google 自己的 Android 和 ChromeOS 团队);浏览器开发者(例如 Mozilla、Apple、Microsoft 以及 Google 自己的 Chrome 团队);硬件制造商(例如手机、机顶盒、电视、游戏机、打印机,等等)。

因此,当前维护的任何系统都很可能支持 Google 的新 GTS 根 CA,包括 GTS Root R1,甚至旧版系统也很可能支持 GlobalSign Root CA - R1,在未来几年内,该证书将用于对 Google 颁发的证书进行交叉签名。

但是,由于第三方证书包含时间表很大程度上不在 Google 控制范围内,因此我们可以提供的最佳一般性建议是,确保您定期应用可用的系统更新。

部分第三方(例如 Mozilla 的 CA 证书计划)可能已载明其证书包含时间表

问题排查

在哪里可以获取所需工具?

获取 curl

如果您的操作系统发行版不提供 curl,您可以从 https://curl.haxx.se/ 下载。您可以下载源代码并自行编译该工具,也可以下载预编译的二进制文件(如果有适用于您的平台的二进制文件)。

获取 OpenSSL

如果您的操作系统发行版不提供 openssl,您可以从 https://www.openssl.org/ 下载源代码并编译该工具。您可以通过 https://www.openssl.org/community/binaries.html 找到由第三方提供的一系列二进制文件 build。但是,这些 build 都不受支持,也未以任何特定方式获得 OpenSSL 团队认可。

获取 Wireshark、Tshark 或 Tcpdump

虽然大多数 Linux 发行版都提供 wireshark、其命令行工具 tsharktcpdump,但您可以在 https://www.wireshark.org 上找到适用于其他操作系统的前两个预编译版本。

Tcpdump 和 LibPCAP 的源代码位于 https://www.tcpdump.org 上。

这些实用工具的文档分别位于 Wireshark 用户指南、Tshark 手册页和 Tcpdump 手册页

获取 Java keytool

keytool 命令行工具应随每个 Java 开发套件 (JDK) 或 Java 运行时环境 (JRE) 版本提供。安装这些后即可获取 keytool.,但是,除非您的应用是使用 Java 构建的,否则无需使用 keytool 进行根证书验证。

在生产环境服务中断时该怎么做

对您而言,主要的应对措施是将受信任的 Google 根 CA 文件包中必需的根证书安装到您的应用使用的根证书存储区中。

  1. 与系统管理员一起升级您的本地根证书存储区。
  2. 参阅此常见问题解答,了解适用于您的系统的指针。
  3. 如果您需要获取特定于平台或系统的进一步帮助,请与您的系统提供商提供的技术支持渠道联系。
  4. 如需获取常规帮助,请与我们的支持团队联系,如与 Google Maps Platform 支持团队联系部分所述。注意:对于特定于平台的问题,我们只能尽最大努力提供相关指导。
  5. 为公开问题 186840968 加注星标,以获取进一步的迁移相关动态。

与 Google Maps Platform 支持团队联系

初始问题排查

请参阅如何验证我的根证书存储区是否需要更新部分,了解通用的问题排查说明。

如果您需要导入或导出根证书,也可在管理受信证书部分找到有价值的信息。

如果问题仍未得到解决,并且您决定与 Google Maps Platform 支持团队联系,请准备好提供以下信息:

  1. 受影响的服务器位于哪里?
  2. 您的服务调用了哪些 Google IP 地址?
  3. 哪些 API 受此问题影响?
  4. 问题开始出现的确切时间。
  5. 以下命令的输出结果:

    curl -vvI https://maps.googleapis.com; \
    openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
    curl -vvI https://good.r1demo.pki.goog/; \
    openssl s_client -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.r1xdemo.pki.goog/; \
    openssl s_client -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;
    

如需了解如何获取所需工具,请参阅问题“在哪里可以获取所需工具?”。

提交支持请求

请按照 Google Maps Platform 支持和资源下的创建支持请求中的说明操作。

提交支持请求时,除了初始问题排查部分列出的数据以外,还请提供以下信息:

  • 您的公共 IP 地址
  • 您的 DNS 服务器的公共 IP 地址
  • 如果可能,提供与 https://maps.googleapis.com/ 失败的 TLS 协商的 tcpdump 或 Wireshark 数据包捕获,使用足够大快照长度来捕获整个数据包而不会截断它的 PCAP 格式(例如使用较旧版本的 tcpdump 上的 -s0)。
  • 如果可能,提供从您的服务中提取、显示确切的 TLS 连接失败原因的日志节选,最好附上完整的服务器证书链信息。

如需了解如何获取所需工具,请参阅问题“在哪里可以获取所需工具?”。

就公开问题 186840968 发帖

就公开问题 186840968 发表评论时,请附上初始问题排查部分所列的信息。

如何确定我的 DNS 的公共地址?

在 Linux 上,您可以运行以下命令:

dig -t txt o-o.myaddr.l.google.com

在 Windows 上,您可以在互动模式下使用 nslookup:

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

如何解释 curl 输出

运行带 -vvI 标记的 curl 可提供许多实用信息。以下是有关如何解释输出的一些说明:

  • 以“*”开头的行显示来自 TLS 协商的输出以及连接终止信息。
  • 以“>”开头的行显示 curl 发送的传出 HTTP 请求。
  • 以“<”开头的行显示它从服务器收到的 HTTP 响应。
  • 如果协议是 HTTPS,则“>”或“<”行的存在意味着 TLS 握手成功。

使用的 TLS 库和根证书文件包

运行带 -vvI 标记的 curl 也会输出使用的根证书存储区,但确切输出可能会因系统而异,如下所示。

curl 关联到 NSS 的 Red Hat Linux 机器的输出可能包含以下行:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

Ubuntu 或 Debian Linux 机器的输出可能包含以下行:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

对于使用 Google 根证书 PEM 文件(通过 --cacert 标记传递)的 Ubuntu 或 Debian Linux 机器,其输出可能包含以下行:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

用户代理

传出请求中包含 User-Agent 标头,该标头可以提供有关 curl 和您的系统的实用信息。

以下是来自 Red Hat Linux 机器的一个示例:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

TLS 握手失败

以下代码示例中的代码行表示由于服务器证书不可信,连接在 TLS 握手过程中终止。如果不存在以 >< 开头的调试输出,则明确表示连接尝试失败:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

TLS 握手成功

如果存在与以下代码示例中的行类似的行,则表示 TLS 握手成功。用于加密连接的加密套件应在行中列出,正如已接受服务器证书的详细信息一样。此外,如果存在以 >< 开头的行,则表示载荷 HTTP 流量正成功通过 TLS 加密连接传输:

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

如何以直观易读的格式输出接收到的服务器证书

假设输出格式为 PEM(例如 openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 的输出),您可以按以下步骤输出提供的证书:

  • 复制整个 Base64 编码证书,包括页眉和页脚:

    -----BEGIN CERTIFICATE-----
    …
    -----END CERTIFICATE-----
    
  • 然后执行以下操作:

    openssl x509 -inform pem -noout -text
    ````
    
  • 将您复制的内容粘贴到终端中。

  • 按回车键。

如需查看示例输入和输出,请参阅如何以直观易读的格式输出 PEM 证书部分。

交叉签名的 Google 证书在 OpenSSL 中是什么样子?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.r1xdemo.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.r1xdemo.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

管理受信证书

如何在手机上查看受信任的根证书?

Android 受信证书

正如问题“移动应用是否有服务中断的风险?”部分所提到的,从 Android 4.0 开始,手机用户可以验证设置下所列的受信证书。下表显示了确切的设置菜单路径:

Android 版本 菜单路径
1.x、2.x、3.x
4.x、5.x、6.x、7.x 设置 > 安全性 > 可信凭据
8.x、9 设置 > 安全性和位置信息 > 加密与凭据 > 可信凭据
10+ 设置 > 安全性 > 高级 > 加密与凭据 > 可信凭据

下表基于使用当前可用的 Android 虚拟设备 (AVD) 系统映像(每当系统映像不再可用时,回退到 AOSP ca-certificates Git 代码库版本记录)的手动验证,说明了每个 Android 版本的最关键根证书可能的提供情况:

Android 版本 GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2(有效期至 2021 年 12 月 15 日)
2.3、3.2、4.x、5.x、6.x、7.x、8.x、9
10+

如果不进行固件更新或获取设备的 root 权限,通常无法更新 Android 系统证书存储区。不过,在大多数仍广泛使用的 Android 版本中,当前受信任的根证书集可能会在未来几年提供不间断的服务,该时间超出了大多数现有设备目前的有效生命周期。

从版本 7.0 开始,Android 为应用开发者提供了添加仅受其应用信任的受信证书的安全方法。这是通过将证书与应用绑定并创建自定义网络安全配置来实现的,如 Android 安全和隐私权最佳做法网络安全配置培训文档中所述。

不过,由于第三方应用开发者无法影响源自 Google Play 服务 APK 的流量的网络安全配置,因此这项措施提供的解决方法并不完备。

在旧版设备上,您只能选择依赖于用户添加的 CA,它由应用于最终用户设备的企业组策略安装,或由最终用户自行安装。

iOS 可信存储区

虽然 Apple 不会向手机用户直接显示其默认的受信任根证书集,但该公司在以下 Apple 支持文章中提供了指向针对 iOS 版本 5 及更高版本的一组受信任根 CA 的链接:

不过,在 iOS 设备上安装的任何其他证书都应显示在设置 > 通用 > 配置文件下。如果设备上没有安装其他证书,系统可能不会显示配置文件菜单项。

下表基于上述来源说明了每个 iOS 版本最关键的根证书的提供情况:

iOS 版本 GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2(有效期至 2021 年 12 月 15 日)
5、6、7、8、9、10、11、12.0
12.1.3+

我的系统根证书存储区位于哪里?如何更新它?

默认根证书存储区的位置因操作系统和使用的 SSL/TLS 库而异。但在大多数 Linux 发行版中,默认根证书位于以下路径之一:

  • /usr/local/share/ca-certificates:Debian、Ubuntu、较旧版 RHEL 和 CentOS
  • /etc/pki/ca-trust/source/anchors/usr/share/pki/ca-trust-source:Fedora、较新版 RHEL 和 CentOS
  • /var/lib/ca-certificates:OpenSUSE

其他证书路径可能包括:

  • /etc/ssl/certs:Debian、Ubuntu
  • /etc/pki/tls/certs:RHEL、CentOS

这些目录中的某些证书可能是指向其他目录中的文件的符号链接。

OpenSSL 根证书存储区

对于使用 OpenSSL 的应用,您可以使用以下命令查看其安装的组件(包括默认根证书存储区)的配置位置:

openssl version -d

此命令会输出 OPENSSLDIR,它对应于库及其配置所在的顶级目录:

OPENSSLDIR: "/usr/lib/ssl"

根证书存储区位于 certs 子目录中。

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs
ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

如果 OpenSSL 依赖于上例中所示的默认系统根证书存储区,请查看上文“我的系统根证书存储区位于哪里?如何更新它?”部分,以确保系统根证书文件包是最新版本。

如需了解如何获取 openssl,请参阅获取 OpenSSL 部分。

Java 根证书存储区

Java 应用可以使用自己的根证书存储区,在 Linux 系统中,存储区通常位于 /etc/pki/java/cacerts/usr/share/ca-certificates-java 下,且可使用 Java keytool 命令行工具对其进行管理。

如要将单个证书导入您的 Java 证书存储区,请发出以下命令:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

只需将 cert.pem 替换为与每个推荐的根证书对应的证书文件,将 alias 替换为唯一但具有实际意义的证书别名,并将 certs.jks 替换为您的环境中所用的证书数据库文件即可。

如需了解更多信息,请参阅关于 Oracle 和 Stack Overflow 的以下文章:

Mozilla NSS 根证书存储区

使用 Mozilla NSS 的应用可能默认也使用通常位于 /etc/pki/nssdb 下的系统级证书数据库或位于 ${HOME}/.pki/nssdb 下特定于用户的默认存储区。

如需更新 NSS 数据库,请使用 certutil 工具。

如要将单个证书文件导入 NSS 数据库,请发出以下命令:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

只需将 cert.pem 替换为与每个推荐的根证书对应的证书文件,将 cert-name 替换为具有实际意义的证书别名,并将 certdir 替换为您的环境中所用的证书数据库路径即可。

如需了解更多信息,请参阅官方的 NSS Tools certutil 手册以及您的操作系统文档。

Microsoft .NET 根证书存储区

Windows .NET 开发者可以找到至少以下 Microsoft 文章来帮助其更新根证书存储区:

证书文件格式

什么是 PEM 文件?

隐私增强邮件 (PEM) 是用于存储和发送加密证书、密钥等内容的一项事实上的标准文本文件格式,在 RFC 7468 中是一项正式的具有法律意义的标准。

虽然该文件格式本身直观易读,但 Base64 编码的二进制证书数据信息不是。不过,PEM 规范允许在发送文本经过编码的证书正文前后发送说明文本,并且许多工具也利用此功能来提供证书中最相关的数据元素的明文摘要。

openssl 等工具还可以用于将整个证书解码为直观易读的格式。如需了解详情,请参阅如何以直观易读的格式输出 PEM 证书部分。

什么是“.crt”文件?

允许以 PEM 格式导出证书的工具通常使用文件扩展名“.crt”来指示文件使用文本编码。

什么是 DER 文件?

唯一编码规则 (DER) 是用于对证书编码的标准化二进制格式。PEM 文件中的证书通常是采用 Base64 编码的 DER 证书。

什么是“.cer”文件?

带有“.cer”后缀的导出文件可能包含 PEM 编码的证书,但更多情况下是二进制文件(通常包含 DER 编码的证书)。按照惯例,“.cer”文件一般只包含一个证书。

我的系统拒绝导入来自 roots.pem 的所有证书

某些系统(例如 Java keytool)只能导入来自 PEM 文件的一个证书,该文件包含多个证书时也是如此。请参阅如何从 roots.pem 中提取各个证书?部分,了解如何先拆分这类文件。

如何从 roots.pem 中提取各个证书?

您可以使用以下简单 bash 脚本将 roots.pem 拆分到其组件证书中:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

这应该会创建很多个类似于以下所列的 PEM 文件:

ls -l *.pem
-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

然后,您就可以分别导入各个 PEM 文件(例如 02265526.pem),或进一步将其转换为您的证书存储区接受的文件格式。

如何在 PEM 文件和我的系统支持的格式之间进行转换?

OpenSSL 工具包命令行工具 openssl 可用于在所有常用的证书文件格式之间转换文件。如需了解如何从 PEM 文件转换为最常用的证书文件格式,请参阅下文。

如需获取可用选项的完整列表,请参阅 OpenSSL 命令行实用程序官方文档

如需了解如何获取 openssl,请参阅获取 OpenSSL 部分。

如何将 PEM 文件转换为 DER 格式?

您可以使用 openssl 发出以下命令,将文件从 PEM 转换为 DER:

openssl x509 -in roots.pem -outform der -out roots.der
如何将 PEM 文件转换为 PKCS #7?

您可以使用 openssl 发出以下命令,将文件从 PEM 转换为 PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
如何将 PEM 文件转换为 PKCS #12 (PFX)?

您可以使用 openssl 发出以下命令,将文件从 PEM 转换为 PKCS #12:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

您需要提供在创建 PKCS #12 归档时的文件密码,如果您不立即将 PKCS #12 文件导入到系统中,请务必将密码存储在安全的地方。

列出、输出和导出根证书存储区中的证书

如何将 Java 密钥库中的证书导出为 PEM 文件?

您可以使用 keytool 发出以下命令,以列出您的证书存储区中的所有证书以及可用于导出每个证书的别名:

keytool -v -list -keystore certs.jks

只需将 certs.jks 替换为您的环境中所用的证书数据库文件即可。该命令还可显示导出证书时需要使用的每个证书的别名。

如要以 PEM 格式导出单个证书,请发出以下命令:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

只需将 certs.jks 替换为您的环境中所用的证书数据库文件,并提供与您要导出的证书对应的 aliasalias.pem 即可。

如需了解更多信息,请参阅 Java 平台、标准编辑工具参考:keytool 手册。

如何将 NSS 根证书存储区中的证书导出为 PEM 文件?

您可以使用 certutil 发出以下命令,以列出您的证书存储区中的所有证书以及可用于导出每个证书的别名:

certutil -L -d certdir

只需将 certdir 替换为您的环境中所用的证书数据库路径即可。该命令还可显示导出证书时需要使用的每个证书的别名。

如要以 PEM 格式导出单个证书,请发出以下命令:

certutil -L -n cert-name -a -d certdir > cert.pem

只需将 certdir 替换为您的环境中所用的证书数据库路径,并提供与您要导出的证书对应的 cert-namecert.pem 即可。

如需了解更多信息,请参阅官方的 NSS Tools certutil 手册以及您的操作系统文档。

如何以直观易读的格式输出 PEM 证书

在以下示例中,我们假设您拥有包含以下内容的文件 GTS_Root_R1.pem

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
使用 OpenSSL 输出证书文件

发出命令

openssl x509 -in GTS_Root_R1.pem -text

应会输出如下类似内容:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

如需了解如何获取 openssl,请参阅获取 OpenSSL 部分。

使用 Java keytool 输出证书

发出以下命令

keytool -printcert -file GTS_Root_R1.pem

应会输出如下类似内容:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

如需了解如何获取 keytool,请参阅获取 Java keytool 部分。

如何查看根证书存储区中安装了哪些证书?

方法因操作系统和 SSL/TLS 库而异。但是,用于向根证书存储区导入和从中导出证书的工具通常也提供列出已安装证书的选项。

此外,如果您已成功将受信任的根证书导出为 PEM 文件,或您的证书存储区已包含存储的 PEM 文件,则您可以尝试在任何文本编辑器中打开相应文件,因为它们是纯文本文件格式。

PEM 文件可能会添加适当的标签,提供相关证书授权机构的直观易读的信息(受信任的 Google 根 CA 文件包中的示例):

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

该文件也可能只包含证书部分。在此类情况下,该文件的名称(例如 GTS_Root_R1.pem)可能描述了证书所属的 CA。此外,-----BEGIN CERTIFICATE----------END CERTIFICATE----- 令牌之间的证书字符串对每个 CA 来说也一定是唯一的。

但是,即使您缺少上述工具,但由于受信任的 Google 根 CA 文件包中的每个证书均已添加适当的标签,因此您可以通过 Issuer 或比较 PEM 文件证书字符串,可靠地将文件包中的根 CA 与您的根证书存储区中的根 CA 相匹配。

网络浏览器可能会使用其自己的根证书存储区,也可能依赖于操作系统提供的默认证书。但是,所有现代浏览器都会允许您管理或至少查看它们信任的根 CA 集。如需进一步了解相关信息,请参阅问题 JavaScript 应用是否有服务中断的风险?

如需获取特定于手机的说明,请参阅问题如何在手机上查看受信任的根证书?

附录

需要更多信息?

请始终以您的操作系统文档、应用编程语言文档以及您的应用使用的任何外部库的文档为主要参考信息。

其他任何信息来源(包括此常见问题解答)都可能已过时或不正确,不应视为权威信息。但是,您仍然可以在多个 Stack Exchange 问答社区AdamW on Linux 等网站和 confirm 博客以及其他平台上找到实用信息。

另请参阅 Google Trust Services 常见问题解答

如需详细了解高级主题(例如证书固定),您可以参阅开放式 Web 应用安全项目 (OWASP) 证书和公钥固定 文章和固定备忘单。如需获取特定于 Android 的说明,请参阅 Android 安全和隐私权最佳做法通过 HTTPS 和 SSL 确保安全官方培训文档。如需查看有关 Android 上的证书固定和公钥固定的讨论,您可以参阅 Matthew Dolan 的博文 Android Security: SSL Pinning

Android 安全和隐私权最佳做法网络安全配置培训文档和 JeroenHD 博文 Android 7 Nougat and certificate authorities 提供了有关如何在 Android 上管理其他受信证书的详细信息。

如需查看 AOSP 信任的根 CA 的完整列表,请参阅 ca-certificates Git 代码库。对于任何基于非官方 Android 分支(例如 LineageOS)的版本,请参阅操作系统供应商提供的相应代码库。