Google Maps API Root CA Migration FAQ

General information

Troubleshooting

Managing your certificates and certificate store

Appendix

General information

What is happening?

The big picture

Google is working on a multi-year plan to issue and use its own root certificates, the cryptographic signatures which are the basis of TLS/SSL internet security used by HTTPS.

Currently, the TLS security of the Google Maps APIs is guaranteed by a root certificate issued by GeoTrust Global CA, a very well known and widely trusted certificate authority (CA) which is owned by Symantec. Practically all TLS clients (such as Web browsers, smartphones, and application servers) are aware of this root certificate, and therefore can use it to ensure that they have a secure connection to the Google Maps APIs servers.

By the early 2020s, Google plans to migrate all Google Maps API services to a root certificate issued by Google's own certificate authority, Google Trust Services (GTS).

As an interim step, in late 2017 the Maps APIs will migrate to another widely-trusted root certificate from GlobalSign (GS). Google has purchased the use of this root certificate (and the CA that GlobalSign used to issue it) in order to ease the certificate transition.

The vast majority of TLS clients already recognise the GlobalSign root certificate, so their usage of the Google Maps APIs will not be affected by this initial change.

However, especially in some specialist use cases such as embedded devices, or users working with very outdated legacy browsers or operating systems, it is possible that some clients will lack the GlobalSign root certificate. These clients will need to be updated with the certificate in order to be able to secure their Google Maps APIs connections. It is not possible for Google to identify these clients, so application owners must carry out any necessary verification on their own applications. Google Trust Services provides HTTPS test endpoints at GTS site to help with this. See below for more technical details.

Technical summary

As announced in the Google Maps API Premium Plan customer support portal on March 16 2017, and earlier on the Google Security Blog, Google has created its own root CA, GTS. Along with other Google services, the Google Maps APIs will gradually transition to TLS certificates signed by GTS root CAs.

As an interim step, Google has purchased the existing, widely-trusted GS Root R2 CA. The Google Maps APIs will migrate from the GeoTrust root certificate to this certificate in late 2017.

Almost all TLS clients are preconfigured with the GS Root R2 certificate or receive it via normal software updates, but, if an application connects to the Google Maps APIs from clients that may not recognize this certificate, the application developers should ensure that the clients are tested and if necessary updated with the certificate.

The GS Root R2 certificate and all GTS root certificates are available via the GTS site. For testing purposes, the GTS site also provides endpoints with TLS certificates signed by each CA. In particular, if your client can establish a TLS connection to GS Root R2 test endpoint then it trusts the GS Root R2 certificate and should not be affected by the upcoming change.

Google will rely on GS Root R2 CA at least through the end of 2018. After that, the Google Maps APIs may transition directly to the GTS CA, or may on occasion fall back to third-party root CAs including GS Root R3 CA.

Why did I receive the mandatory service announcement?

You received the mandatory service announcement email either because you either have previously interacted directly with Google Maps API technical support, or because your address is stored in our records as a technical contact point for your organization. In very rare cases, where we have no technical contact on record, we have reached out to customer contacts for whom we have no job description or title.

If you have received this message but you are not responsible for the technical maintenance of TLS-related issues, then we apologize and we ask that you please forward this message to your technical team.

As a Maps API Premium Plan customer you may also file a support case, if the FAQ does not provide sufficient guidance. While we will not be able to go into implementation details of your system, we can provide you general guidance. Any useful findings and generally applicable advice from support cases will be added to the FAQ.

Why did I not receive any mandatory service announcement?

The proactive outreach campaign was targeted to Google Maps API Premium Plan customers, but we may in the future extend also such campaigns to Standard Plan customers. Please take a moment to review your notification settings in the Google Cloud Console, as explained in the Cloud Platform Console Help article Manage notifications.

Is the information posted anywhere publicly so I can share it?

Yes, please star and share the public issue. Please also share a link to this FAQ, as it is being updated throughout the migration process whever we encounter topics that may be of general interest!

