GTS Root R1 and R2 for Azure App Services app

Question

GTS Root R1 and R2 for Azure App Services app

Mia Wang 20

Hi Sampath,

Now I managed to complete the operation, but I am still unsure if the new certificates are in use by my App Service app. Here's what I did:

I created the .cer files for GTS R1 and R2 by using the Keychain Access app in my Mac. That was a very straightforward way as it already had the GTS R1 and R2 certificates, and they can be exported as .cer files.
I uploaded the .cer files to app's Public key certificates in Azure.
I added the WEBSITE_LOAD_ROOT_CERTIFICATES definition with thumbprint values to app's Settings > Environment variables > App settings (this is where I think MS instructions are a bit off).

If I now use "dir cert:\localmachine\root" in PowerShell, it still does not show the newly added certificates. I user "az webapp config ssl list --resource-group MyResourceGroup" in cloud shell, also not show added certificates.

I try to use other environment variables "WEBSITE_ROOT_CERTS_PATH" /"WEBSITE_LOAD_CERTIFICATES" to definition with thumbprint, also not show added certificates.

Is there any other way to see if those installed certificates are available as well?

Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-16T06:33:36.04+00:00

Hi @Mia Wang ,

It seems like you've done most of the steps correctly to upload and configure the GTS Root R1 and R2 certificates for your Azure App Service app. To verify if the newly added certificates are in use by your Azure App Service app, you can follow below steps:

You can access the Kudu console for your app by navigating to https://<your-app-name>.scm.azurewebsites.net/DebugConsole. From there, you can run the command dir Cert:\LocalMachine\Root to see if your certificates are listed or not.

Ensure that the WEBSITE_LOAD_ROOT_CERTIFICATES setting is correctly configured with the thumbprint values of the certificates you uploaded. If you have multiple certificates, they should be separated by commas without any whitespace. After making changes to the application settings, it is necessary to restart your app for the changes to take effect.

You can also use the Azure CLI to check the configuration. The command az webapp config appsettings list --name <app-name> --resource-group <resource-group-name> Will show you the current application settings, including the certificate settings.

If the certificates still do not appear, you may want to double-check the upload process and ensure that the certificates were correctly exported and uploaded.

References:

Private client certificate
Use TLS/SSL certificates in your application code
TLS/SSL

Hope this helps, please let us know if you have any further queries.
Mia Wang 20 Reputation points

2025-04-16T23:36:50.3733333+00:00

Hi Bhargavi Naragani,

Thanks for your answer.

I have try to upload and add appsettings again, and check the configuration, I can see the app setting "WEBSITE_LOAD_ROOT_CERTIFICATES, but when I run the "dir cert:\localmachine\root" command in kudu , still not show the certificates GTS R2 and GTS R1 . Do you have any other suggestions for this?

