Google Maps Platform Root CA Migration FAQ

This document contains the following sections:

For an more detailed overview of the ongoing Google root CA migration, see What is happening?.

Terminology

Below, we have collected a list of the most important terms you need to be familiar with for this document. For a more comprehensive overview of related terminlogy, please turn to the Google Trust Services FAQ.

SSL/TLS Certificate
A certificate binds a cryptographic key to an identity.
SSL/TLS certificates are used to authenticate and establish secure connections to websites. Certificates are issued and cryptographically signed by entities known as Certificate Authorities.
Browsers rely on certificates issued by trusted Certificate Authorities to know that the information transmitted is sent to the right server and that it is encrypted while in transit.
Secure Sockets Layer (SSL)
Secure Sockets Layer was the most widely deployed protocol used to encrypt internet communications. The SSL protocol isn't considered secure anymore and should not be used.
Transport Layer Security (TLS)
Transport Layer Security is the successor to SSL.
Certificate Authority (CA)
A Certificate Authority is like a digital passport office for devices and people. It issues cryptographically protected documents (certificates) to attest that an entity (e.g. website) is who it claims to be.
Prior to issuing a Certificate, CAs are responsible for verifying that the names in the Certificate are linked to the person or entity requesting it.
The term Certificate Authority can refer to both organizations like Google Trust Services, and to systems which issue certificates.
Root certificates store
A root certificates store contains a set of Certificate Authorities trusted by an Application Software Supplier. Most web browsers and operating systems have their own root certificates store.
To be included in a root certificates store, the Certificate Authority must fulfill strict requirements set forth by the Application Software Supplier.
Typically these include compliance with industry standards such as the CA/Browser Forum requirements.
Root Certificate Authority
A Root Certificate Authority (or more correctly, its certificate) is the topmost certificate in a certificate chain.
Root CA certificates are usually self-signed. The private keys associated with them are stored in highly secure facilities, and maintained in an offline state to protect them from unauthorized access.
Intermediate Certificate Authority
An Intermediate Certificate Authority (or more correctly, its certificate) is a certificate that is used to sign other certificates in a certificate chain.
Intermediate CAs primarily exist to enable online certificate issuance while allowing the Root CA certificate to remain offline.
Intermediate CAs are also known as Subordinate CAs.
Issuing Certificate Authority
An Issuing Certificate Authority, or more correctly, its certificate, is the certificate that is used to sign the bottom-most certificate in a certificate chain.
This bottom-most certificate is commonly called a subscriber certificate, end-entity certificate or leaf certificate. In this document we will also use the term server certificate.
Certificate chain
Certificates are linked to (cryptographically signed by) their issuer. A certificate chain is made of a leaf-certificate, all its issuer certificates and a root certificate.
Cross-signing
Application Software Suppliers' clients must update their root certificates store to include new CA certificates for them to be trusted by their products. It takes some time until products containing the new CA certificates are widely used.
To increase compatibility with older clients, CA certificates can be "cross signed" by another older established CA. This effectively creates a second CA certificate for the same identity (name & key pair).
Depending on the CAs included in their root certificates store, clients will build a different certificate chain up to a root they trust.

General information

What is happening?

The big picture

In 2017, Google began a multi-year project to issue and use its own root certificates, the cryptographic signatures which are the basis of TLS internet security used by HTTPS.

After the first phase, the TLS security of Google Maps Platform services has been guaranteed by GS Root R2, a very well known and widely trusted root certificate authority (CA), which Google acquired from GMO GlobalSign to ease the transition to our own self-issued Google Trust Services (GTS) root CAs.

Practically all TLS clients (such as Web browsers, smartphones, and application servers) have trusted this root certificate, and have therefore been able to establish a secure connection to the Google Maps Platform servers during the first phase of the migration.

However, a CA can by design not issue certificates that are valid beyond the expiration time of its own certificate. As GS Root R2 expires on December 15, 2021, Google will migrate its own services to a new CA, GTS Root R1 Cross, using a certficate issued by Google's own root CA GTS Root R1.

