CA change resulting in errors when trying to communicate with Auth0.
Starting November 1, 2022, Auth0 certificates will be signed by one of the following certificate authorities: Let’s Encrypt and Google Trust Services. Certificates used by Auth0 (including those existing for all Auth0 domains and Custom Domains feature) may be replaced with certificates signed with the above CAs.
Encryption and Certificate Authorities
In simplified terms, in order to establish a secure, encrypted session (via Transport Layer Security “TLS”) and make successful API requests, first a client must be able to verify the identity of the server. Verification is performed by checking the server name against a list of certificates in what’s called a
TrustStore. Clients trust these Certificate Authority (CA) root certificates in the TrustStore by default.
This list of trusted CAs is not static and changes over time. New CAs can be introduced by major cloud, service, and security vendors. In some cases, CAs are removed from the list due to security incidents (https://en.wikipedia.org/wiki/DigiNotar). Security best practice is to keep the list of Certificates up to date.
CA Root Certificates in the TrustStore
Auth0 is currently using LetsEncrypt and will soon adopt Google Trust Services (in 2023) as Certificate Authorities. The following root certificate public must be present. Most modern operating systems have these installed, older operating systems or unpatched older operating systems might not have them.
What: LetsEncrypt (current)
Name: ISRG Root X1
Google Trust Services (GTS):
- was included in the initial announcement as a new Certificate Authority. Auth0 is not using it as a CA currently.
- is intended to be offered as an alternative and backup to LetsEncrypt however a final decision is still pending
- We have included GTS root CA details for completeness to enable customers to verify their operating systems and app runtime are compatible. GTS root CAs are present in any modern trust store.
How do I prepare for these additional Certificate Authorities?
Check your operating system and application runtime truststores
Operating systems have a CA truststore and some application runtimes - like Java and Node.JS - have their own truststore independent from the operating system. In both cases, the truststores need to have the appropriate root CAs.
- Ensure operating systems and application runtimes are running recent versions (not the end of life!) so their truststores are up-to-date
- verify of “ISRG Root X1” and “Google Trust Services” root CAs are present in your truststores
Validate your application does not use certificate pinning
Some customer applications implement certificate pinning (explained in detail here: https://sectigo.com/resource-library/what-is-certificate-pinning): they contain configuration or application logic that insists on specific certificate details like the certificate’s serial number, fingerprint, or Common Name.
Certificate pinning is not a best practice. Instead, the application validate a connection is secure by relying on TLS and certificate validation (using an up-to-date truststore).
- verify your application logic relies on certificate validity and not specific certificate details
Test an authentication request using Auth0
All Auth0 tenants using the hostname pattern
auth0.com are using certificates signed by the new Certificate Authorities. Test your application by attempting to fetch your tenant’s JWKS keyset and confirming your application runtime retrieves them successfully.
Operating Systems and Application Runtimes that Require Action
LetsEncrypt may not be in the truststore of older operating systems and application runtimes. According to Certificate Compatibility (https://letsencrypt.org/docs/certificate-compatibility/#platforms-that-trust-dst-root-ca-x3-but-not-isrg-root-x1), this affects:
- macOS < 10.12.1
- iOS < 10
- Mozilla Firefox < 50
- Ubuntu >= intrepid / 8.10
- Debian >= squeeze / 6 (https://twitter.com/TokenScandi/status/600806080684359680) and < jessie /8
- Java 8 >= 8u101 and < 8u141
- Java 7 >= 7u111 and < 7u151
- NSS >= v3.11.9 and < 3.26
- Amazon FireOS (Silk Browser) (version range unknown)
- Cyanogen > v10 (version that added ISRG Root X1 unknown)
- Jolla Sailfish OS > v22.214.171.124 (version that added ISRG Root X1 unknown)
- Kindle > v3.4.1 (version that added ISRG Root X1 unknown)
- Blackberry >= 10.3.3 (version that added ISRG Root X1 unknown)
- PS4 game console with firmware >= 5.00 (version that added ISRG Root X1 unknown)
Additional Information for Auth0 Customers
- NodeJS has its own built-in trust store. Versions below < 8 have issues. See the answer section of LetsEncrypt root certificate expiry breaks Azure Function Node application (https://stackoverflow.com/questions/69445796/letsencrypt-root-certificate-expiry-breaks-azure-function-node-application) for upgrade instructions. Node v8 and higher fully support Letsencrypt without issues.
- Instructions for unpatched old OS versions of Windows, Mac : Certifytheweb - Clients (https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/#clients-browsers-etc)
Certificate expiry errorOpenSSL 1.0.2 results in a certificate expiration error while all certificates are actually valid. This version of OpenSSL has a bug (does not honor cross signing) that causes some root CAs to not be evaluated when determining whether a connection is secure or not.
- Upgrade OpenSSL to a recent version, or
- Workaround: remove expired certificate “DST Root CA X3” from the truststore.