How do I get updates on this migration process?

Please star the public issue, and make sure to regularly check this FAQ for updates!

We use multiple Google services. Will the root CA migration affect all of them?

Yes, the root CA migration will happen across all Google services and APIs, but the timeline may vary per service. However, once you have verified that your application trusts the recommended set of root certificates listed in the Google sample PEM file, your application should be future proof during the root certificate migration, no matter which Google API or service it might call. See question Should I install all the root certificates from the Google sample PEM file? for further details.

How do I verify if my certificate store needs an update

Test your application environment against the test endpoints listed together with each of the root CAs on the GTS site. If you are able to establish a TLS connection to the GS Root R2 test endpoint and Google certificate test sandbox, you will be fine at least through the end of 2018.

Therefore, we strongly recommend that you install now all certificates from the Google sample PEM file to future proof your system, unless you are certain that you will always manage to keep your production environment completely up to date and patched up.

Is there a simple tool I can use to verify our certificate store?

The command line tool curl, available on most platforms, offers extensive options for testing your setup. For instructions getting curl, see section Getting curl.

Testing your default certificate store
# 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/
Verifying the Google Root CA bundle
Download the Google sample PEM file, then follow the steps below: 
# 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/

Where can I give feedback about the outreach campaign?

A link to a short survey was included in the email that was sent to the recipients of the mandatory service announcement.

Can I get the communications in my own language?

English is the only official Google Maps API Support language. If you cannot find anyone in your organization that can explain the contents, Maps API Premium Plan customers have the option to file a support case. We have an international team, so we may be able to provide best effort support in your language.

How will the migration proceed?

When will the migration occur?

The first migration phase, switching over to certificates issued by Google Internet Authority G3 (GIAG3) using GS Root R2, has started for the Google Maps APIs. However, due to issues reported by our customers, the rollout was temporarily on hold to give our customers more time to verify and update their systems.

The migration is currently scheduled to recommence on the week of Monday November 13, 2017, following the general outline described below. Initially only a small fraction of the traffic will be served using our new certificates issued by GIAG3, but the ratio increases with each data center included in the rollout. The GS Root R2 rollout is expected to last at least a few months, until all data centers serving Maps APIs have switched over to the new certificates. However, most Google Maps API users are still expected to receive the old-style certificates issued by Google Internet Authority G2 (GIAG2) using the Google's root CA until the end of 2017.

The schedules of later migration phases will be announced in the coming years, but well in advance of the GS Root R2 2021 certificate expiration.

General rollout plan for each Google service

  • The staged rollout starts in a single data center.
  • The rollout is gradually extended to more data centers until there is global coverage.
  • If serious issues are detected at any stage, the tests can be rolled back temporarily while the issues are addressed.
  • Based on input from previous iterations, further Google services are included in the rollout until gradually all Google services have migrated to the new certificates.

Who will be affected, when, and where?

Increasing numbers of Google Maps API developers will start to receive the new certificates as new data centers are migrated over. The changes will be somewhat localized, as client requests tend to be forwarded to servers in geographically nearby data centers. As we cannot with certainty in advance say who will be affected, when and where, we recommend all our customers verify their systems before the certificate change starts rolling out.

What to look out for

Clients that are not configured with the necessary root certificate will not be able to verify their TLS connection to the Google Maps APIs. In this situation, clients will typically issue a warning that certificate validation has failed. Depending on their TLS configuration, clients may continue to issue a Maps API request, or they may refuse to continue with the request.
In case of systematic failures
See question Our system is down because of the root CA migration! What can we do?.

Which kinds of applications are at risk of breaking?

The application uses the system certificate store without any developer imposed restrictions

Maps API web service applications

If you are using a mainstream OS, e.g., Ubuntu, Red Hat, Windows 7+ or Server 2008+, OS X) that is still maintained and receives regular updates, your default certificate store should already include the GS Root R2 certificate.