While the vast majority of modern operating systems and TLS client libraries already trust the GTS root CAs, to also ensure a smooth transition for most legacy systems, Google has acquired a cross-sign from GMO GlobalSign using GlobalSign Root CA - R1, one of the oldest, most trusted root CAs currently available.

Therefore, most customers' Google Maps Platform clients will already recognise either (or both) of these well-trusted root CAs, and will be completely unaffected by the second phase of the migration.

This also applies to customers who took action during the first phase of the migration in 2018, presuming they at the time followed our instructions, installing all certificates from our trusted Google root CA bundle.

You should verify your systems, if the following applies:

  • your services run non-standard or legacy platforms and/or you maintain your own root certificates store
  • you did not take action in 2017-2018, during the first phase of Google's root CA migration, or you did not install the full set of certificates from the trusted Google root CA bundle

If the above applies, your clients may need to be updated with the recommended root certificates in order to be able to ensure uninterrupted Google Maps Platform use during the this phase of the migration.

See below for further technical details. For general instructions, please refer to section How to verify if my root certificates store needs an update.

We also recommend that you continue keeping your root certificates stores in sync with the above curated root CA bundle to proof your services against future root CA changes. However, these will be announced in advance. See sections How do I get updates on this migration phase? and How can I get advance notification of future migrations? for further instructions on how to stay informed.

Technical summary

As announced on March 15 2021 on the Google Security Blog, GS Root R2, the root CA Google Maps Platform has used since early 2018 will expire on December 15, 2021. Google will therefore during this year migrate to a newly issued CA GTS Root R1 Cross. This means that our services will gradually transition to TLS leaf certificates issued by this new CA.

Almost all modern TLS clients and systems are already preconfigured with the GTS Root R1 certificate or should receive it via normal software updates, and GlobalSign Root CA - R1 should even be available on older legacy systems.

However, you should verify your systems at least if both the following points apply:

  • your services run on non-standard or legacy platforms and/or you maintain your own root certificates store
  • you did not take action in 2017-2018, during the first phase of Google's root CA migration, or you did not install the full set of certificates from the trusted Google root CA bundle

Section How to verify if my root certificates store needs an update provides general guidance for testing if your system will be affected.

See question Why should I keep my root certificates store in sync with the trusted Google root CA bundle? for the full details.

How do I get updates on this migration phase?

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

How can I get advance notification of future migrations?

We suggest you follow the Google Security Blog. We will also strive to update product-specific documentation as soon as possible, following the pubic announcement on the blog.

Please also subscribe to Google Maps Platform Notifications, as we regularly post updates on the forum about changes that are likely to affect a larger number of customers.

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 the root certificates stores used by your Google Maps Platform client applications contain all CAs listed in the trusted Google root CA bundle, your services should not be affected by the ongoing migration, and keeping these in sync will also protect you against future root CA changes.

See questions Why should I keep my root certificates store in sync with the trusted Google root CA bundle? and Which kinds of applications are at risk of breaking? for further insights.

Section How to verify if my root certificates store needs an update below also provides general instructions for testing your system.

How to verify if my root certificates store needs an update

Test your application environment against the test endpoints listed below:

  • If you are able to establish a TLS connection to the GTS Root R1 Cross test endpoint, you should be unaffected by the GS Root R2 expiration.
  • If you are able to establish a TLS connection to the GTS Root R1 test endpoint, your application will likely even be shielded from the expiration of GTS Root R1 Cross and GlobalSign Root CA - R1 in 2028.

Your system will generally be compatible with this root CA change if:

  • your service runs on a maintained mainstream operating system, and you have kept both the operating system and the libraries your service uses patched up and you do not maintain your own root certificates store, or:
  • you followed our previous recommendations, and installed all root CAs from the trusted Google root CA bundle

Possibly affected customers should immediately install the certificates from trusted Google root CA bundle to avoid future service interruptions.

See question Why should I keep my root certificates store in sync with the trusted Google root CA bundle? for the full details.

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

You may find two command line tools curl and openssl useful in your investigations. Both are available on most platforms, and offer extensive options for testing your setup.

For instructions getting curl, see section Getting curl below.

For instructions getting openssl, see section Getting OpenSSL below.

You will also find further useful tools under section Where can I get the tools I need? below.

