本文档包含以下几个部分：
如需详细了解持续进行的 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 证书。
- 根据根证书存储区中包含的 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 无法颁发在 CA 自己的证书到期后仍然有效的证书。GS Root R2 于 2021 年 12 月 15 日到期，因此 Google 将使用自己的根 CA（即 GTS Root R1）颁发的证书将其服务迁移到新的 CA（即 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 文件包保持同步？”。
是否有可用于验证根证书存储区的简单工具？
您可能会发现 curl 和 openssl 这两个命令行工具很适合您的调查。大多数平台上都提供这两个命令行工具，它们可提供用于测试您的设置的各种选项。
如需了解如何获取 curl，请参阅下文的“获取 curl”部分。
以下所示的 openssl 命令适用于版本 1.1.1 或更高版本。1.1.1 之前的版本不受支持。如果您使用的是较早的版本，请进行升级，或根据需要为您的版本修改这些命令。如需了解如何获取 openssl，请参阅下文的“获取 OpenSSL”部分。
您还可在下文的“在哪里可以获取所需工具？”部分找到更多实用工具。
如需了解具体的测试说明，请参阅“如何验证我的根证书存储区是否需要更新”部分。
测试默认的根证书存储区
curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.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.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;如何以及何时继续进行 Google 根 CA 迁移？
- 第一阶段（迁移到 GS Root R2）于 2017 年 1 月宣布，始于 2017 年底，结束于 2018 年上半年。
- 第二阶段（迁移到 GTS Root R1 Cross）已于 2021 年 3 月宣布，并于几个月内（即 GS Root R2 于 2021 年 12 月 15 日到期之前）进行。
后续迁移阶段的最终时间安排会于将来的证书到期之前尽早公布。
不过，如果您确保将根证书存储区与可信 Google 根 CA 文件包中精选的根 CA 列表保持同步，您的应用将可以适应将来的变更。
另请参阅问题“为什么我应确保将根证书存储区与可信 Google 根 CA 文件包保持同步？”，了解更多背景信息。
各项 Google 服务的一般部署计划
- 此分阶段部署从单个数据中心开始。
- 部署会逐步扩展到更多数据中心，直到实现全面覆盖。
- 如果在任何阶段检测到严重问题，我们可能会在解决问题时暂时回滚测试。
- 根据来自之前迭代的输入，我们会将更多 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 和 GlobalSign Root CA - R1 到期后仍可正常运行。
另请参阅问题“我正在构建一款连接到 Google 服务的产品。我需要信任哪些 CA 证书？”（位于 GTS 常见问题解答中），获取更多建议。
为什么不应安装任何叶证书或中间 CA 证书？
否则，在我们部署新证书或更改中间 CA 的整个过程中，您的应用都会面临服务中断的风险。我们随时可能部署新证书或更改中间 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 证书。
不过，Android 10 之前的版本对 GTS 根 CA（包括 GTS Root R1）的支持可能仍然有限。
对于 iOS 设备，Apple 在其支持页面上维护了一个列表，针对每个最新 iOS 版本列出了可信根 CA。但是，所有 iOS 5 及更高版本均支持 GlobalSign Root CA - R1。
从 iOS 12.1.3 开始，所有 iOS 版本均支持 GTS 根 CA（包括 GTS Root R1）。
如需了解详情，请参阅问题“如何在手机上查看可信根证书？”。
我的浏览器或操作系统何时会包含 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、其命令行工具 tshark 和 tcpdump，但您可以在 https://www.wireshark.org 上找到适用于其他操作系统的 wireshark 和 tshark 的预编译版本。
您可以访问 https://www.tcpdump.org 找到 Tcpdump 和 LibPCAP 的源代码。
您还可以参阅 Wireshark 用户指南、Tshark 手册页和 Tcpdump 手册页来分别找到这些实用工具的文档。
获取 Java keytool
每个 Java 开发套件 (JDK) 或 Java 运行时环境 (JRE) 版本都应随附 keytool 命令行工具。安装相应套件或版本后即可获取 keytool.。但是，除非您的应用是使用 Java 构建的，否则不太可能会用到 keytool 来进行根证书验证。
在生产环境服务中断时该怎么做
对您而言，主要的应对措施是将可信 Google 根 CA 文件包中必需的根证书安装到您的应用使用的根证书存储区中。
- 与系统管理员一起升级您的本地根证书存储区。
- 参阅此常见问题解答，了解适用于您的系统的指针。
- 如果您需要获取特定于平台或系统的进一步帮助，请与您的系统提供商提供的技术支持渠道联系。
- 如需获取常规帮助，请按照“与 Google Maps Platform 支持团队联系”部分所述的方法，与我们的支持团队联系。注意：对于特定于平台的问题，我们只能尽最大努力提供相关指导。
- 为公开问题 186840968 加注星标，以获取进一步的迁移相关动态。
与 Google Maps Platform 支持团队联系
初始问题排查
请参阅“如何验证我的根证书存储区是否需要更新”部分，了解通用的问题排查说明。
如果您需要导入或导出根证书，也可在“管理可信证书”部分找到有价值的信息。
如果问题仍未得到解决，并且您决定与 Google Maps Platform 支持团队联系，还请准备好提供以下信息：
- 受影响的服务器的位置。
- 您的服务调用的 Google IP 地址。
- 受相应问题影响的 API。
- 问题开始出现的确切时间。
以下命令的输出结果：
curl -vvI https://maps.googleapis.com; \ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \ curl -vvI https://good.gtsr1.demosite.pki.goog/; \ openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \ curl -vvI https://good.gtsr1x.demosite.pki.goog/; \ openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;
如需了解如何获取所需工具，请参阅问题“在哪里可以获取所需工具？”。
提交支持请求
请按照 Google Maps Platform 支持和资源下的创建支持请求中的说明操作。
提交支持请求时，除了“初始问题排查”部分列出的数据以外，还请提供以下信息：
- 您的公共 IP 地址。
- 您的 DNS 服务器的公共 IP 地址。
- 如果可能，提供 TLS 与
https://maps.googleapis.com/协商失败的 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 请求。 - 以“
<”开头的行显示 curl 从服务器收到的 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 ````将您复制的内容粘贴到终端中。
按 Return 键。
如需查看示例输入和输出，请参阅“如何以直观易读的格式输出 PEM 证书”部分。
交叉签名的 Google 证书在 OpenSSL 中是什么样子？
…
---
Certificate chain
0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.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.gtsr1x.demosite.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 版本最关键的根证书的可能提供情况（手动验证使用当前可用的 Android 虚拟设备 [AVD] 系统映像进行；每当系统映像不再可用时，则回退到 AOSP ca-certificates Git 代码库版本记录）：
| 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，这些 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/certslrwxrwxrwx 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 替换为您的环境中所用的证书数据库文件，并提供与您要导出的证书对应的 alias 和 alias.pem 即可。
如需了解更多信息，请参阅 Java 平台、标准编辑工具参考：keytool 手册。
如何将 NSS 根证书存储区中的证书导出为 PEM 文件？
您可以使用 certutil 发出以下命令，以列出您的证书存储区中的所有证书以及可用于导出每个证书的别名：
certutil -L -d certdir只需将 certdir 替换为您的环境中所用的证书数据库路径即可。该命令还可显示导出证书时需要使用的每个证书的别名。
如要以 PEM 格式导出单个证书，请发出以下命令：
certutil -L -n cert-name -a -d certdir > cert.pem只需将 certdir 替换为您的环境中所用的证书数据库路径，并提供与您要导出的证书对应的 cert-name 和 cert.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 and more 和 confirm blog 等网站，以及其他平台上找到实用信息。
另请参阅 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）的版本，请参阅操作系统供应商提供的相应代码库。