If you are using a legacy OS version that no longer receives updates, you may or may not have the GS Root R2 certificate. For example, Windows XP SP2 includes the certificate, but Windows XP SP1 does not. Legacy devices should be tested to ensure that they trust the certificate.

For mobile applications calling Google Maps API web services directly from the end user device, guidelines from question Are mobile applications at risk of breaking? apply.

Client-side Maps API applications

Google Maps Javascript API applications rely on the root certificates of the web browser running the application. See section Are Google Maps JavaScript API applications at risk of breaking? for more further details.

For native mobile applications using the Google Maps Android API or Maps SDK for iOS, the same rules apply the same guidelines as for apps calling the Google Maps API web services.

See question Are mobile applications at risk of breaking? for more details.

The application uses its own certificate bundle, or uses advanced security features, such as certificate pinning

You will need make sure to to update your certificate bundle yourself. As discussed under question Should I install all the root certificates from the Google sample PEM file?, we recommend you import all root certificates from the Google sample PEM file into your certificate store.

If you are pinning certificates or public keys for the Google domains your application connects to, you should add the certificates and public keys to the list of trusted entities in your application.

For further information about certificate or public key pinning, refer to the external resources listed under question Need more info?.

Should I install any intermediate or subordinate certificates?

You should only install the root certificates from the Google sample PEM file, and rely on certificate chains anchored in these to verify the authenticity of any subordinate certificates. This applies equally to server certificates (e.g. those used by host maps.googleapis.com), as well as any of our intermediate certificate authorities (e.g. GIAG2 and GIAG3).

Any modern TLS library implementation should be able to automatically verify such chains of trust, as long as the root certificate authority is trusted.

Should I install all the root certificates from the Google sample PEM file?

If you wish to future proof your system now in one go, we recommend that you install all certificates from the Google sample PEM file if you do not regularly and routinely apply operating system updates to your system, or if you for example maintain your own certificate bundles for your application.

Are Google Maps JavaScript API applications at risk of breaking?

The GlobalSign R2 root CA is well embedded, and trusted by most modern browsers. Therefore, it is likely that these browsers will continue to be able to connect to Google services for some time. If the browser is actively maintained, it is also almost certain that it will at some point also support all other Google root CAs.

However, the Google Maps JavaScript API itself is only guaranteed to work on supported browsers, so we recommend using one of the listed browsers and keeping the browser up to date to ensure problem free use.

Are mobile applications at risk of breaking?

Android and Apple devices still receiving regular updates from the device manufacturer are also expected to be future proof. Most older Android phone models already include at least both the GS Root R2 and GS Root R3 certificates, although the list of trusted certificates may vary per handset manufacturer, device model and Android version. Newer Android Open Source Project (AOSP) versions used on Google Nexus and Pixel branded devices also trust GS Root R4 by default. Support for the GTS Root CAs is still minimal in any of the released Android versions.

For iOS devices, Apple maintains a list of trusted root CAs for each recent iOS version on its support pages. However, all iOS versions 5 and up support GS Root R2 and R3, versions 7 and up also GS Root R4. As with current Android versions, GTS Root CAs are not yet supported at the time of writing.

See section How can I check the trusted root certificates on my mobile phone? for further details.

When will my browser or operating system include the Google Trust Services root certificates?

Google is working with all major third parties maintaining widely used and trusted root certificate bundles. Examples include operating system manufacturers, such as Apple and Microsoft, but also Google's own Android and ChromeOS teams; browser developers, such as Mozilla, Apple, Microsoft, but also Google's own Chrome team; manufacturers of hardware, such as phones, set-top boxes, TVs, game consoles, printers, just to name a few.

As third-party certificate inclusion timelines are largely beyond the control of Google, the best general advice we can offer is to make sure you regularly apply available system updates. Select third parties, such as Mozillaʼs CA Certificate Program may have documented their own certificate inclusion timelines.

Troubleshooting

Where can I get the tools I need?

Getting curl

If your OS distribution doesn't provide curl, you can download it from https://curl.haxx.se/. You can either download the source and compile the tool yourself or download a pre-compiled binary, if one is available for your platform.

