Google Maps Platform Root CA Migration FAQ

General information

Troubleshooting

Managing your trusted certificates

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 Platform 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 Platform servers.

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

As an interim step, in early 2018 Google Maps Platform migrated 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 Platform 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 Platform 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.

The same will likely apply to most systems by the time the migration to GTS root certificates begins, but following the recommendations in this document should generally ensure a smooth migration even for specialist systems.

Technical summary

As announced in the Google Maps Platform 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 Google Maps Platform 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 Platform started migrating from the GeoTrust root certificate to this certificate in late 2017, finishing the migration in early 2018.

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 Platform 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 Platform may transition directly to the GTS CA, or may on occasion fall back to third-party root CAs including GS Root R3 CA.

How do I get updates on this migration process?

Star public issue 67842936 for updates. This FAQ is also updated throughout the migration process, whenever we encounter topics that may be of general interest.

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 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/
$ 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
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/
$ 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

How will the migration proceed?

When will the migration occur?

The first migration phase, switching over to certificates issued by intermediate CAs anchored in GS Root R2, started in late 2017 and finished in the first half of 2018.

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 Platform 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 already verify their systems are future proof, well in advance of the next phases of the Google Root CA migration.

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 Platform. 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 Google Maps Platform request, or they may refuse to continue with the request.

What are the minimum requirements for a TLS client to communicate with Google Maps Platform?

Please refer to section What are the recommended minimum requirements for a Transport Layer Security (TLS) client to communicate with Google? in the GTS FAQ.

Google Maps Platform does not impose any additional requirements.

Which kinds of applications are at risk of breaking?

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

Google Maps Platform 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 Platform web services directly from the end user device, guidelines from question Are mobile applications at risk of breaking? apply.

Client-side Google Maps Platform applications

Google Maps JavaScript API applications generally 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, both on Android and iOS, using either the Google Maps or Places SDKs, the same rules apply as for apps calling the Google Maps Platform 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 update your certificate bundle yourself. As discussed under question Should I install all 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 all 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, especially 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.

Why should I not install any intermediate CA certificates?

You should only install the root certificates from the Google sample PEM file, and rely on the root certificate to verify the authenticity of the entire certificate chain anchored to it. This applies equally to individual server certificates (e.g. those served by the host maps.googleapis.com), as well as any of our intermediate CAs (e.g. GIAG3, GTS CA 1O1 or GIAG4).

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

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.

What to do in a production outage?

The primary course of action for you is to install the required root certificates from the Google sample PEM file into the certificate trust store your application uses. However, you may still find useful information in section Managing your trusted certificates.
  1. Work together with your system administrators to upgrade your local certificate store.
  2. Check this FAQ for pointers applicable to your system.
  3. If you need further platform- or system-specific assistance, reach out to the technical support channels offered by your system provider.
  4. For general assistance, reach out to our support team, as described in section Reaching out to Google Maps Platform support.
  5. Star public issue 67842936 for further migration related updates.

Reaching out to Google Maps Platform support

Initial troubleshooting

See question How do I verify if my certificate store needs an update for generic troubleshooting instuctions.

Section Managing your trusted certificates may also provide valuable information, if you need to import or export root certificates.

If the issue is not resolved, and you decide to reach out to Google Maps Platform support, be prepared to also provide the following information:

  1. Where are your affected servers located?
  2. Which Google IP addresses is your service calling?
  3. Which API(s) are affected by this issue?
  4. When exactly did the issue start?
  5. Outputs of the following commands: 
    # 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

For instructions getting the required tools, see question Where can I get the tools I need?.

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 or Debian Linux machine may contain these lines: 

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

Output from an Ubuntu or Debian 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: 
* 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
How do I print the received server certificates in human readable form?
Presuming the output is PEM formatted, e.g. the output from openssl s_client ... -showcerts, you can print out the served certificate following the below steps:
  1. Copy the entired Base 64 encoded certificate, including header and footer: 
    -----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

  2. openssl x509 -inform pem -noout -text
  3. Paste the contents of your copy buffer into the terminal.
  4. Hit the Return key.
For example input and output, see section How do I print PEM certificates in human readable form? below.

What do the Google certificates look like in OpenSSL?

New certificate anchored in GlobalSign Root 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

Managing your trusted certificates

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

Android trusted certificates

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, 9 Settings > Security & Location > Encryption & credentials > Trusted credentials
10 Settings > Security > Advanced ∨ 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, 9
10

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, 12.0
12.1.3+

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.

OpenSSL

For applications using OpenSSL, you can check the configured location of its installed components including the default certificate store using the following command: 
openssl version -d
The command prints out OPENSSLDIR, which corresponds to the top level directory the library and its configurations can be found under: 
OPENSSLDIR: "/usr/lib/ssl"
The certificate store is located in the certs subdirectory. 
$ 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
…

If OpenSSL relies on the default system certificate store as in the example above, check the top-level section Where is my system certificate store located and how can I update it? to ensure the system root certificate bundle is up to date.

For instructions getting openssl, see section Getting OpenSSL.

Mozilla NSS

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.

Microsoft .NET

Windows .NET developers may find at least the following Microsoft articles useful for updating their certificate store:

Java

Java applications might 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:

What is a PEM file?

Privacy-Enhanced Mail (PEM) is a de-facto standard textual file format for storing and sending cryptographic certificates, keys, etc., formalized as a de-jure standard in RFC 7468.

While the file format itself is human readable, the Base64 encoded binary certificate data information is not. However, the PEM specficiation permits emitting explanatory text either before or after the text encoded certificate body, and many tools use this feature to also provide a clear-text summary of the most relevant data elements in a certificate.

Tools, such as openssl can also be used to decode the entire certificate into human-readable form. See section How do I print PEM certificates in human readable form? for more info.

What is a ".crt" file?

Tools that allow exporting of certificates in PEM format commonly use the file extension ".crt" to indicate the file uses a textual enconding.

What is a DER file?

Distinguished Encoding Rules (DER) is a standardized binary format for encoding certificates. Certificates in PEM files are typically Base64 encoded DER certificates.

What is a ".cer" file?

An exported file with a ".cer" suffix may contain a PEM-encoded certificate, but more typically a binary, usually DER-encoded certificate. By convention, ".cer" files generally only contain a single certificate.

My system refuses to import all certificates from roots.pem

Some systems only accept importing PEM files that constain a single certificate. See question How do I extract individual certificates from roots.pem? below to see how the file can be split up.

How do I extract individual certifiactes from roots.pem?

You can split up roots.pem into its component certificates using the following simple bash script: 
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
This should create a number of individual PEM files similar to the ones listed below: 
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
The PEM files issuer=….pem can then be imported individually, or further converted into a file format your certificate store accepts.

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

The OpenSSL toolkit command-line tool openssl can be used to convert files between all commonly used certificate file formats. Instructions for converting from a PEM file to most commonly used certificate file formats are listed below.

For a full list of available options, check the official OpenSSL Command Line Utilities documentation.

For instructions getting openssl, see section Getting OpenSSL.

How do I convert a PEM file to DER format?

Using openssl you can issue the following command convert a file from PEM to DER: 
openssl x509 -in roots.pem -outform der -out roots.der

How do I convert a PEM file to PKCS #7?

Using openssl you can issue the following command convert a file from PEM to PKCS #7: 
openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b

How do I convert a PEM file to PKCS #12 (PFX)?

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

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.