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

一般信息

问题排查

管理受信证书

附录

一般信息

发生了什么?

概览

Google 正在开展一项持续多年的计划,以颁发并使用其自己的根证书,即加密签名,加密签名是 HTTPS 所利用的 TLS/SSL 互联网安全性的基础。

目前,Google Maps Platform 的 TLS 安全性由 GeoTrust Global CA 颁发的根证书提供保证。GeoTrust Global CA 是一个非常知名且广受信任的证书授权机构,归 Symantec 所有。实际上所有 TLS 客户端(例如网络浏览器、智能手机和应用服务器)都知道此根证书,因此可以使用它来确保自己与 Google Maps Platform 服务器之间建立的连接安全无虞。

到 2020 年初,Google 计划将所有 Google Maps Platform 服务迁移到由 Google 自有的证书授权机构 Google Trust Services (GTS) 颁发的根证书。

作为一项临时措施,2018 年初,Google Maps Platform 迁移到了另一个来自 GlobalSign (GS) 的广受信任的根证书。Google 购买了此根证书(以及 GlobalSign 用于颁发此证书的 CA)的使用权,以便顺利完成证书过渡。

大多数 TLS 客户端已可以识别该 GlobalSign 根证书,因此这项初始变更不会影响它们对 Google Maps Platform 的使用。

不过,某些客户端可能会缺少 GlobalSign 根证书,尤其是在一些特殊用例下(例如,嵌入式设备,或者用户使用非常老旧的浏览器或操作系统)。这些客户端需要进行证书更新,才能够确保其 Google Maps Platform 连接的安全。Google 无法识别这些客户端,因此应用所有者必须在自己的应用中执行任何必要的验证。Google Trust Services 在 GTS 网站上提供了 HTTPS 测试端点,以帮助进行此类验证。如需了解更多技术详情,请参阅下文。

在向 GTS 根证书的迁移开始后,大多数系统可能都要经历同样的情形,不过一般来说,即使是特殊系统,采纳本文档中提供的建议都应该能确保顺利迁移。

技术摘要

正如 2017 年 3 月 16 日在 Google Maps Platform 高级计划客户服务门户中以及更早时候在 Google 安全博客中宣布的那样,Google 已创建自己的根 CA,即 GTS。Google Maps Platform 将与其他 Google 服务一同逐步过渡到由 GTS 根 CA 签名的 TLS 证书。

作为一项临时措施,Google 购买了现有的、广受信任的 GS Root R2 CA。Google Maps Platform 在 2017 年底开始从 GeoTrust 根证书迁移到该证书,并于 2018 年初完成迁移。

几乎所有 TLS 客户端都预先配置了 GS Root R2 证书或通过常规软件更新接收了该证书,但是,如果应用从可能无法识别该证书的客户端连接到 Google Maps Platform,应用开发者应确保其客户端经过测试,并在必要时进行更新以接收该证书。

您可以在 GTS 网站上获取 GS Root R2 证书和所有 GTS 根证书。出于测试目的,GTS 网站还提供具有由每个 CA 签名的 TLS 证书的端点。具体而言,如果您的客户端能够与 GS Root R2 测试端点建立 TLS 连接,则说明它信任 GS Root R2 证书,应该不会受到即将发生的更改的影响。

至少到 2018 年底,Google 将依赖 GS Root R2 CA。此后,Google Maps Platform 可能会直接过渡到 GTS CA,有时也可能会回退到 GS Root R3 CA 等第三方根 CA。

如何接收有关此迁移流程的最新动态?

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

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

会,所有 Google 服务和 API 都会进行根 CA 迁移,但具体的迁移时间可能因服务而异。不过,在您确认自己的应用信任 Google 示例 PEM 文件中列出的一系列推荐的根证书后,您的应用应该会在根证书迁移过程中为未来做好准备,无论它会调用哪些 Google API 或服务。如需了解详情,请参阅问题是否应安装 Google 示例 PEM 文件中的所有根证书?

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

