General information
- What is happening?
- Why did I receive the mandatory service announcement?
- Why did I not receive any mandatory service announcement?
- Is the information posted anywhere publicly so I can share it?
- How do I get updates on this migration process?
- We use multiple Google services. Will the root CA migration affect all of them?
- How do I verify if my certificate store needs an update
- Where can I give feedback about the outreach campaign?
- Can I get the communications in my own language?
- How will the migration proceed?
- Which kinds of applications are at risk of breaking?
- Should I install any intermediate or subordinate certificates?
- Should I install all the root certificates from the Google sample PEM file?
- Are Google Maps JavaScript API applications at risk of breaking?
- Are mobile applications at risk of breaking?
- When will my browser or operating system include the Google Trust Services root certificates?
Troubleshooting
- Where can I get the tools I need?
- Our system is down because of the root CA migration! What can we do?
- What steps should I take before reaching out to support?
- What do the Google certificates look like in OpenSSL?
Managing your certificates and certificate store
- How can I check the trusted root certificates on my mobile phone?
- Where is my system certificate store located and how can I update it?
- How do I convert between a PEM file and a format supported by my system?
- How do I export certificates from the NSS certificate store as a PEM file?
- How do I print PEM certificates in human readable form?
- How do I see what certificates are installed in my certificate store?
Appendix
General information
What is happening?
The big picture
Google is working on a multi-year plan to issue and use its own root certificates, the cryptographic signatures which are the basis of TLS/SSL internet security used by HTTPS.
Currently, the TLS security of the Google Maps APIs is guaranteed by a root certificate issued by GeoTrust Global CA, a very well known and widely trusted certificate authority (CA) which is owned by Symantec. Practically all TLS clients (such as Web browsers, smartphones, and application servers) are aware of this root certificate, and therefore can use it to ensure that they have a secure connection to the Google Maps APIs servers.
By the early 2020s, Google plans to migrate all Google Maps API services to a root certificate issued by Google's own certificate authority, Google Trust Services (GTS).
As an interim step, in late 2017 the Maps APIs will migrate to another widely-trusted root certificate from GlobalSign (GS). Google has purchased the use of this root certificate (and the CA that GlobalSign used to issue it) in order to ease the certificate transition.
The vast majority of TLS clients already recognise the GlobalSign root certificate, so their usage of the Google Maps APIs will not be affected by this initial change.
However, especially in some specialist use cases such as embedded devices, or users working with very outdated legacy browsers or operating systems, it is possible that some clients will lack the GlobalSign root certificate. These clients will need to be updated with the certificate in order to be able to secure their Google Maps APIs connections. It is not possible for Google to identify these clients, so application owners must carry out any necessary verification on their own applications. Google Trust Services provides HTTPS test endpoints at GTS site to help with this. See below for more technical details.
Technical summary
As announced in the Google Maps API Premium Plan customer support portal on March 16 2017, and earlier on the Google Security Blog, Google has created its own root CA, GTS. Along with other Google services, the Google Maps APIs will gradually transition to TLS certificates signed by GTS root CAs.
As an interim step, Google has purchased the existing, widely-trusted GS Root R2 CA. The Google Maps APIs will migrate from the GeoTrust root certificate to this certificate in late 2017.
Almost all TLS clients are preconfigured with the GS Root R2 certificate or receive it via normal software updates, but, if an application connects to the Google Maps APIs from clients that may not recognize this certificate, the application developers should ensure that the clients are tested and if necessary updated with the certificate.
The GS Root R2 certificate and all GTS root certificates are available via the GTS site. For testing purposes, the GTS site also provides endpoints with TLS certificates signed by each CA. In particular, if your client can establish a TLS connection to GS Root R2 test endpoint then it trusts the GS Root R2 certificate and should not be affected by the upcoming change.
Google will rely on GS Root R2 CA at least through the end of 2018. After that, the Google Maps APIs may transition directly to the GTS CA, or may on occasion fall back to third-party root CAs including GS Root R3 CA.
Why did I receive the mandatory service announcement?
You received the mandatory service announcement email either because you either have previously interacted directly with Google Maps API technical support, or because your address is stored in our records as a technical contact point for your organization. In very rare cases, where we have no technical contact on record, we have reached out to customer contacts for whom we have no job description or title.
If you have received this message but you are not responsible for the technical maintenance of TLS-related issues, then we apologize and we ask that you please forward this message to your technical team.
As a Maps API Premium Plan customer you may also file a support case, if the FAQ does not provide sufficient guidance. While we will not be able to go into implementation details of your system, we can provide you general guidance. Any useful findings and generally applicable advice from support cases will be added to the FAQ.
Why did I not receive any mandatory service announcement?
The proactive outreach campaign was targeted to Google Maps API Premium Plan customers, but we may in the future extend also such campaigns to Standard Plan customers. Please take a moment to review your notification settings in the Google Cloud Console, as explained in the Cloud Platform Console Help article Manage notifications.How do I get updates on this migration process?
Please star the public issue, and make sure to regularly check this FAQ for updates!We use multiple Google services. Will the root CA migration affect all of them?
Yes, the root CA migration will happen across all Google services and APIs, but the timeline may vary per service. However, once you have verified that your application trusts the recommended set of root certificates listed in the Google sample PEM file, your application should be future proof during the root certificate migration, no matter which Google API or service it might call. See question Should I install all the root certificates from the Google sample PEM file? for further details.How do I verify if my certificate store needs an update
Test your application environment against the test endpoints listed together with each of the root CAs on the GTS site. If you are able to establish a TLS connection to the GS Root R2 test endpoint and Google certificate test sandbox, you will be fine at least through the end of 2018.
Therefore, we strongly recommend that you install now all certificates from the Google sample PEM file to future proof your system, unless you are certain that you will always manage to keep your production environment completely up to date and patched up.
Is there a simple tool I can use to verify our certificate store?
The command line tool curl
, available on most platforms, offers extensive options for
testing your setup. For instructions getting curl
, see section
Getting curl.
Testing your default certificate store
# Google certificate test sandbox $ curl -vvI https://cert-test.sandbox.google.com/ # GS Root R2 $ curl -vvI https://good.gsr2demo.pki.goog/ # GS Root R4 $ curl -vvI https://good.gsr4demo.pki.goog/ # GS Root R3 $ curl -vvI https://valid.r3.roots.globalsign.com/ # GTS Root R1 $ curl -vvI https://good.r1demo.pki.goog/ # GTS Root R2 $ curl -vvI https://good.r2demo.pki.goog/ # GTS Root R3 $ curl -vvI https://good.r3demo.pki.goog/ # GTS Root R4 $ curl -vvI https://good.r4demo.pki.goog/
Verifying the Google Root CA bundle
Download the Google sample PEM file, then follow the steps below:# Google certificate test sandbox $ curl -vvI --cacert roots.pem https://cert-test.sandbox.google.com/ # GS Root R2 $ curl -vvI --cacert roots.pem https://good.gsr2demo.pki.goog/ # GS Root R4 $ curl -vvI --cacert roots.pem https://good.gsr4demo.pki.goog/ # GS Root R3 $ curl -vvI --cacert roots.pem https://valid.r3.roots.globalsign.com/ # GTS Root R1 $ curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/ # GTS Root R2 $ curl -vvI --cacert roots.pem https://good.r2demo.pki.goog/ # GTS Root R3 $ curl -vvI --cacert roots.pem https://good.r3demo.pki.goog/ # GTS Root R4 $ curl -vvI --cacert roots.pem https://good.r4demo.pki.goog/
Where can I give feedback about the outreach campaign?
A link to a short survey was included in the email that was sent to the recipients of the mandatory service announcement.Can I get the communications in my own language?
English is the only official Google Maps API Support language. If you cannot find anyone in your organization that can explain the contents, Maps API Premium Plan customers have the option to file a support case. We have an international team, so we may be able to provide best effort support in your language.How will the migration proceed?
When will the migration occur?
The first migration phase, switching over to certificates issued by Google Internet Authority G3 (GIAG3) using GS Root R2, has started for the Google Maps APIs. However, due to issues reported by our customers, the rollout was temporarily on hold to give our customers more time to verify and update their systems.
The migration is currently scheduled to recommence on the week of Monday November 13, 2017, following the general outline described below. Initially only a small fraction of the traffic will be served using our new certificates issued by GIAG3, but the ratio increases with each data center included in the rollout. The GS Root R2 rollout is expected to last at least a few months, until all data centers serving Maps APIs have switched over to the new certificates. However, most Google Maps API users are still expected to receive the old-style certificates issued by Google Internet Authority G2 (GIAG2) using the Google's root CA until the end of 2017.
The schedules of later migration phases will be announced in the coming years, but well in advance of the GS Root R2 2021 certificate expiration.
General rollout plan for each Google service
- The staged rollout starts in a single data center.
- The rollout is gradually extended to more data centers until there is global coverage.
- If serious issues are detected at any stage, the tests can be rolled back temporarily while the issues are addressed.
- Based on input from previous iterations, further Google services are included in the rollout until gradually all Google services have migrated to the new certificates.
Who will be affected, when, and where?
Increasing numbers of Google Maps API developers will start to receive the new certificates as new data centers are migrated over. The changes will be somewhat localized, as client requests tend to be forwarded to servers in geographically nearby data centers. As we cannot with certainty in advance say who will be affected, when and where, we recommend all our customers verify their systems before the certificate change starts rolling out.What to look out for
Clients that are not configured with the necessary root certificate will not be able to verify their TLS connection to the Google Maps APIs. In this situation, clients will typically issue a warning that certificate validation has failed. Depending on their TLS configuration, clients may continue to issue a Maps API request, or they may refuse to continue with the request.In case of systematic failures
See question Our system is down because of the root CA migration! What can we do?.Which kinds of applications are at risk of breaking?
The application uses the system certificate store without any developer imposed restrictions
Maps API web service applications
If you are using a mainstream OS, e.g., Ubuntu, Red Hat, Windows 7+ or Server 2008+, OS X) that is still maintained and receives regular updates, your default certificate store should already include the GS Root R2 certificate.
If you are using a legacy OS version that no longer receives updates, you may or may not have the GS Root R2 certificate. For example, Windows XP SP2 includes the certificate, but Windows XP SP1 does not. Legacy devices should be tested to ensure that they trust the certificate.
For mobile applications calling Google Maps API web services directly from the end user device, guidelines from question Are mobile applications at risk of breaking? apply.
Client-side Maps API applications
Google Maps Javascript API applications rely on the root certificates of the web browser running the application. See section Are Google Maps JavaScript API applications at risk of breaking? for more further details.
For native mobile applications using the Google Maps Android API or Maps SDK for iOS, the same rules apply the same guidelines as for apps calling the Google Maps API web services.
See question Are mobile applications at risk of breaking? for more details.
The application uses its own certificate bundle, or uses advanced security features, such as certificate pinning
You will need make sure to to update your certificate bundle yourself. As discussed under question Should I install all the root certificates from the Google sample PEM file?, we recommend you import all root certificates from the Google sample PEM file into your certificate store.
If you are pinning certificates or public keys for the Google domains your application connects to, you should add the certificates and public keys to the list of trusted entities in your application.
For further information about certificate or public key pinning, refer to the external resources listed under question Need more info?.
Should I install any intermediate or subordinate certificates?
You should only install the root certificates from the Google sample PEM file, and rely on certificate chains anchored in these to verify the authenticity of any subordinate certificates. This applies equally to server certificates (e.g. those used by host maps.googleapis.com), as well as any of our intermediate certificate authorities (e.g. GIAG2 and GIAG3).
Any modern TLS library implementation should be able to automatically verify such chains of trust, as long as the root certificate authority is trusted.
Should I install all the root certificates from the Google sample PEM file?
If you wish to future proof your system now in one go, we recommend that you install all certificates from the Google sample PEM file if you do not regularly and routinely apply operating system updates to your system, or if you for example maintain your own certificate bundles for your application.
Are Google Maps JavaScript API applications at risk of breaking?
The GlobalSign R2 root CA is well embedded, and trusted by most modern browsers. Therefore, it is likely that these browsers will continue to be able to connect to Google services for some time. If the browser is actively maintained, it is also almost certain that it will at some point also support all other Google root CAs.
However, the Google Maps JavaScript API itself is only guaranteed to work on supported browsers, so we recommend using one of the listed browsers and keeping the browser up to date to ensure problem free use.
Are mobile applications at risk of breaking?
Android and Apple devices still receiving regular updates from the device manufacturer are also expected to be future proof. Most older Android phone models already include at least both the GS Root R2 and GS Root R3 certificates, although the list of trusted certificates may vary per handset manufacturer, device model and Android version. Newer Android Open Source Project (AOSP) versions used on Google Nexus and Pixel branded devices also trust GS Root R4 by default. Support for the GTS Root CAs is still minimal in any of the released Android versions.
For iOS devices, Apple maintains a list of trusted root CAs for each recent iOS version on its support pages. However, all iOS versions 5 and up support GS Root R2 and R3, versions 7 and up also GS Root R4. As with current Android versions, GTS Root CAs are not yet supported at the time of writing.
See section How can I check the trusted root certificates on my mobile phone? for further details.
When will my browser or operating system include the Google Trust Services root certificates?
Google is working with all major third parties maintaining widely used and trusted root certificate bundles. Examples include operating system manufacturers, such as Apple and Microsoft, but also Google's own Android and ChromeOS teams; browser developers, such as Mozilla, Apple, Microsoft, but also Google's own Chrome team; manufacturers of hardware, such as phones, set-top boxes, TVs, game consoles, printers, just to name a few.
As third-party certificate inclusion timelines are largely beyond the control of Google, the best general advice we can offer is to make sure you regularly apply available system updates. Select third parties, such as Mozillaʼs CA Certificate Program may have documented their own certificate inclusion timelines.
Troubleshooting
Where can I get the tools I need?
Getting curl
If your OS distribution doesn't providecurl
, 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 provideopenssl
, 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 ofwireshark
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
Thekeytool
command line tool should be shipped with every Java
Development Kit (JDK) or Java Runtime Environment (JRE) version. Install these
to get keytool.
However, using keytool
is unlikely
necessary for root certificate verification, unless your application is built
using Java.
Our system is down because of the root CA migration! What can we do?
The primary course of action for you is to install the required root certificates from the Google sample PEM file into the certificate store your application uses. However, you may still find useful information section Managing your certificates and certificate store.- Try upgrading your certificate store.
- Perform initial troubleshooting steps as explained under question What steps should I take before reaching out to support?.
- Google Maps API Premium Plan customers should file a support case.
- Google Maps API Standard Plan customers should post a comment on the public issue.
- Star the public issue for status updates.
What steps should I take before reaching out to support?
Verifying your system before the root CA migration
See question How do I verify if my certificate store needs an update for further details. Section Managing your certificates and certificate store may also provide valuable information, if you end up needing to import or export root certificates.How can I determine the public address of my DNS?
On Linux, you can run the following command:dig -t txt o-o.myaddr.l.google.comOn 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?
Runningcurl
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 thatcurl
sends. - Lines starting with '
<
' display the HTTP response it gets from the server. - If the protocol was HTTPS, the presence of '
>
' or '<
' lines imply a successful TLS handshake.
Used TLS library and root certificate bundle
Running curl
with the -vvI
flags also prints out the
used certificate store, but the exact output may vary per system as shown below.
Output from a Red Hat Linux machine with curl
linked against NSS
may contain these lines:
* Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none
Output from an Ubuntu Linux machine may contain these lines:
* successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs
Output from an Ubuntu Linux machine using the Google root certificate PEM file
given using the --cacert
flag may contain these lines:
* successfully set certificate verify locations: * CAfile: /home/<username>/Downloads/roots.pem CApath: /etc/ssl/certs
User agent
Outgoing requests contain the User-Agent header that may provide useful
information about curl
and your system.
An example from a Red Hat Linux machine:
> HEAD / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: cert-test.sandbox.google.com > Accept: */* >
Failed TLS handshake
Lines, such as the ones below indicate the connection was terminated mid-TLS-handshake because of an untrusted server certificate. The absence of debug output starting with '>
' or '<
' are also
strong indicators of an unsuccessful connection attempt:
* SSLv3, TLS alert, Server hello (2): * SSL certificate problem: unable to get local issuer certificate * Closing connection 0
Successful TLS handshake
A successful TLS handshake is indicated by the presence of similar looking lines to the ones below. The cipher suite used for the encrypted connection should be listed, as should details of the accepted server certificate. Furthermore, the presence of lines starting with '>
' or '<
' indicate
that payload HTTP traffic is being successfully transmitted over the TLS
encrypted connection:
* SSLv3, TLS handshake, Finished (20): * SSL connection using ECDHE-ECDSA-AES128-GCM-SHA256 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.googleapis.com * start date: 2017-09-07 11:07:47 GMT * expire date: 2017-11-30 10:54:00 GMT * subjectAltName: maps.googleapis.com matched * issuer: C=US; O=Google Inc; CN=Google Internet Authority G2 * SSL certificate verify ok. > HEAD / HTTP/1.1 > User-Agent: curl/7.35.0 > Host: maps.googleapis.com > Accept: */* > < HTTP/1.1 302 Found
What do the Google certificates look like in OpenSSL?
Managing your certificates and certificate store
How can I check the trusted root certificates on my mobile phone?
Android certificate store
As mentioned under question Are mobile applications at risk of breaking?, Android has since version 4.0 allowed handset users to verify the list of trusted certificates under Settings. The table below shows the exact Settings menu path:
Android version | Menu path |
---|---|
1.x, 2.x, 3.x | N/A |
4.x, 5.x, 6.x, 7.x | Settings > Security > Trusted credentials |
8.x | Settings > Security & Location > Encryption & credentials > Trusted credentials |
The table below illustrates the likely availability of the most critical root certificates per Android version, based on manual verification using currently available Android Virtual Device (AVD) system images, falling back to the AOSP ca-certificates Git repository version history whenever system images are no longer available:
Android version | GS Root R2 | GS Root R3 | GS Root R4 | GTS |
---|---|---|---|---|
2.3, 3.2, 4.x, 5.0 | ||||
5.1, 6.x, 7.x, 8.x |
Updating the Android system certificate store is generally not possible without a firmware update or rooting the device. However, the current set of trusted root certificates on most still widely used Android versions is likely to provide uninterrupted service for multiple years to come, beyond the effective lifetime of most currently existing devices.
Beginning with version 7.0, Android offers application developers a secure method for adding trusted certificates which are only trusted by their application. This is done by bundling the certificates with the application and creating a custom network security configuration, as described in the Android Best Practices for Security & Privacy Network Security Configuration training document.
However, as third-party application developers will not be able to influence the network security configuration of traffic originating from the Google Play Services APK, such efforts would likely only provide a partial workaround.
On older legacy devices, your only available option would be to rely on user-added CAs, either installed by a corporate group policy applied to the end user device, or by the end users themselves.
iOS Trust Store
While Apple does not directly show its default set of trusted root certificates to the handset user, the company has links to the sets of trusted root CAs for iOS versions 5 and up from the Apple Support articles Lists of available trusted root certificates in iOS and iOS 5 and iOS 6: List of available trusted root certificates.
However, any additional certificates installed on the iOS device should be visible under Settings > General > Profile. If no additional certificates are installed, the Profile menu item may not be displayed.
The table below illustrates the availability of the most critical root certificates per iOS version, based on the above sources:
iOS version | GS Root R2 | GS Root R3 | GS Root R4 | GTS |
---|---|---|---|---|
5, 6 | ||||
7, 8, 9, 10, 11 |
Where is my system certificate store located and how can I update it?
The location of the default certificate store varies with operating system and
used SSL/TLS library. However, on most Linux distributions, the default root
certificates can be found under one of the following paths:
/usr/local/share/ca-certificates
(Debian, Ubuntu, older RHEL and
CentOS versions) , /etc/pki/ca-trust/source/anchors
and
/usr/share/pki/ca-trust-source
(Fedora, newer RHEL and CentOS
versions) or /var/lib/ca-certificates
(OpenSUSE). Other certificate
paths may include /etc/ssl/certs
(Debian, Ubuntu) or
/etc/pki/tls/certs
(RHEL, CentOS). Some of the certificates in
these directories are likely symbolic links to files in other directories.
Applications using Mozilla
NSS may by default also use a system-wide certificate database typically located under
/etc/pki/nssdb
, or a user-specific default
store under ${HOME}/.pki/nssdb
. For updating NSS, check out the
certutil
tool documentation
for how to add new certificates, as well as the official OS documentation.
Windows .NET developers may find at least the following Microsoft articles useful for updating their certificate store: Working with Certificates, Manage Trusted Root Certificates.
Java applications may use their own certificate store, which on Linux systems is
typically located at /etc/pki/java/cacerts
or
/usr/share/ca-certificates-java
. Please refer to the following
Stack Overflow and Oracle articles for help updating your Java certificate store
using the Oracle keytool
command line tool:
How
to properly import a selfsigned certificate into Java keystore that is available
to all Java applications by default?, How
to obtain the location of cacerts of the default java installation?,
How do I convert between a PEM file and a format supported by my system?
The Stack Overflow article Convert
.pem to .crt and .key explains how to use the Linux openssl
command line tool to convert between PEM and CRT+KEY, DER, P12 and other file
formats. For a full list of available options, check the officialOpenSSL Command Line Utilities
documentation.
For instructions getting openssl
, see section
Getting OpenSSL.
How do I convert a PEM file to P12?
Usingopenssl
you can issue the following command convert a file from PEM to
PKCS #12:
openssl pkcs12 -info -in roots.p12
You need to provide a file password when created a PKCS #12 archive, make sure to store the password somewhere safe, if you don't immediately import the PKCS #12 file into your system.
How do I export certificates from the NSS certificate store as a PEM file?
Check out the Mozilla NSScertutil
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 fileGlobalSign_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 commandopenssl x509 -in GlobalSign_Root_CA_-_R2.pem -textshould 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.pemshould 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.