FAQ for Certificate Changes

We expect to keep this FAQ updated, so please check back if you don’t see the answer to your question.

What are the recommended minimum requirements for a TLS client communicating with Google

  1. Support for TLS 1.2.
  2. A Server Name Indication (SNI) extension that contains the domain that's being connected to.
  3. Support for the cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 using the NIST P-256 curve (a.k.a “secp256r1”) and uncompressed points.
  4. At a minimum, trust the certificates listed at https://pki.goog/roots.pem.
  5. Support for DNS Subject Alternative Names (SANs) by the certificate verifier, where SANs may include a single wildcard as the left-most label in the domain name.

Why has the intermediate CA cert been changing? Can we hardcode it in our software?

Depending on business needs and technology changes, we may regularly change our intermediate certificate authority used for signing SSL server certificates. The current intermediate certificate authority or root certificate authority should never be relied upon as static.
Hardcoding CA certificate is the wrong way to fix the problem. Certificates can change on a moment’s notice, and software that uses them must be prepared to deal with that. While in the past, Root certificates have not changed, that is less likely in the future. CAs are now under attack and the compromise of a CA’s Root certificate would require revocation. Also, compromised CAs have had all of their Roots revoked. So, the only way to do this correctly is to build software that understands that Roots can change, and can adapt to that.

We use the SSL stack on (whatever). Is that one OK?

Unfortunately, we don’t know. So, you will need to test it. Typically, it is not the stack itself that is broken, but rather that Root certificates are hard-coded and cannot be updated. That said, if you are using an older stack, there may be issues with SANs or SNI.

What desktop OSes could have problems?

Windows Vista, 7 and 8 will phone home to get updated Roots if the chain goes back to a Root they do not recognize. XP, prior to Service Pack 2, does not, but the latest updated version does trust the root certificate we will be using.

What devices have problems?

In general, any device that does not do proper certificate validation OR hard-codes the Root it expects to see - especially if there is no update mechanism. This can include phones, printers, set-top boxes, cameras, and apps that do their own certificate validation separate from the underlying operating system.

Can you be more specific? How about phones?

iOS and Android OSes update their root stores as part of OS updates. However, this does not necessarily mean that phones with these OSes are immune from problems. For example, the Qualcomm modem firmware in a recent model Android phone had hard-coded the Root Certificate they expected to see when fetching AGPS data. While there was no problem in the Android OS, the Qualcomm firmware did not use the operating system certificate store for validation. Instead, they had hard-coded the Root they expected to see in the modem firmware, and when the Root changed, AGPS functionality broke.

How about set-top boxes?

Most set-top boxes manufactured in the last two years have the ability to connect to the Internet, so they can show movies from Hulu, Netflix, YouTube, etc. If these devices properly validate the certificate chain, and have the ability to update the Roots they trust, then they should continue to work. If not, whatever they are unable to do will need to be corrected. Fortunately, most set-top boxes have a way to update their firmware in a relatively painless manner. The principal concern here is the lead time required to make changes and push updates.

How about gaming consoles?

Recent gaming consoles also have the ability to show movies (YouTube, Netflix, etc) in addition to gaming. The answer here is basically the same as for set-top boxes.

How about printers?

Printers usually do not have an off-the-shelf OS which can update its own Root certificates. Therefore, these devices often select the Root certificate and hard-code that in firmware. This may be for some combination of ease and a belief that Roots are long-lived and do not change. Unfortunately, this then requires a firmware update if the Root changes. A better approach for these systems is to build a mechanism that provides for periodic updating from some master site. It is also likely that they did not build in the capability to handle other, newer SSL features like SANs and SNI.

What about cameras?

This would only be a problem for cameras that provided the capability to connect to the Internet (i.e., to automatically upload pictures). Even more than printers, we would expect that camera manufacturers did not build in the ability to update the Roots they trust. Also likely is that they did not build in the capability to handle other, newer SSL features like SANs and SNI. Unfortunately, low-end cameras are likely not to have provided any way to update their firmware, so any change that invalidates the assumptions used when that firmware was created, will cause the camera to fail when attempting a secure connection. Higher end cameras may have ways to update, but these are usually manual and/or offline. Until the user updates, these will also experience https connection problems.

What roots should we trust for connecting to Google?

Google provides a sample PEM file which includes the Google Trust Services owned and operated roots as well as other roots that may be necessary now, or in the future to communicate with and use Google products and services.

How can I test SNI?

https://googlemail.com is a URL that should only validate if you are sending SNI.

Is there some document I can give partners that describes the requirements for using SSL to connect to our services?

Is there somewhere we can test clients to see if they work correctly?