For concrete testing instructions, please see section How to verify if my root certificates store needs an update.

Testing your default root certificates store

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

Verifying the trusted Google root CA bundle

Download the trusted Google root CA bundle, then follow these steps:

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

How and when will the Google root CA migration continue?

  1. First phase (migrating to GS Root R2), announced in January 2017, started in late 2017 and wrapped up in the first half of 2018.
  2. Second phase (migrating to GTS Root R1 Cross) was announced in March 2021, and will roll out over the coming months, before the expiration of GS Root R2 on December 15, 2021.

Schedules of eventual later migration phases will be announced well in advance of future certificate expirations.

However, you will be able to future proof your apps, if you keep your root certificates store in sync with the curated list of root CAs in the trusted Google root CA bundle.

Also see question Why should I keep my root certificates store in sync with the trusted Google root CA bundle? for further background.

General rollout plan for each Google service

  1. The staged rollout starts in a single data center.
  2. The rollout is gradually extended to more data centers until there is global coverage.
  3. If serious issues are detected at any stage, the tests can be rolled back temporarily while the issues are addressed.
  4. 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 and future proof their services well in advance of possible Google root CA migration phases.

See section How to verify if my root certificates store needs an update for additional guidance.

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?

Google Maps Platform certificates employ DNS Subject Alternative Names (SANs), so a client's certificate handling must be able to support SANs that may include a single wildcard as the left-most label in the name, such as *.googleapis.com.

For other requirements, please refer to section What are the recommended requirements for a TLS client to communicate with Google? in the GTS FAQ.

Which kinds of applications are at risk of breaking?

The application uses the system root certificates 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 10 or Server 2019, OS X) that is still maintained and receives regular updates, your default root certificates store should already include the GTS Root R1 certificate.

If you are using a legacy OS version that no longer receives updates, you may or may not have the GTS Root R1 certificate. However, your root certificates store will most likely contain GlobalSign Root CA - R1, one of the oldest and most widely trusted root CAs.

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

Client-side Google Maps Platform applications

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

For native mobile applications using any of Maps SDK for Android, Maps SDK for iOS, Places SDK for Android or Places SDK for iOS, the same rules apply as for apps calling the Google Maps Platform web services.

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

The app 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 Why should I keep my root certificates store in sync with the trusted Google root CA bundle?, we recommend you import all certificates from the trusted Google root CA bundle into your own root certificates 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?.

Why should I keep my root certificates store in sync with the trusted Google root CA bundle?

The curated list of root CAs in the trusted Google root CA bundle includes all CAs that may plausibly be used by Google services in the foreseeable future.

Therefore, if you wish to future proof your system, we strongly recommend that you verify that your root certificates store contains all the certificates from the bundle, and make a habit of keeping the two in sync.

This is especially important if your services run on an unmaintained operating system version, you are for other reasons unable to keep your operating system and libraries patched up, or you maintain your own root certificates store.

See question How can I get advance notification of future migrations? to find out how to get updates about future root CA migrations. Routinely keeping your root certificates store in sync with the curated list will safeguard your services against future service interruptions, due to CA changes, and will keep your services running beyond the expiration of both GTS Root R1 Cross and GlobalSign Root CA - R1.

Also, please refer to question I'm building a product that connects to Google services. What CA certificates do I need to trust? in the GTS FAQ for further recommendations.

Why should I not install any leaf or intermediate CA certificates?

Doing so will risk breaking your application at any point we enroll a new certificate, or switch intermediate CAs. Either of these may happen at any time and without any prior notice, and it applies equally to individual server certificates, such as those served by maps.googleapis.com, as well as any of our intermediate CAs, such as GTS Root R1 Cross.

To shield your services against this, you should only install root certificates from the trusted Google root CA bundle, and rely on the root certificate alone to verify the trustworthiness of the entire certificate chain anchored to it.

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 JavaScript applications at risk of breaking?

The GTS root certicates are already well embedded and trusted by most modern browsers, and the cross-sign from GMO GlobalSign should ensure a smooth migration even for most end users on legacy browsers. This includes all officially supported browsers for Maps JavaScript API.