根据 GTS 网站上随每个根 CA 一同列出的测试端点测试您的应用环境。如果您能够与 GS Root R2 测试端点Google 证书测试沙盒建立 TLS 连接,则说明至少到 2018 年底您的应用将正常运行。

因此,我们强烈建议您立即安装 Google 示例 PEM 文件中列出的所有证书,以便您的系统为未来做好准备,除非您确定自己将设法确保生成环境始终处于最新状态并及时修补。

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

命令行工具 curl 在大多数平台上都可以找到,它提供大量可用于测试设置的选项。如需了解如何获取 curl,请参阅“获取 curl”部分。

测试默认证书存储区
# Google certificate test sandbox
$ curl -vvI https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI https://good.r4demo.pki.goog/
$ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
验证 Google 根 CA 文件包
下载 Google 示例 PEM 文件,然后按照以下步骤操作:
# Google certificate test sandbox
$ curl -vvI --cacert roots.pem https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI --cacert roots.pem https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI --cacert roots.pem https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI --cacert roots.pem https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI --cacert roots.pem https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI --cacert roots.pem https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI --cacert roots.pem https://good.r4demo.pki.goog/
$ openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -CAfile roots.pem -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null

迁移过程如何进行?

迁移何时开始?

第一个迁移阶段是改用锚定在 GS Root R2 中的由中级 CA 颁发的证书,于 2017 年底开始,2018 年上半年结束。

我们会在未来几年公布后续迁移阶段的时间安排,但该时间应该会远远早于 GS Root R2 2021 证书的到期时间。

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

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

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

随着新数据中心的迁移,越来越多的 Google Maps Platform 开发者将开始接收新证书。由于客户端请求往往会被转发到地理位置上临近的数据中心内的服务器,因此这些变化的影响可能会因本地情况而异。我们不能预先断定哪些位置的哪些人会在什么时候受到影响,因此建议所有客户在 Google 根 CA 迁移的后续阶段开始之前早早确认其系统已为未来做好准备。

需要注意的地方

如果客户端未配置必要的根证书,将无法验证与 Google Maps Platform 的 TLS 连接。在这种情况下,客户端通常会发出证书验证失败的警告。客户端可能会继续发出 Google Maps Platform 请求,也可能拒绝继续处理该请求,具体取决于其 TLS 配置。

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

请参阅GTS 常见问题解答中的“要与 Google 通信,传输层安全协议 (TLS) 客户端需满足哪些建议的最低要求?”部分。

Google Maps Platform 没有任何其他要求。

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

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

Google Maps Platform 网络服务应用

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

如果您使用的是不再接收更新的旧版操作系统,那么您不一定有 GS Root R2 证书。例如,Windows XP SP2 包含该证书,Windows XP SP1 则不包含。您应对旧版设备应进行测试,以确保它们信任该证书。

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

Google Maps Platform 客户端应用

Google Maps JavaScript API 应用通常依赖于运行应用的网络浏览器的根证书。如需了解更多详情,请参阅Google Maps JavaScript API 应用是否有服务中断的风险?部分。

对于 Android 设备和 iOS 设备上的原生移动应用,无论是使用 Google Maps SDK 还是使用 Places SDK,与调用 Google Maps Platform 网络服务的应用均遵守相同的规则。

如需了解更多详情,请参阅问题移动应用是否有服务中断的风险?

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

您必须自行更新证书文件包。如问题是否应安装 Google 示例 PEM 文件中的所有根证书?下所述,我们建议您将 Google 示例 PEM 文件 中的所有根证书导入到您的证书存储区。

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

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

是否应安装 Google 示例 PEM 文件中的所有根证书?

如果您想让自己的系统现在一次性为未来做好准备,建议您安装 Google 示例 PEM 文件中的所有证书,特别是在您不会定期为系统应用操作系统更新或者您为应用(举例来说)维护自己的证书文件包的情况下。

为什么不应安装任何中级 CA 证书?

