Background
Google provides public test endpoints that use TLS certificates signed by the Google Trust Services (GTS) R1-R4 Certificate Authorities (CAs). These endpoints allow users to simulate and validate the behavior of their applications when connecting to Atlas clusters configured with GTS-issued certificates.
The scripts provided in this article use these test endpoints to confirm whether your application's trust stores include the necessary certificates and are specifically for MongoDB Atlas. Successful validation indicates that your environment is ready for secure connections using the new TLS certificates.
Note:
The scripts in this article are provided for illustration purposes only and fall outside of the MongoDB Atlas support scope.
Scripts may need to be adapted to specific environments and configurations.
They should only be tested in non-production environments to avoid unintended disruptions.
Validation scripts
1. For Linux
Use the following Bash script to test your connection to Google’s test endpoints:
#!/bin/bash check_cert() { label=$1 url=$2 curl --silent --head --fail "$url" > /dev/null 2>&1 && echo "$label pass" || echo "$label fail" } check_cert R1 "https://good.gtsr1.demosite.pki.goog/" check_cert R2 "https://good.gtsr2.demosite.pki.goog/" check_cert R3 "https://good.gtsr3.demosite.pki.goog/" check_cert R4 "https://good.gtsr4.demosite.pki.goog/"Expected output:
pass: Indicates that the certificates are installed and functional.fail: Indicates missing certificates or failed connections.
2. For Windows
Windows-based environments (including Azure VMs and App Services) include a limited set of pre-installed root certificates. Many others — such as Google Trust Services (GTS) Root R1–R4 — are retrieved on demand through the Automatic Root Certificate Update mechanism.
How GTS certificate retrieval works
When a Windows-based workload connects to a remote server presenting a valid certificate chain (such as, a MongoDB Atlas cluster using GTS), Windows will contact Windows Update to fetch the corresponding root CA.
These dynamically retrieved root certificates are stored under:
Cert:\LocalMachine\AuthRoot
Pre-installed (static) root certificates reside in:
Cert:\LocalMachine\Root
Use PowerShell to validate certificates
Use the following PowerShell command to check for pre-installed GTS roots:
Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*Google Trust Services*" }Use the following PowerShell command to check for dynamically installed roots (after first connection):
Get-ChildItem -Path Cert:\LocalMachine\AuthRoot | Where-Object { $_.Subject -like "*Google Trust Services*" }
Force GTS certificate retrieval
To force the retrieval of GTS certificates, perform an HTTPS request to a GTS-signed endpoint:
curl https://good.gtsr1.demosite.pki.goog/
After a successful request, GTS Root R1 will appear in the AuthRoot.
Validate certificates using a PowerShell script
You can also use a PowerShell script to test certificate validation:
$urls = @{ R1 = "https://good.gtsr1.demosite.pki.goog/" R2 = "https://good.gtsr2.demosite.pki.goog/" R3 = "https://good.gtsr3.demosite.pki.goog/" R4 = "https://good.gtsr4.demosite.pki.goog/" } foreach ($key in $urls.Keys) { try { Invoke-WebRequest -Uri $urls[$key] -UseBasicParsing -ErrorAction Stop > $null Write-Output "$key pass" } catch { Write-Output "$key fail" } }Expected output:
pass: Certificates are correctly installed and connections succeed.fail: Indicates the certificate is missing or the connection could not be established. Forfail, ensure your environment retrieves GTS roots dynamically or manually imports them.
Most modern Windows Server editions (2019 and 2022) and Windows 10 and 11 do not include GTS Root R1–R4 by default in the static root store. Instead, they rely on on-demand retrieval.
If your environment has restricted internet access or does not allow Windows Update-based root updates, GTS roots must be manually imported into the Root store to ensure TLS validation.
3. For Java
Create the GTSCheck.java file to test certificate validation with endpoints:
import javax.net.ssl.HttpsURLConnection; import java.net.URL; import java.util.Map; public class GTSCheck { public static void main(String[] args) { Map<String, String> urls = Map.of( "R1", "https://good.gtsr1.demosite.pki.goog/", "R2", "https://good.gtsr2.demosite.pki.goog/", "R3", "https://good.gtsr3.demosite.pki.goog/", "R4", "https://good.gtsr4.demosite.pki.goog/" ); urls.forEach((label, link) -> { try { HttpsURLConnection conn = (HttpsURLConnection) new URL(link).openConnection(); conn.setConnectTimeout(5000); conn.connect(); System.out.println(label + " pass"); } catch (Exception e) { System.out.println(label + " fail"); } }); } }Run the script
Compile this script using the following command:
javac GTSCheck.java
This will create a
GTSCheck.classfile.Run the script with the following command:
java GTSCheck
Alternatively, you can use your Java IDE to compile and run this script.
Expected output:
pass: Indicates the certificates are found in the Java Runtime Environment (JRE).fail: Certificates are missing from the JRE keystore.
4. For Python
Use the following Python script to test for the endpoints:
import ssl import urllib.request urls = { "R1": "https://good.gtsr1.demosite.pki.goog/", "R2": "https://good.gtsr2.demosite.pki.goog/", "R3": "https://good.gtsr3.demosite.pki.goog/", "R4": "https://good.gtsr4.demosite.pki.goog/" } context = ssl.create_default_context() for key, url in urls.items(): try: with urllib.request.urlopen(url, context=context): print(f"{key} pass") except: print(f"{key} fail")Expected output:
pass: Certificates are present and validation succeeds.fail: Indicates missing certificates.
5. For Node.js
Use the following Node.js script to validate that the certificates are found by your runtime:
const https = require('https'); const urls = { R1: "https://good.gtsr1.demosite.pki.goog/", R2: "https://good.gtsr2.demosite.pki.goog/", R3: "https://good.gtsr3.demosite.pki.goog/", R4: "https://good.gtsr4.demosite.pki.goog/" }; const urlEntries = Object.entries(urls); let pendingRequests = urlEntries.length; // Initialize counter for (const [key, url] of urlEntries) { https.get(url, res => { console.log(`${key} pass`); pendingRequests--; // Decrement counter on success if (pendingRequests === 0) { process.exit(0); // Exit when all requests are done } }).on('error', (err) => { console.log(`${key} fail`, err.message); // Log error message for more info pendingRequests--; // Decrement counter on failure if (pendingRequests === 0) { process.exit(0); // Exit when all requests are done } }); } // Note: The script will continue to run until all pendingRequests become 0 // because the event loop is kept alive by the outstanding requests.Expected output:
passIndicates that the certificates are installed.failCertificates are missing or connections fail.
6. Kubernetes and container validation
Since Kubernetes clusters rely on their underlying OS trust store, it’s important to verify whether GTS certificates are supported.
Use the following steps to validate GTS compatibility based on your cloud provider.
Step 1: Identify your Kubernetes node OS
Each managed Kubernetes service uses different base OS images for worker nodes:
AWS EKS → Amazon Linux, Bottlerocket, Ubuntu, Windows
GCP GKE → Container-Optimized OS (COS), Ubuntu
Azure AKS → Ubuntu, Mariner, Windows
To check the OS of your nodes, run:
kubectl get nodes -o wide
Review the OS image field to identify the base OS.
If using a custom node group (self-managed nodes), verify the OS manually.
Step 2: Verify GTS certificates on Kubernetes nodes
Each Kubernetes worker node maintains a system-wide CA trust store. You can check whether GTS root certificates are installed by running:
For Linux-based nodes (EKS, GKE, AKS)
Open a shell on a worker node:
kubectl debug node/<node-name> -it --image=ubuntu
You will need to follow the steps as mentioned in the section above.
If the connection succeeds, GTS is trusted.
If there are certificate errors, you may need to update the CA bundle or use a custom trust store.
For Windows-based Nodes (EKS, AKS)
Windows nodes rely on the Windows Certificate Store, which managed by Microsoft. You need to open a PowerShell session on a Windows node and follow the steps mentioned in the section above.
If GTS root certificates are listed, they are trusted.
If missing, Microsoft must update the CA bundle.
Step 3: Verify application containers
Even if Kubernetes nodes trust GTS, your application containers might not if they use outdated CA bundles. Check your container image’s base OS:
kubectl get pods -o=jsonpath='{.items[*].spec.containers[*].image}'Run an interactive shell in a pod:
kubectl exec -it <pod-name> -- /bin/sh
Test TLS connectivity and access the following links:
# GTS Root R1 curl -v https://good.gtsr1.demosite.pki.goog/ # GTS Root R2 curl -v https://good.gtsr2.demosite.pki.goog/ # GTS Root R3 curl -v https://good.gtsr3.demosite.pki.goog/ # GTS Root R4 curl -v https://good.gtsr4.demosite.pki.goog/
If the connection succeeds, GTS is trusted.
If errors occur, update the container’s CA bundle.
Step 4: Verify certificate pinning
If your Kubernetes workloads use certificate pinning, switching to GTS could break connections.
Pin the GTS Root CA instead of individual leaf certificates.
Use public key pinning (HPKP) instead of certificate pinning.
Step 5: Compliance and security checks (Enterprise users)
For enterprise security teams, check if:
Your corporate firewall or proxy allows GTS certificates.
Any internal TLS termination (such as Istio or Envoy) trusts GTS roots.
Security policies (such as PCI-DSS, FedRAMP, or ISO 27001) require manual approval of new root CAs.