But I ran this in kudu cmd prompt (to hit google's test server for GTS R2)

curl https://good.gtsr2.demosite.pki.goog/

The curl command succeeded. Then I go back to powershell and re-run the "dir cert:\localmachine\root" command and see "GTS Root R2" successfully in the output.

And there are two "GTS RootR2" with different thumbprint value, one of them is which I have added.

I donnot know why?

Is the "curl https://good.gtsr2.demosite.pki.goog/" command can download and install the certificates? And if it can, do we need run this command everytime after we publish api?
Mia Wang 20 Reputation points

2025-04-16T23:38:56.66+00:00

Hi Bhargavi Naragani,

Thanks for your answer. I have try to upload and add appsettings again, but not show the certificates. Do you have any other suggestions for this?

But I ran this in kudu cmd prompt (to hit google's test server for GTS R2)

curl https://good.gtsr2.demosite.pki.goog/

The curl command succeeded. Then I go back to powershell and re-run the "dir cert:\localmachine\root" command and see "GTS Root R2" successfully in the output.

And there are two "GTS RootR2" with different thumbprint value, one of them is which I have added.

I donnot know why?

Is the "curl https://good.gtsr2.demosite.pki.goog/" command can download and install the certificates? And if it can, do we need run this command everytime after we publish api?
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T04:58:32.9033333+00:00
Hi @Mia Wang ,

The reason you’re not initially seeing the certificates under Cert:\LocalMachine\Root is due to how Azure App Service loads and manages certificates:

WEBSITE_LOAD_ROOT_CERTIFICATES does not install certs system-wide or show them immediately under LocalMachine\Root. It just makes them available to your app process at runtime.

The certs are loaded on demand, not automatically at app startup. That’s why the certs appear only after a request (like curl) triggers a TLS handshake, which causes the certificate validation chain to be evaluated.

Once the app tries to validate a chain (like by making an outbound HTTPS request that uses those roots), Azure’s runtime loads the relevant certs into the process, and then you’ll see them in the cert store from that point onward in that session.

You did everything right. Your certificates are there; they just aren’t pre-loaded until needed and you do not need to run the curl manually after every deployment. As long as the certs are uploaded and listed in WEBSITE_LOAD_ROOT_CERTIFICATES, your app will load them automatically when needed.

Note: The reason you saw two GTS Root R2 certs is likely because one was loaded dynamically from the request, and the other is your uploaded version.

Azure App Service: Load certificates in your app
App settings reference for Azure App Service
Use client certificates in Azure App Service
Mia Wang 20 Reputation points

2025-04-17T06:40:35.2633333+00:00

Hi Bhargavi Naragani,Thanks for your answer.

But when I try to run below command in kudu:

curl https://good.gtsr2.demosite.pki.goog/

Then I go back to powershell and re-run the "dir cert:\localmachine\root" command and also see "GTS Root R4" successfully in the output. There are also two "GTS RootR2" with different thumbprint value.

And I didn't upload the "GTS Root R4" certificate.

And when I try to re-run the "dir cert:\localmachine\root" command and the second day

So I don't understand why this happened?
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T07:03:04.8433333+00:00

Hi @Mia Wang
The certificates (like GTS R4) are dynamically loaded when needed by Azure’s platform, even if you didn’t upload them. They’re not persisted long-term in Cert:\LocalMachine\Root, so they can disappear between sessions. Your app will still work just fine; Azure handles the certificate chain trust in the background.

When you run: "curl https://good.gtsr2.demosite.pki.goog/" your App Service instance reaches out to Google's test endpoint over HTTPS. During the TLS handshake, Azure pulls in the required public root certificates to complete the certificate validation chain. These root certificates are pulled from Azure’s trusted certificate store, not just from the certificates you upload manually.

So, in your case you did not upload GTS Root R4, but it appeared in Cert:\LocalMachine\Root after running curl. That’s because Google's server uses GTS Root R4 in its chain, and Azure dynamically fetched it during the TLS handshake and same with multiple versions of GTS Root R2 - one might be the cert you uploaded, and the other one could be the version auto-loaded by Azure as part of its trusted roots.

Key point: Azure App Service dynamically loads root certificates into your app’s certificate store on demand, depending on the server you're calling and the certificate chain it uses.
Mia Wang 20 Reputation points

2025-04-17T07:12:37.1066667+00:00

Hi Bhargavi Naragani,

Because we need to ensure "GTS Root R1" and "GTS Root R2" are included in app services trust stores, we need these 2 certificates when connect MongoDB Atlas.

So do you have any other suggestions to help us to verify we have "GTS Root R1" and "GTS Root R2" in my app services.

BTY, "GTS Root R1" and "GTS Root R2" are not dynamically loaded when needed by Azure’s platform, like "GTS Root R4"? Is that correct?

Thank you very much!
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T07:45:53.7066667+00:00
@Mia Wang
GTS Root R4 is a newer root certificate that’s already part of Azure App Service’s platform-managed trusted root store, so it often gets loaded dynamically during TLS handshakes. However, GTS Root R1 and R2 are older (legacy) roots from Google Trust Services and may not be present in the default store used by all Azure App Service regions or SKUs. That’s why they might not load automatically, especially if MongoDB Atlas is presenting a cert chain anchored to R1 or R2 and Azure doesn’t recognize it. So yes, you are correct to upload R1 and R2 manually if you depend on them for secure TLS to MongoDB.

To Ensure R1 and R2 Are Trusted by Your App make sure the .cer files for GTS Root R1 and R2 are uploaded to: TLS/SSL Settings > Public Key Certificates (Incoming client certificates)Docs: Upload public certificates to App Service, configure WEBSITE_LOAD_ROOT_CERTIFICATES In your App Service app settings, add a setting named WEBSITE_LOAD_ROOT_CERTIFICATES then set its value to the thumbprints of R1 and R2, comma-separated (no spaces)

Docs: WEBSITE_LOAD_ROOT_CERTIFICATES

This tells Azure to make these root certs available in your app’s trusted root store. After setting the environment variable, be sure to restart your App Service to load the certs, you can use Kudu PowerShell to check if the certs were loaded by running "dir Cert:\LocalMachine\Root" command.

Alternative approach:

You can also verify from within your app (or Kudu) using a quick TLS test:

openssl s_client -connect <your-mongodb-host>:<port> -showcerts

This shows the certificate chain served by MongoDB Atlas, you’ll see if it includes GTS R1/R2 and confirms your app can build trust successfully.

Let me know if you're able to verify "GTS Root R1" and "GTS Root R2" in your app services by following above.
Mia Wang 20 Reputation points

2025-04-17T09:03:59.6566667+00:00

Hi Bhargavi Naragani,

Thank you so much for replying so quickly.

I try to upload the .cer files to app's Public key certificates in Azure. And adde the WEBSITE_LOAD_ROOT_CERTIFICATES definition with thumbprint values to app's Settings and restart again. Then run "dir cert:\localmachine\root", still not show "GTS Root R1" and "GTS Root R2".

Also I run the TLS test:

"openssl s_client -connect <your-mongodb-host>:<port> -showcerts"

But I still cannot find "GTS Root R1" and "GTS Root R2" in my app services. It shows TLSv1.2 and ISRG Root X1
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T09:25:57.9366667+00:00

@Mia Wang

Thank you for confirming,

You see ISRG Root X1, but not GTS Root R1 or R2, that tells us MongoDB Atlas is not serving a certificate chain anchored to GTS R1 or R2. Instead, it’s serving a chain anchored to ISRG Root X1, which is part of Let’s Encrypt’s trusted roots. That’s why even after uploading R1/R2 manually, you're not seeing them used, because they’re simply not required by the MongoDB server's current TLS setup. So, there’s actually nothing wrong with your App Service or the certificate upload process, the reason you don’t see GTS R1/R2 is because the connection never uses them.

Google Trust Services (GTS) roots like R1/R2 are sometimes used by Google-hosted TLS endpoints, but MongoDB Atlas doesn’t always use them, it depends on the region, cluster configuration, or recent CA changes.

MongoDB recently shifted many clusters to use Let’s Encrypt (ISRG) for certificates, which is why you’re seeing ISRG Root X1 in the chain.
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-18T01:24:29.13+00:00

Hi @Mia Wang ,
Just checking in to see if above information was helpful. If you have any further queries on this issue, please feel free to post back.
Mia Wang 20 Reputation points

2025-04-18T02:17:05.7733333+00:00

Hi Bhargavi Naragani,

Sorry not feed back.

Thanks a lot to help me. But I still cannot confirm we have install the GTS Root R1 and GTS Root R2 in my trust store successfully. I will contact with MongoDB support for this connect command.

Thank you so much. If I have any other questions, Could you help me again?

Accepted answer

0 additional answers

Your answer

Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-16T06:33:36.04+00:00

Hi @Mia Wang ,

It seems like you've done most of the steps correctly to upload and configure the GTS Root R1 and R2 certificates for your Azure App Service app. To verify if the newly added certificates are in use by your Azure App Service app, you can follow below steps:

You can access the Kudu console for your app by navigating to https://<your-app-name>.scm.azurewebsites.net/DebugConsole. From there, you can run the command dir Cert:\LocalMachine\Root to see if your certificates are listed or not.

Ensure that the WEBSITE_LOAD_ROOT_CERTIFICATES setting is correctly configured with the thumbprint values of the certificates you uploaded. If you have multiple certificates, they should be separated by commas without any whitespace. After making changes to the application settings, it is necessary to restart your app for the changes to take effect.

You can also use the Azure CLI to check the configuration. The command az webapp config appsettings list --name <app-name> --resource-group <resource-group-name> Will show you the current application settings, including the certificate settings.

If the certificates still do not appear, you may want to double-check the upload process and ensure that the certificates were correctly exported and uploaded.

References:

Private client certificate
Use TLS/SSL certificates in your application code
TLS/SSL

Hope this helps, please let us know if you have any further queries.
Mia Wang 20 Reputation points

2025-04-16T23:36:50.3733333+00:00

Hi Bhargavi Naragani,

Thanks for your answer.

I have try to upload and add appsettings again, and check the configuration, I can see the app setting "WEBSITE_LOAD_ROOT_CERTIFICATES, but when I run the "dir cert:\localmachine\root" command in kudu , still not show the certificates GTS R2 and GTS R1 . Do you have any other suggestions for this?

But I ran this in kudu cmd prompt (to hit google's test server for GTS R2)

curl https://good.gtsr2.demosite.pki.goog/

The curl command succeeded. Then I go back to powershell and re-run the "dir cert:\localmachine\root" command and see "GTS Root R2" successfully in the output.

And there are two "GTS RootR2" with different thumbprint value, one of them is which I have added.

I donnot know why?

Is the "curl https://good.gtsr2.demosite.pki.goog/" command can download and install the certificates? And if it can, do we need run this command everytime after we publish api?
Mia Wang 20 Reputation points

2025-04-16T23:38:56.66+00:00

Hi Bhargavi Naragani,

Thanks for your answer. I have try to upload and add appsettings again, but not show the certificates. Do you have any other suggestions for this?

But I ran this in kudu cmd prompt (to hit google's test server for GTS R2)

curl https://good.gtsr2.demosite.pki.goog/

The curl command succeeded. Then I go back to powershell and re-run the "dir cert:\localmachine\root" command and see "GTS Root R2" successfully in the output.

And there are two "GTS RootR2" with different thumbprint value, one of them is which I have added.

I donnot know why?

Is the "curl https://good.gtsr2.demosite.pki.goog/" command can download and install the certificates? And if it can, do we need run this command everytime after we publish api?
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T04:58:32.9033333+00:00

Hi @Mia Wang ,

The reason you’re not initially seeing the certificates under Cert:\LocalMachine\Root is due to how Azure App Service loads and manages certificates:

WEBSITE_LOAD_ROOT_CERTIFICATES does not install certs system-wide or show them immediately under LocalMachine\Root. It just makes them available to your app process at runtime.

The certs are loaded on demand, not automatically at app startup. That’s why the certs appear only after a request (like curl) triggers a TLS handshake, which causes the certificate validation chain to be evaluated.

Once the app tries to validate a chain (like by making an outbound HTTPS request that uses those roots), Azure’s runtime loads the relevant certs into the process, and then you’ll see them in the cert store from that point onward in that session.

You did everything right. Your certificates are there; they just aren’t pre-loaded until needed and you do not need to run the curl manually after every deployment. As long as the certs are uploaded and listed in WEBSITE_LOAD_ROOT_CERTIFICATES, your app will load them automatically when needed.

Note: The reason you saw two GTS Root R2 certs is likely because one was loaded dynamically from the request, and the other is your uploaded version.

Azure App Service: Load certificates in your app
App settings reference for Azure App Service
Use client certificates in Azure App Service
Mia Wang 20 Reputation points

2025-04-17T06:40:35.2633333+00:00

Hi Bhargavi Naragani,Thanks for your answer.

But when I try to run below command in kudu:

curl https://good.gtsr2.demosite.pki.goog/

Then I go back to powershell and re-run the "dir cert:\localmachine\root" command and also see "GTS Root R4" successfully in the output. There are also two "GTS RootR2" with different thumbprint value.

And I didn't upload the "GTS Root R4" certificate.

And when I try to re-run the "dir cert:\localmachine\root" command and the second day

So I don't understand why this happened?
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T07:03:04.8433333+00:00

Hi @Mia Wang
The certificates (like GTS R4) are dynamically loaded when needed by Azure’s platform, even if you didn’t upload them. They’re not persisted long-term in Cert:\LocalMachine\Root, so they can disappear between sessions. Your app will still work just fine; Azure handles the certificate chain trust in the background.

When you run: "curl https://good.gtsr2.demosite.pki.goog/" your App Service instance reaches out to Google's test endpoint over HTTPS. During the TLS handshake, Azure pulls in the required public root certificates to complete the certificate validation chain. These root certificates are pulled from Azure’s trusted certificate store, not just from the certificates you upload manually.

So, in your case you did not upload GTS Root R4, but it appeared in Cert:\LocalMachine\Root after running curl. That’s because Google's server uses GTS Root R4 in its chain, and Azure dynamically fetched it during the TLS handshake and same with multiple versions of GTS Root R2 - one might be the cert you uploaded, and the other one could be the version auto-loaded by Azure as part of its trusted roots.

Key point: Azure App Service dynamically loads root certificates into your app’s certificate store on demand, depending on the server you're calling and the certificate chain it uses.
Mia Wang 20 Reputation points

2025-04-17T07:12:37.1066667+00:00

Hi Bhargavi Naragani,

Because we need to ensure "GTS Root R1" and "GTS Root R2" are included in app services trust stores, we need these 2 certificates when connect MongoDB Atlas.

So do you have any other suggestions to help us to verify we have "GTS Root R1" and "GTS Root R2" in my app services.

BTY, "GTS Root R1" and "GTS Root R2" are not dynamically loaded when needed by Azure’s platform, like "GTS Root R4"? Is that correct?

Thank you very much!
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T07:45:53.7066667+00:00

@Mia Wang
GTS Root R4 is a newer root certificate that’s already part of Azure App Service’s platform-managed trusted root store, so it often gets loaded dynamically during TLS handshakes. However, GTS Root R1 and R2 are older (legacy) roots from Google Trust Services and may not be present in the default store used by all Azure App Service regions or SKUs. That’s why they might not load automatically, especially if MongoDB Atlas is presenting a cert chain anchored to R1 or R2 and Azure doesn’t recognize it. So yes, you are correct to upload R1 and R2 manually if you depend on them for secure TLS to MongoDB.

To Ensure R1 and R2 Are Trusted by Your App make sure the .cer files for GTS Root R1 and R2 are uploaded to: TLS/SSL Settings > Public Key Certificates (Incoming client certificates)Docs: Upload public certificates to App Service, configure WEBSITE_LOAD_ROOT_CERTIFICATES In your App Service app settings, add a setting named WEBSITE_LOAD_ROOT_CERTIFICATES then set its value to the thumbprints of R1 and R2, comma-separated (no spaces)

Docs: WEBSITE_LOAD_ROOT_CERTIFICATES

This tells Azure to make these root certs available in your app’s trusted root store. After setting the environment variable, be sure to restart your App Service to load the certs, you can use Kudu PowerShell to check if the certs were loaded by running "dir Cert:\LocalMachine\Root" command.

Alternative approach:

You can also verify from within your app (or Kudu) using a quick TLS test:

openssl s_client -connect <your-mongodb-host>:<port> -showcerts

This shows the certificate chain served by MongoDB Atlas, you’ll see if it includes GTS R1/R2 and confirms your app can build trust successfully.

Let me know if you're able to verify "GTS Root R1" and "GTS Root R2" in your app services by following above.
Mia Wang 20 Reputation points

2025-04-17T09:03:59.6566667+00:00

Hi Bhargavi Naragani,

Thank you so much for replying so quickly.

I try to upload the .cer files to app's Public key certificates in Azure. And adde the WEBSITE_LOAD_ROOT_CERTIFICATES definition with thumbprint values to app's Settings and restart again. Then run "dir cert:\localmachine\root", still not show "GTS Root R1" and "GTS Root R2".

Also I run the TLS test:

"openssl s_client -connect <your-mongodb-host>:<port> -showcerts"

But I still cannot find "GTS Root R1" and "GTS Root R2" in my app services. It shows TLSv1.2 and ISRG Root X1
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-17T09:25:57.9366667+00:00

@Mia Wang

Thank you for confirming,

You see ISRG Root X1, but not GTS Root R1 or R2, that tells us MongoDB Atlas is not serving a certificate chain anchored to GTS R1 or R2. Instead, it’s serving a chain anchored to ISRG Root X1, which is part of Let’s Encrypt’s trusted roots. That’s why even after uploading R1/R2 manually, you're not seeing them used, because they’re simply not required by the MongoDB server's current TLS setup. So, there’s actually nothing wrong with your App Service or the certificate upload process, the reason you don’t see GTS R1/R2 is because the connection never uses them.

Google Trust Services (GTS) roots like R1/R2 are sometimes used by Google-hosted TLS endpoints, but MongoDB Atlas doesn’t always use them, it depends on the region, cluster configuration, or recent CA changes.

MongoDB recently shifted many clusters to use Let’s Encrypt (ISRG) for certificates, which is why you’re seeing ISRG Root X1 in the chain.
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-18T01:24:29.13+00:00

Hi @Mia Wang ,
Just checking in to see if above information was helpful. If you have any further queries on this issue, please feel free to post back.
Mia Wang 20 Reputation points

2025-04-18T02:17:05.7733333+00:00

Hi Bhargavi Naragani,

Sorry not feed back.

Thanks a lot to help me. But I still cannot confirm we have install the GTS Root R1 and GTS Root R2 in my trust store successfully. I will contact with MongoDB support for this connect command.

Thank you so much. If I have any other questions, Could you help me again?

Answer 1

Bhargavi Naragani 6,365 Microsoft External Staff Moderator

@Mia Wang

No worries at all, I really appreciate your persistence and your clear updates throughout this process!

You're absolutely on the right track by reaching out to MongoDB support to confirm which certificate chain their server's use. That will help determine whether GTS Root R1 and R2 are even needed for your current setup.

The reason you're not seeing GTS R1/R2 in the certificate store could be simply because the server you're connecting to (MongoDB Atlas) is not presenting a certificate chain that requires them at this time. This behavior aligns with Azure App Service's design it will only expose certificates in Cert:\LocalMachine\Root that are either: Used in a TLS connection, or explicitly loaded via WEBSITE_LOAD_ROOT_CERTIFICATES

If my assistance has been helpful to you, please click Accept Answer and kindly upvote it.

Looking forward to assisting you any time you need.

Mia Wang 20 Reputation points

2025-04-21T03:41:52.62+00:00

Hi Bhargavi Naragani,

Sorry to bother you again.

I found the GTS Root R1 and GTS Root R2 by using below command in Kudu powershell:

dir cert:\CurrentUser\My

So if these two R1 and R2 in the CurrentUserMy path, is it ok for connect with MongoDB Atlas?

And how can I upload my GTS Root R1 and GTS Root R2 in to LocalMachine\Root?
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-23T04:08:12.5866667+00:00
Hi @Mia Wang,

Apologies for the late response

These certificates are available in your user’s personal certificate store, but they are not currently part of the trusted root store used for TLS validation by your App Service. In short, this means they exist, but they aren’t being used for server validation (which relies on the LocalMachine\Root store)

To Load Root Certs Properly in App Service, here’s what you need to do (if not done already):

Upload your .cer files for GTS Root R1 and R2 to your App Service: Go to TLS/SSL settings > Public Key Certificates (.cer) in the Azure Portal. Upload each root certificate.

Configure App Settings: Go to Configuration > Application settings. Add or update: WEBSITE_LOAD_ROOT_CERTIFICATES = <thumbprint1>,<thumbprint2> Replace with the actual thumbprints of GTS R1 and R2 with no spaces.

Once done, these certificates will be loaded into the LocalMachine\Root store at runtime and can be verified with:
dir Cert:\LocalMachine\Root | Where-Object { $_.Thumbprint -eq "<your-thumbprint>" }

Hope this helps, please let us know if you have any further queries.
Mia Wang 20 Reputation points

2025-04-23T05:42:10.1933333+00:00

Hi Bhargavi Naragani,

This go back the first issue again. Even I have added the enviroment WEBSITE_LOAD_ROOT_CERTIFICATES = <thumbprint1>,<thumbprint2>, I still can not see the related thumbprint1/thumbprint2 by using "dir Cert:\LocalMachine\Root | Where-Object { $_.Thumbprint -eq "<your-thumbprint>" }" command.

Thanks, Mia
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-23T05:58:01.3933333+00:00
@Mia Wang,

Azure App Service loads certificates into the trusted store at runtime only when the app actually makes a TLS connection that requires validating against that root certificate.

So even with the correct environment variable set, the certificate may not appear in LocalMachine\Root until your app tries to establish a secure connection (like to MongoDB Atlas) that chains to that certificate.

This is intentional lazy-loading behavior to keep the environment secure and minimal.

Ensure your app is actively making a TLS connection to MongoDB Atlas during startup or during a request. Then, immediately after that, go to Kudu PowerShell and run:

dir Cert:\LocalMachine\Root | Where-Object { $_.Thumbprint -eq "<your-thumbprint>" }

or to list all:

dir Cert:\LocalMachine\Root | Sort-Object Subject

You should then see GTS Root R1 or R2 only if the MongoDB server certificate chain actually uses them during validation. If they still don’t show up, it's likely the MongoDB server doesn’t require them (e.g., it may use ISRG Root X1 as the root instead).

The WEBSITE_LOAD_ROOT_CERTIFICATES setting:

“Allows an app to load public root certificates into the trusted root store at runtime to establish outbound TLS connections.” — Microsoft Docs – App Settings

This means visibility of those certs is tied to whether the app actually uses them in a real connection.
Mia Wang 20 Reputation points

2025-04-23T06:09:28.23+00:00

Hi Bhargavi Naragani,

Thank you very much.
Mia Wang 20 Reputation points

2025-04-23T06:27:59.8233333+00:00

Hi Bhargavi Naragani,

Why can I only see the Enviroment var "WEBSITE_LOAD_CERTIFICATES"

What difference between "WEBSITE_LOAD_CERTIFICATES" and "WEBSITE_LOAD_ROOT_CERTIFICATES"?
Bhargavi Naragani 6,365 Reputation points Microsoft External Staff Moderator

2025-04-23T07:55:09.8033333+00:00
Hi @Mia Wang,

WEBSITE_LOAD_CERTIFICATES setting is used when you want to load private certificates (typically .pfx certificates with private keys) that you have uploaded to App Service > TLS/SSL settings > Private Key Certificates (.pfx).

It allows your application code to access these certificates for client certificate authentication, mutual TLS, or secure communication that requires a private key.

Use this when accessing certs in code under: Cert:\CurrentUser\My or CurrentUser\My store. Use a TLS/SSL certificate in your code

WEBSITE_LOAD_ROOT_CERTIFICATES setting is used to load public root or intermediate certificates (typically .cer files) into the trusted root certificate store (LocalMachine\Root) at runtime — for example, when your app makes an outbound TLS connection to a service (like MongoDB Atlas).

Certificates must be uploaded to Public Key Certificates (.cer) in App Service.

Used to extend the trust store for verifying server certificates during outbound HTTPS/TLS connections.

These certs are not used in code directly, but rather to help validate secure connections your app makes App Settings – WEBSITE_LOAD_ROOT_CERTIFICATES

You Might Only See WEBSITE_LOAD_CERTIFICATES Mentioned in Some Docs because, most Azure App Service documentation focuses on certificates used in code (hence, WEBSITE_LOAD_CERTIFICATES), but WEBSITE_LOAD_ROOT_CERTIFICATES is used more for outbound trust, which is less commonly needed but very important in cases like yours.
Mia Wang 20 Reputation points

2025-04-23T08:39:20.4366667+00:00

Hi Bhargavi Naragani,

Thanks for your patience.

Share via

GTS Root R1 and R2 for Azure App Services app

0 additional answers

Your answer