Getting OpenSSL

If your OS distribution doesn't provide openssl, you can download the source from https://www.openssl.org/ and compile the tool. A list of binaries build by 3rd parties can be found via https://www.openssl.org/community/binaries.html. However, none of these builds are supported or in any specific way endorsed by the OpenSSL team.

Getting Wireshark and tcpdump

While most Linux distributions offer both tools, pre-compiled versions of wireshark for other OSs can be found at https://www.wireshark.org. The source code for tcpdump and LibPCAP can be found at https://www.tcpdump.org.

Getting Java keytool

The keytool command line tool should be shipped with every Java Development Kit (JDK) or Java Runtime Environment (JRE) version. Install these to get keytool. However, using keytool is unlikely necessary for root certificate verification, unless your application is built using Java.

Our system is down because of the root CA migration! What can we do?

The primary course of action for you is to install the required root certificates from the Google sample PEM file into the certificate store your application uses. However, you may still find useful information section Managing your certificates and certificate store.
  1. Try upgrading your certificate store.
  2. Perform initial troubleshooting steps as explained under question What steps should I take before reaching out to support?.
  3. Google Maps API Premium Plan customers should file a support case.
  4. Google Maps API Standard Plan customers should post a comment on the public issue.
  5. Star the public issue for status updates.

What steps should I take before reaching out to support?

Verifying your system before the root CA migration

See question How do I verify if my certificate store needs an update for further details. Section Managing your certificates and certificate store may also provide valuable information, if you end up needing to import or export root certificates.

How can I determine the public address of my DNS?

On Linux, you can run the following command: 
dig -t txt o-o.myaddr.l.google.com
On Windows you can use nslookup in interactive mode: 
C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

How do I interpret the curl output correctly and ensure the results are reliable?

Running curl with the -vvI flags provides much useful information. Here are a few instructions for interpreting the output:
  • Lines starting with '*' display output from the TLS negotiation, as well as connection termination information.
  • Lines starting with '>' display the outgoing HTTP request that curl sends.
  • Lines starting with '<' display the HTTP response it gets from the server.
  • If the protocol was HTTPS, the presence of '>' or '<' lines imply a successful TLS handshake.
Used TLS library and root certificate bundle

Running curl with the -vvI flags also prints out the used certificate store, but the exact output may vary per system as shown below.

Output from a Red Hat Linux machine with curl linked against NSS may contain these lines: 

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

Output from an Ubuntu Linux machine may contain these lines: 

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

Output from an Ubuntu Linux machine using the Google root certificate PEM file given using the --cacert flag may contain these lines: 

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

User agent

Outgoing requests contain the User-Agent header that may provide useful information about curl and your system.

An example from a Red Hat Linux machine: 

> 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: */*
>
Failed TLS handshake
Lines, such as the ones below indicate the connection was terminated mid-TLS-handshake because of an untrusted server certificate. The absence of debug output starting with '>' or '<' are also strong indicators of an unsuccessful connection attempt: 
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
Successful TLS handshake
A successful TLS handshake is indicated by the presence of similar looking lines to the ones below. The cipher suite used for the encrypted connection should be listed, as should details of the accepted server certificate. Furthermore, the presence of lines starting with '>' or '<' indicate that payload HTTP traffic is being successfully transmitted over the TLS encrypted connection: 
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-ECDSA-AES128-GCM-SHA256
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.googleapis.com
* start date: 2017-09-07 11:07:47 GMT
* expire date: 2017-11-30 10:54:00 GMT
* subjectAltName: maps.googleapis.com matched
* issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
* SSL certificate verify ok.
> HEAD / HTTP/1.1
> User-Agent: curl/7.35.0
> Host: maps.googleapis.com
> Accept: */*
>
< HTTP/1.1 302 Found

What do the Google certificates look like in OpenSSL?

New certificate issued by Google Internet Authority G3