您应仅安装 Google 示例 PEM 文件中的根证书,并依赖于根证书来验证锚定至它的整个证书链的真实性。这同样适用于各个服务器证书(例如由主机 maps.googleapis.com 服务的证书)以及我们的任何中级 CA(例如 GIAG3、GTS CA 1O1 或 GIAG4)。

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

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

GlobalSign R2 根 CA 充分嵌入到了大多数现代浏览器中,并受其信任。因此,这些浏览器可能在一段时间内能够继续连接到 Google 服务。如果浏览器得到积极维护,几乎可以肯定的是,在某个时间它也会支持所有其他 Google 根 CA。

但是,我们只能保证 Google Maps JavaScript API 可以在受支持的浏览器上运行,因此建议您使用列出的浏览器之一并及时更新浏览器,以确保使用时不会出现任何问题。

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

仍在接收设备制造商提供的定期更新的 Android 设备和 Apple 设备应该也为未来做好准备。虽然受信证书列表可能因手机制造商、设备型号和 Android 版本而异,但是大多数旧款 Android 手机已至少包含 GS Root R2 和 GS Root R3 证书。默认情况下,Google Nexus 和 Pixel 品牌的设备上使用的较新的 Android 开源项目 (AOSP) 版本也信任 GS Root R4。在任何已发布的 Android 版本中,对 GTS 根 CA 的支持仍然是最少的。

对于 iOS 设备,Apple 在其支持页面上维护了一个列表,针对每个最新 iOS 版本列出了受信任的根 CA。但是,所有 iOS 版本 5 及更高版本均支持 GS Root R2 和 R3,所有版本 7 及更高版本还支持 GS Root R4。与较新的 Android 版本一样,GTS 根 CA 在我们撰写此文档时尚不受支持。

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

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

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

由于第三方证书包含时间表很大程度上不在 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 和 tcpdump

虽然大多数 Linux 发行版都提供这两种工具,但您可在 https://www.wireshark.org 上找到适用于其他操作系统的 wireshark 预编译版本。tcpdump 和 LibPCAP 的源代码位于 https://www.tcpdump.org 上。

获取 Java keytool

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

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

对您而言,主要的应对措施是将 Google 示例 PEM 文件中必需的根证书安装到您的应用使用的证书可信存储区中。 不过,您仍然可以在管理受信证书部分中找到实用信息。
  1. 与系统管理员一起升级您的本地证书存储区。
  2. 参阅此常见问题解答,了解适用于您的系统的指针。
  3. 如果您需要获取特定于平台或系统的进一步帮助,请与您的系统提供商提供的技术支持渠道联系。
  4. 如需获取常规帮助,请与我们的支持团队联系,如与 Google Maps Platform 支持团队联系部分中所述。
  5. 为公开问题 67842936 加注星标,以获取进一步的迁移相关动态。

与 Google Maps Platform 支持团队联系

初始问题排查

如需获取一般性问题排查说明,请参阅问题如何验证我的证书存储区是否需要更新

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

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

  1. 受影响的服务器位于哪里?
  2. 您的服务调用了哪些 Google IP 地址?
  3. 哪些 API 受此问题影响?
  4. 问题开始出现的确切时间。
  5. 以下命令的输出:
    # Google Maps Platform service
    $ curl -vvI https://maps.googleapis.com/
    # Google Search site
    $ curl -vvI https://www.google.com/
    # Google certificate test sandbox
    $ curl -vvI https://cert-test.sandbox.google.com/
    # GS Root R2
    $ curl -vvI https://good.gsr2demo.pki.goog/
    # GS Root R3
    $ curl -vvI https://valid.r3.roots.globalsign.com/
    # GTS Root R1
    $ curl -vvI https://good.r1demo.pki.goog/
    $ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
    $ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
    

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

