Upcoming change to TLS certificates: Addition of Google Trust Services with Let's Encrypt

MongoDB Atlas requires Transport Layer Security (TLS) encryption for customer data and intra-cluster network communications. MongoDB Atlas uses Let’s Encrypt as the Certificate Authority (CA) for TLS certificates for all clusters.

Starting in June of 2025, we are adding Google Trust Services as an additional Certificate Authority for Atlas clusters to improve availability. You must ensure that your application recognizes certificates from both Let's Encrypt and Google Trust Services before this change:

You cannot control the timing of the TLS CA change; however, it will respect your configured project maintenance window.

For your reference, the root CA certificates for the Google Trust Store can be found at https://pki.goog/repository/ under the "Root CAs" section.

You can verify whether these certificates are already included in your environment by following these steps:

You can also use the following command which will establishes a secure TLS connection to the MongoDB Atlas cluster and retrieve the SSL/TLS certificates presented by the server. It helps in verifying the certificate chain.

Note: Replace <node_hostname> with the hostname of any primary or secondary node in your cluster. You can find these details in the "View Monitoring" or METRICS tab in the Atlas UI (for example, clustername-shard-00-01.xxxxx.mongodb.net).

The location of the default root certificates store varies depending on operating system and SSL/TLS library used. However, on most Linux distributions, the default root certificates can be found under one of the following paths:

Other certificate paths may include:

Some certificates in these directories are likely symbolic links to files in other directories. You can use the steps mentioned above to check for the presence of GTS Root Certificates on your Linux machines.

To verify certificates in the Local Machine Trusted Root Certification Authorities store on a Windows system, you can use the following PowerShell command:

You can also check the Trusted Root Certification Authorities Certificate Store through the Windows GUI. For detailed instructions, see the Azure documentation on Trusted Root Certification Authorities Certificate Store.

Note: For App Services and Cloud Functions that are Azure cloud offerings, we recommend reaching out to Azure support. They can provide assistance in verifying CA certificate details from the backend environment.

If your application is hosted on AWS (EC2 machine), you can check if the required CAs are already available in your environment by running the following command from the environment's CLI:

Alternatively, if you're using AWS Certificate Manager, see the official AWS documentation to list the certificates.

Note: If your application server is running inside a container (AWS ECS/EKS) or using AWS Lamda, you must contact AWS support to verify whether the container/pod's trust store contains the GTS Root R1, R2, R3 and R4 certificates.

Java applications might use their own root certificates store or maintain their own set of trusted CAs. However, not every Java release contains the GTS Root R1, R2, R3 and R4 CA certificate.

The following table lists each Oracle Java version that does include the GTS Root R1, R2, R3 and R4 CA certificates.

Note: For some Java versions, the GTS certificates were only added in a later patch release.

We suggest checking if GTS Root R1, R2, R3 and R4 certificates are already listed in your Java trust store using the keytool (for Solaris, Linux, or macOS; or Windows). For additional details, see the Java-Security documentation.

Note: The following sections are based on the documentation for Oracle JDK, so some parts may be inapplicable to your JDK or to the custom TLS/SSL implementation you use.

See the Enable TLS/SSL on a Connection in Java documentation for more details. For Kotlin based applications, see the Enable TLS/SSL on a Connection documentation.

See the Configure Transport Layer Security (TLS) with Python documentation for more details.

Similar to Java, Node.js maintains its own set of trusted CAs, but not every Node.js release contains the GTS Root R1, R2, R3 and R4 CA certificate.

The following table lists each Node.js version that does include the GTS Root R1, R2, R3 and R4 CA certificates.

Note: For some Node.js versions, the GTS certificates were only added in a later patch release.

As previously mentioned, Node.js maintains its own list of trusted root certificates accessible through the tls.rootCertificates property. This property returns an array of PEM-encoded certificates. You can iterate through this array to check for specific certificates, such as GTS Root R1, R2, R3 and R4.

Example script:

See the Node.js tls.rootCertificates Property documentation for more details.

The MongoDB drivers usually rely on the operating system's trust store (such as Windows or Linux) to validate TLS certificates, unless a custom trust store is configured for your application. If the required certificates are already included in your environment's trust store, no additional action is necessary.

Some network devices, such as firewalls or proxies, might intercept SSL connections for monitoring or filtering and present their own certificates instead of the ones from MongoDB Atlas. If these CAs are not in the trust store, you may experience an SSLHandshakeException error.

The above changes apply to all Atlas dedicated tier clusters.

MongoDB is onboarding Google Trust Service (GTS) as an alternative CA for Atlas. It will be actively used with Let's Encrypt Certificate Authority at no additional cost.

We will start making the changes from June 2025 onwards.

In a cluster, TLS certificates will be signed by Let’s Encrypt for some nodes and by Google Trust Services for others. Certificates will not be cross-signed.

For database users leveraging X.509 certificate-based authentication within MongoDB, there is no impact. X.509 certificates are used for authenticating users accessing the MongoDB database, and this process is distinct from the TLS certificates used for securing data in transit.

If the certificates are not present with either Java JDK or Node.js bundle, then it will not do a lookup on the system-hosted CA.

To clarify, if the Google Trust Services (GTS) certificates are not bundled with the Java JDK or Node.js runtime being used, those applications might not automatically fall back to the system-hosted Certificate Authority (CA) store for verification. This means that applications using these runtimes could fail TLS connections to services that use GTS-issued certificates.

We recommend installing Node.js and Java JDK versions that include these certificates by default. If upgrading is not an option, manually import the required GTS certificates into the application's trust store. See the necessary steps mentioned earlier in the article.

Yes, your setup will continue to work without issues if you have already added GTS Root R1 and R2 to your application’s trust store. We’re now recommending the inclusion of GTS Root R3 and R4 in preparation for future support of TLS 1.3, which will rely on these additional roots. Adding R3 and R4 now is a proactive step to ensure long-term compatibility and minimize future updates when TLS 1.3 is adopted.