---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=<subdomain or hostname, e.g. *.googleapis.com>
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=<subdomain or hostname, e.g. *.googleapis.com>
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---

Old certificate issued by Google Internet Authority G2

---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=<subdomain or hostname, e.g. *.googleapis.com>
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=<subdomain or hostname, e.g. *.googleapis.com>
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---

Managing your certificates and certificate store

How can I check the trusted root certificates on my mobile phone?

Android certificate store

As mentioned under question Are mobile applications at risk of breaking?, Android has since version 4.0 allowed handset users to verify the list of trusted certificates under Settings. The table below shows the exact Settings menu path:

Android version Menu path
1.x, 2.x, 3.x N/A
4.x, 5.x, 6.x, 7.x Settings > Security > Trusted credentials
8.x Settings > Security & Location > Encryption & credentials > Trusted credentials

The table below illustrates the likely availability of the most critical root certificates per Android version, based on manual verification using currently available Android Virtual Device (AVD) system images, falling back to the AOSP ca-certificates Git repository version history whenever system images are no longer available:

Android version 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

Updating the Android system certificate store is generally not possible without a firmware update or rooting the device. However, the current set of trusted root certificates on most still widely used Android versions is likely to provide uninterrupted service for multiple years to come, beyond the effective lifetime of most currently existing devices.

Beginning with version 7.0, Android offers application developers a secure method for adding trusted certificates which are only trusted by their application. This is done by bundling the certificates with the application and creating a custom network security configuration, as described in the Android Best Practices for Security & Privacy Network Security Configuration training document.

However, as third-party application developers will not be able to influence the network security configuration of traffic originating from the Google Play Services APK, such efforts would likely only provide a partial workaround.

On older legacy devices, your only available option would be to rely on user-added CAs, either installed by a corporate group policy applied to the end user device, or by the end users themselves.

iOS Trust Store

While Apple does not directly show its default set of trusted root certificates to the handset user, the company has links to the sets of trusted root CAs for iOS versions 5 and up from the Apple Support articles Lists of available trusted root certificates in iOS and iOS 5 and iOS 6: List of available trusted root certificates.

However, any additional certificates installed on the iOS device should be visible under Settings > General > Profile. If no additional certificates are installed, the Profile menu item may not be displayed.

The table below illustrates the availability of the most critical root certificates per iOS version, based on the above sources:

iOS version GS Root R2 GS Root R3 GS Root R4 GTS
5, 6
7, 8, 9, 10, 11

Where is my system certificate store located and how can I update it?

The location of the default certificate store varies with operating system and used SSL/TLS library. However, on most Linux distributions, the default root certificates can be found under one of the following paths: /usr/local/share/ca-certificates (Debian, Ubuntu, older RHEL and CentOS versions) , /etc/pki/ca-trust/source/anchors and /usr/share/pki/ca-trust-source (Fedora, newer RHEL and CentOS versions) or /var/lib/ca-certificates (OpenSUSE). Other certificate paths may include /etc/ssl/certs (Debian, Ubuntu) or /etc/pki/tls/certs (RHEL, CentOS). Some of the certificates in these directories are likely symbolic links to files in other directories.

Applications using Mozilla NSS may by default also use a system-wide certificate database typically located under /etc/pki/nssdb, or a user-specific default store under ${HOME}/.pki/nssdb. For updating NSS, check out the certutil tool documentation for how to add new certificates, as well as the official OS documentation.

Windows .NET developers may find at least the following Microsoft articles useful for updating their certificate store: Working with Certificates, Manage Trusted Root Certificates.

Java applications may use their own certificate store, which on Linux systems is typically located at /etc/pki/java/cacerts or /usr/share/ca-certificates-java. Please refer to the following Stack Overflow and Oracle articles for help updating your Java certificate store using the Oracle keytool command line tool: How to properly import a selfsigned certificate into Java keystore that is available to all Java applications by default?, How to obtain the location of cacerts of the default java installation?,

Java Platform, Standard Edition Tools Reference: keytool