如何确定我的 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/<username>/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 libssh2/1.4.2
> Host: cert-test.sandbox.google.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 加密连接传输:
* 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=*.googleapis.com
*  start date: Jul 29 17:24:40 2019 GMT
*  expire date: Oct 27 17:24:40 2019 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.
> HEAD / HTTP/1.1
> User-Agent: curl/7.64.0
> Host: maps.googleapis.com
> Accept: */*
>
< HTTP/1.1 302 Found
如何以直观易懂的格式输出接收到的服务器证书?
假设输出格式为 PEM(例如 openssl s_client ... -showcerts 的输出),您可以按以下步骤输出提供的证书:
  1. 复制整个 Base64 编码证书,包括页眉和页脚:
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    
  2. openssl x509 -inform pem -noout -text
    
  3. 将您复制的内容粘贴到终端中。
  4. 按回车键。
如需查看示例输入和输出,请参阅如何以直观易懂的格式输出 PEM 证书?部分。

Google 证书在 OpenSSL 中是什么样子?

锚定在 GlobalSign 根 CA - R2 中的新证书

Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com
   i:C = US, O = Google Trust Services, CN = GTS CA 1O1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com

issuer=C = US, O = Google Trust Services, CN = GTS CA 1O1

管理受信证书

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

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 版本 GS Root R2 GS Root R3 GS Root R4 GTS
2.3、3.2、4.x、5.0
5.1、6.x、7.x、8.x、9
10

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

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

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

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

iOS 可信存储区

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

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

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

iOS 版本 GS Root R2 GS Root R3 GS Root R4 GTS
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 Feb 13  2017 /usr/lib/ssl/certs -> /etc/ssl/certs
$ ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 212177 Sep  5 00:45 ca-certificates.crt
…
lrwxrwxrwx 1 root root     62 Sep  5 00:39 GlobalSign_Root_CA_-_R2.pem -> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
…

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

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

Mozilla NSS

使用 Mozilla NSS 的应用可能默认也使用通常位于 /etc/pki/nssdb 下的系统级证书数据库或位于 ${HOME}/.pki/nssdb 下特定于用户的默认存储区。如需更新 NSS,请参阅 certutil 工具文档(以了解如何添加新证书)以及官方操作系统文档。

Microsoft .NET

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

Java

Java 应用可以使用自己的证书存储区,在 Linux 系统中,它通常位于 /etc/pki/java/cacerts/usr/share/ca-certificates-java如需获取使用 Oracle keytool 命令行工具更新 Java 证书存储区方面的帮助,请参阅以下 Stack Overflow 和 Oracle 文章:

什么是 PEM 文件?

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

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

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

什么是“.crt”文件?

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

什么是 DER 文件?

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

什么是“.cer”文件?

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

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

某些系统只接受导入包含一个证书的 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}"\
    $(printf %b $(openssl x509 -in ${f} -noout -issuer|sed -e 's/"//g'|sed -e 's#/#_#g')).pem;\
done
这应该会创建很多个类似于以下所列的 PEM 文件:
issuer=C=BE,O=GlobalSignnv-sa,OU=RootCA,CN=GlobalSignRootCA.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=ComodoCALimited,CN=AAACertificateServices.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOECCCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODORSACertificationAuthority.pem
issuer=C=IE,O=Baltimore,OU=CyberTrust,CN=BaltimoreCyberTrustRoot.pem
issuer=C=SE,O=AddTrustAB,OU=AddTrustExternalTTPNetwork,CN=AddTrustExternalCARoot.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustCommercial.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustNetworking.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremiumECC.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremium.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertHighAssuranceEVRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertTrustedRootG4.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2009Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-G2.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2012Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-EC1.pem
issuer=C=US,O=Entrust,Inc.,OU=www.entrust.net_CPSisincorporatedbyreference,OU=(c)2006Entrust,Inc.,CN=EntrustRootCertificationAuthority.pem
issuer=C=US,O=GeoTrustInc.,CN=GeoTrustGlobalCA.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR1.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR2.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR3.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR4.pem
issuer=C=US,O=StarfieldTechnologies,Inc.,OU=StarfieldClass2CertificationAuthority.pem
issuer=C=US,O=TheGoDaddyGroup,Inc.,OU=GoDaddyClass2CertificationAuthority.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com,Inc.,CN=GoDaddyRootCertificateAuthority-G2.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=StarfieldTechnologies,Inc.,CN=StarfieldRootCertificateAuthority-G2.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustECCCertificationAuthority.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustRSACertificationAuthority.pem
issuer=O=Cybertrust,Inc,CN=CybertrustGlobalRoot.pem
issuer=O=Entrust.net,OU=www.entrust.net_CPS_2048incorp.byref.(limitsliab.),OU=(c)1999Entrust.netLimited,CN=Entrust.netCertificationAuthority(2048).pem
issuer=OU=GlobalSignECCRootCA-R4,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignECCRootCA-R5,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R2,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R3,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R6,O=GlobalSign,CN=GlobalSign.pem
roots.pem
然后,您就可以分别导入各个 PEM 文件 issuer=….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 文件导入到系统中,请务必将密码存储在安全的地方。

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

请参阅 Mozilla NSS certutil 工具文档以及 Red Hat 社区网站讨论将 cert8.db 中的证书导出为 .pem 文件

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

在以下示例中,我们假设您拥有包含以下内容的文件 GlobalSign_Root_CA_-_R2.pem
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

使用 OpenSSL 输出证书

发出命令
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
应会在证书前输出以下行:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:0f:86:26:e6:0d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Validity
            Not Before: Dec 15 08:00:00 2006 GMT
            Not After : Dec 15 08:00:00 2021 GMT
        Subject: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:cf:24:0e:be:2e:6f:28:99:45:42:c4:ab:3e:
                    21:54:9b:0b:d3:7f:84:70:fa:12:b3:cb:bf:87:5f:
                    c6:7f:86:d3:b2:30:5c:d6:fd:ad:f1:7b:dc:e5:f8:
                    60:96:09:92:10:f5:d0:53:de:fb:7b:7e:73:88:ac:
                    52:88:7b:4a:a6:ca:49:a6:5e:a8:a7:8c:5a:11:bc:
                    7a:82:eb:be:8c:e9:b3:ac:96:25:07:97:4a:99:2a:
                    07:2f:b4:1e:77:bf:8a:0f:b5:02:7c:1b:96:b8:c5:
                    b9:3a:2c:bc:d6:12:b9:eb:59:7d:e2:d0:06:86:5f:
                    5e:49:6a:b5:39:5e:88:34:ec:bc:78:0c:08:98:84:
                    6c:a8:cd:4b:b4:a0:7d:0c:79:4d:f0:b8:2d:cb:21:
                    ca:d5:6c:5b:7d:e1:a0:29:84:a1:f9:d3:94:49:cb:
                    24:62:91:20:bc:dd:0b:d5:d9:cc:f9:ea:27:0a:2b:
                    73:91:c6:9d:1b:ac:c8:cb:e8:e0:a0:f4:2f:90:8b:
                    4d:fb:b0:36:1b:f6:19:7a:85:e0:6d:f2:61:13:88:
                    5c:9f:e0:93:0a:51:97:8a:5a:ce:af:ab:d5:f7:aa:
                    09:aa:60:bd:dc:d9:5f:df:72:a9:60:13:5e:00:01:
                    c9:4a:fa:3f:a4:ea:07:03:21:02:8e:82:ca:03:c2:
                    9b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root-r2.crl

            X509v3 Authority Key Identifier:
                keyid:9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E

    Signature Algorithm: sha1WithRSAEncryption
         99:81:53:87:1c:68:97:86:91:ec:e0:4a:b8:44:0b:ab:81:ac:
         27:4f:d6:c1:b8:1c:43:78:b3:0c:9a:fc:ea:2c:3c:6e:61:1b:
         4d:4b:29:f5:9f:05:1d:26:c1:b8:e9:83:00:62:45:b6:a9:08:
         93:b9:a9:33:4b:18:9a:c2:f8:87:88:4e:db:dd:71:34:1a:c1:
         54:da:46:3f:e0:d3:2a:ab:6d:54:22:f5:3a:62:cd:20:6f:ba:
         29:89:d7:dd:91:ee:d3:5c:a2:3e:a1:5b:41:f5:df:e5:64:43:
         2d:e9:d5:39:ab:d2:a2:df:b7:8b:d0:c0:80:19:1c:45:c0:2d:
         8c:e8:f8:2d:a4:74:56:49:c5:05:b5:4f:15:de:6e:44:78:39:
         87:a8:7e:bb:f3:79:18:91:bb:f4:6f:9d:c1:f0:8c:35:8c:5d:
         01:fb:c3:6d:b9:ef:44:6d:79:46:31:7e:0a:fe:a9:82:c1:ff:
         ef:ab:6e:20:c4:50:c9:5f:9d:4d:9b:17:8c:0c:e5:01:c9:a0:
         41:6a:73:53:fa:a5:50:b4:6e:25:0f:fb:4c:18:f4:fd:52:d9:
         8e:69:b1:e8:11:0f:de:88:d8:fb:1d:49:f7:aa:de:95:cf:20:
         78:c2:60:12:db:25:40:8c:6a:fc:7e:42:38:40:64:12:f7:9e:
         81:e1:93:2e

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

使用 Java keytool 输出证书

发出以下命令
keytool -printcert -file GlobalSign_Root_CA_-_R2.pem
应会提供以下输出:
Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Issuer:
CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Serial number:
400000000010f8626e60d
Valid from: Fri Dec 15 09:00:00 CET 2006 until: Wed Dec 15
09:00:00 CET 2021
Certificate fingerprints:
   MD5:
94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
   SHA1:
75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
   SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
   Signature algorithm name: SHA1withRSA
   Version: 3

Extensions:

#1:
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

#2: ObjectId:
2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
     [URIName: http://crl.globalsign.net/root-r2.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

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

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

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

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

PEM 文件可能会添加适当的标签,提供相关证书授权机构的直接易懂的信息(Google 示例 PEM 文件中的示例):

# Operating CA: GlobalSign
# Issuer: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Subject: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Label: "GlobalSign Root CA - R2"
# Serial: 4835703278459682885658125
# MD5 Fingerprint: 94:14:77:7e:3e:5e:fd:8f:30:bd:41:b0:cf:e7:d0:30
# SHA1 Fingerprint: 75:e0:ab:b6:13:85:12:27:1c:04:f8:5f:dd:de:38:e4:b7:24:2e:fe
# SHA256 Fingerprint: ca:42:dd:41:74:5f:d0:b8:1e:b9:02:36:2c:f9:d8:bf:71:9d:a1:bd:1b:1e:fc:94:6f:5b:4c:99:f4:2c:1b:9e
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

该文件也可能只包含证书部分。在此类情况下,该文件的名称(例如 GlobalSign_Root_CA_-_R2.pem)可能描述了证书所属的 CA。 -----BEGIN CERTIFICATE----------END CERTIFICATE----- 令牌之间的证书字符串对每个 CA 来说一定是唯一的,如果您无法以其他方式识别 CA,那么比较 PEM 文件之间的这些字符串是一种可靠的方式。

因此,您可以将 Google 示例 PEM 文件中的每个证书与您从证书存储区中提取的 PEM 文件进行比较。由于 Google 根 CA 文件包中的每个证书都添加了适当的标签,因此您可以可靠地验证您的证书存储区中已有哪些证书,并确定仍需添加哪些证书,即使您的证书存储区 PEM 文件未添加标签。

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

附录

需要更多信息?

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

其他任何信息来源(包括此常见问题解答)都可能已过时或不正确,不应视为权威信息。但是,您仍然可以在多个 Stack Exchange 问答社区AdamW on Linux 等网站和 confirm 博客以及其他平台上找到实用信息。另请参阅 GTS 常见问题解答以及文章如何使用 X.509 证书和 SSL 实现安全通信

如需详细了解高级主题(例如证书固定),您可以参阅开放式 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)的版本,请参阅操作系统供应商提供的相应代码库。