Every modern browser should allow end users to verify and usually edit which certificates the browser trusts. Although the exact location differs with each browser, the list of certificates can typically be found somewhere under Settings.

Are mobile apps at risk of breaking?

Android and Apple iOS devices still receiving regular updates from the device manufacturer are also expected to be future proof. Most older Android phone models include at least the GlobalSign Root CA - R1 certificate, although the list of trusted certificates may vary per handset manufacturer, device model and Android version.

However, support for the GTS root CAs, including GTS Root R1 may still be limited in Android versions prior to 10.

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 GlobalSign Root CA - R1.

GTS root CAs, including GTS Root R1 have been supported since iOS version 12.1.3.

See question 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 has over the last years worked extensively 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.

It is therefore very likely that any currently maintained system already support Google's new GTS Root CAs, including GTS Root R1, and even legacy systems are highly likely to support GlobalSign Root CA - R1, which will be used for cross-signing Google-issued certificates through the next years.

However, 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, Tshark or Tcpdump

While most Linux distributions offer wireshark, its command-line tool tshark and tcpdump, pre-compiled versions of the first two 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.

Documentation for these useful tools can be found in the Wireshark User's Guide, on the Tshark man page and on the Tcpdump man page, respectively.

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 trusted Google root CA bundle into the root certificates store your application uses.

  1. Work together with your system administrators to upgrade your local root certificates 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. Note: For platform-specific issues, guidance is only provided on a best effort basis.
  5. Star public issue 186840968 for further migration related updates.

Reaching out to Google Maps Platform support

Initial troubleshooting

See section How to verify if my root certificates store needs an update for generic troubleshooting instructions.

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:

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

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

Filing a support case

Please follow the instructions for Creating a support case under Google Maps Platform Support and Resources.

When filing a support case, in addition to the data listed in section Initial troubleshooting, please also provide the following:

  • What are your public IP addresses?
  • What is the public IP address of your DNS server?
  • If possible, a tcpdump or Wireshark packet capture of the failed TLS negotiation against https://maps.googleapis.com/ in PCAP format, using a sufficiently large snapshot-length to capture the entire packet without truncating it (e.g. using -s0 on older versions of tcpdump).
  • If possible, logs excerpts from your service showing the exact TLS connection failure reason, preferably with full server certificate chain information.

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

Posting on public issue 186840968

When posting a comment on public issue 186840968, please include the information listed in section Initial troubleshooting.

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 to interpret the curl output

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 root certificates store, but the exact output may vary per system as shown here.

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/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

User agent

Outgoing requests contain the User-Agent header, which 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 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

Failed TLS handshake

Lines, such as the ones in this code sample, 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 in this code sample. 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:

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

How to print the received server certificates in human readable form

Presuming the output is PEM formatted, e.g. the output from openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, you can print out the served certificate following these steps:

  • Copy the entired Base 64 encoded certificate, including header and footer:

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • Then do:

    openssl x509 -inform pem -noout -text
````

  • Then paste the contents of your copy buffer into the terminal.

  • Hit the Return key.

For example input and output, see section How to print PEM certificates in human readable form.

What do cross-signed Google certificates look like in OpenSSL?

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

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

---
…

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 apps at risk of breaking?, Android has since version 4.0 allowed handset users to verify the list of trusted certificates under Settings. This table 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

This table 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, where system images were no longer available:

Android version GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (valid until Dec 15, 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Updating the Android system root certificates store is generally not possible without a firmware update or rooting the device. However, on most Android versions that are still in wide use, the current set of trusted root certificates 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:

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.

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

iOS version GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (valid until Dec 15, 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Where is my system root certificates store and how can I update it?

The location of the default root certificates 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
  • /var/lib/ca-certificates: OpenSUSE

Other certificate paths may include:

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

Some of the certificates in these directories are likely symbolic links to files in other directories.

OpenSSL root certificates store

For applications using OpenSSL, you can check the configured location of its installed components, including the default root certificates 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 root certificates store is located in the certs subdirectory.

ls -l /usr/lib/ssl/certs

lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs

…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

If OpenSSL relies on the default system root certificates store as in the example above, check the top-level section Where is my system root certificates store 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.

Java root certificates store

Java applications might use their own root certificates store, which on Linux systems is typically located at /etc/pki/java/cacerts or /usr/share/ca-certificates-java, which can be managed using the Java keytool command-line tool.

To import an individual certificate into your Java certificate store, issue the following command:

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

Just replace cert.pem with the certificate file corresponding to each recommended root certificate, alias with a unique but meaningful certificate alias, and certs.jks with the certificate database file used in your environment.

For further information, please refer to the following Oracle and Stack Overflow articles:

Mozilla NSS root certificates store

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 your NSS database, use the certutil tool.

To import an individual certificate file into your NSS database, issue the following command:

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

Just replace cert.pem with the certificate file corresponding to each recommended root certificate, cert-name with a meaningful certificate nickname, and certdir with the certificate database path used in your environment.

For further information, please refer to the official NSS Tools certutil manual, as well as your operating system documentation.

Microsoft .NET root certificates store

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

Certificate file formats

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 specification 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 to 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 encoding.

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, e.g., Java keytool, may only import a single certificate from a PEM file, even if it contains several. See question How do I extract individual certificates from roots.pem? to see how the file can first be split up.

How do I extract individual certificates 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}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

This should create a number of individual PEM files similar to the ones listed here:

ls -l *.pem

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

The individual PEM files, such as 02265526.pem can then be imported separately, or further converted into a file format your certificate store accepts.

How to 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 to 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 to 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 to 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 creating 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.

Listing, printing and exporting certificates from your root certificates store

How do I export a certificate from the Java Key Store as a PEM file?

Using keytool you can issue the following command to list all certificates in your certificate store, together with the alias you can use to export each one:

keytool -v -list -keystore certs.jks

Just replace certs.jks with the certificate database file used in your environment. This command will also show the alias of each certificate, which you will need if you wist to export it.

To export an individual certificate in PEM format, issue the following command:

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

Just replace certs.jks with the certificate database file used in your environment, and provide an alias and alias.pem corresponding to the certificate you wish to export.

For further information, please refer to the Java Platform, Standard Edition Tools Reference: keytool manual.

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

Using certutil you can issue the following command to list all certificates in your certificate store, together with the nickname you can use to export each one:

certutil -L -d certdir

Just replace certdir with the certificate database path used in your environment. This command will also show the nickname of each certificate, which you will need if you wist to export it.

To export an individual certificate in PEM format, issue the following command:

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

Just replace certdir with the certificate database path used in your environment, and provide a cert-name and cert.pem corresponding to the certificate you wish to export.

For further information, please refer to the official NSS Tools certutil manual, as well as your operating system documentation.

How to print PEM certificates in human readable form

In the following examples we presume you have the file GTS_Root_R1.pem with the following contents:

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

Issuing the command

openssl x509 -in GTS_Root_R1.pem -text

should output something similar to:

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

For instructions getting openssl, see section Getting OpenSSL.

Printing certificates using Java keytool

Issuing the following command

keytool -printcert -file GTS_Root_R1.pem

should output something similar to:

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

Extensions:

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

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

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

For instructions getting keytool, see section Getting Java keytool.

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

This varies per operating system and SSL/TLS library. However, the tools that allows importing and exporting certificates to and from the root certificates 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 root certificates 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 trusted Google root CA bundle):

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

The file may also just contain the certificate part. In such cases, the name of the file, such as GTS_Root_R1.pem may describe which CA the certificate belongs to. The certificate string between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tokens is also guaranteed to be unique for each CA.

However, even if you lack the above tools, as each certificate in the trusted Google root CA bundle is properly labeled, you can reliably match the root CAs from the bundle aganist the ones from your root certificates store either by Issuer, or by comparing PEM file certificate strings.

Web browsers may use their own root certificates store, or rely on the default one provided by the operating. However, all modern browsers should allow you to manage or at least view the set of root CAs they trust. See question Are JavaScript applications at risk of breaking? for further details.

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 Google Trust Services FAQ.

For further details about advanced topics, such as certificate pinning, you may find the Open Web Application Security Project (OWASP) Certificate and Public Key Pinning article and Pinning 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 vs. 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 JeroenHD's 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.