How do I convert between a PEM file and a format supported by my system?

The Stack Overflow article Convert .pem to .crt and .key explains how to use the Linux openssl command line tool to convert between PEM and CRT+KEY, DER, P12 and other file formats. For a full list of available options, check the officialOpenSSL Command Line Utilities documentation.

For instructions getting openssl, see section Getting OpenSSL.

How do I convert a PEM file to P12?

Using openssl you can issue the following command convert a file from PEM to PKCS #12: 
openssl pkcs12 -info -in roots.p12

You need to provide a file password when created a PKCS #12 archive, make sure to store the password somewhere safe, if you don't immediately import the PKCS #12 file into your system.

How do I export certificates from the NSS certificate store as a PEM file?

Check out the Mozilla NSS certutil tool documentation, as well as the Red Hat community site discussion export certificate from cert8.db as a .pem file.

How do I print PEM certificates in human readable form?

In the following examples we presume you have the file GlobalSign_Root_CA_-_R2.pem with the following contents: 
-----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-----

Printing certificates using OpenSSL

Issuing the command 
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
should output the following lines before the certificate: 
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

For instructions getting openssl, see section Getting OpenSSL.

Printing certificates using Java keytool

Issuing the following command 

keytool -printcert -file GlobalSign_Root_CA_-_R2.pem
should provide the following output: 
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                                        ....
]
]

For instructions getting keytool, see section Getting Java keytool.

How do I see what certificates are installed in my certificate store?

This varies per operating system and SSL/TLS library. However, the tools that allows importing and exporting certificates to and from the certificate store typically also provide an option to list the installed certificates.

Also, if you have successfully exported the trusted root certificates into PEM files, or your certificate store already contains stored PEM files, you can try opening the files in any text editor, as it is a plain text file format.

The PEM file may be properly labeled, providing human readable information of the associated certificate authority (example from the Google sample PEM file): 

# 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-----

The file may also just contain the certificate part. In such cases, the name of the file, such as GlobalSign_Root_CA_-_R2.pem may describe which CA the certificate belongs to. The certificate string between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tokens is guaranteed to be unique for each CA, and you can reliably compare these strings between PEM files, if you cannot otherwise identify the CAs.

Therefore you can compare each of the certificates in the Google sample PEM file against the PEM files you extracted from your certificate store. As each certificate in the Google root CA bundle is properly labeled, you can reliably verify which of the certificates you already have in your certificate store and identify which of them still need to be added, even if your certificate store PEM files were not labeled.

For mobile phone specific instructions, see the separate question How can I check the trusted root certificates on my mobile phone?.

Appendix

Need more info?

Always rely primarily on your operating system documentation, the documentation of your application programming language(s), as well as the documentation from any external libraries that your application is using.

Any other source of information including this FAQ may be outdated or otherwise incorrect, and should not be taken as authoritative. However, you may still find useful information on many of the Stack Exchange Q&A communities, as well as sites such as AdamW on Linux and more and the confirm blog, among others. Please also check out the GTS FAQ, as well as the article How to Use X.509 Certificates and SSL For Secure Communications.

For further details about advanced topics, such as certificate pinning, you may find the Open Web Application Security Project (OWASP) article and cheat sheet informative. For Android specific instructions, please refer to the official Android Best Practices for Security & Privacy Security with HTTPS and SSL training document. For discussion about certificate v.s. public key pinning on Android, you may find Matthew Dolan's blog post Android Security: SSL Pinning useful.

The Android Best Practices for Security & Privacy Network Security Configuration training document and the JeroenHD blog post Android 7 Nougat and certificate authorities provide further information about managing additional trusted certificates on Android.

For a comprehensive list of root CAs trusted by AOSP, refer to the ca-certificates Git repository. For any versions based on inofficial Android forks, e.g. LineageOS, refer to the appropriate repositories provided by the OS vendor.

发送以下问题的反馈：

此网页
文档反馈
Google Maps Platform
Google Maps Platform
产品反馈