Azure Web App cannot connect to login.microsoftonline.com due to SSL error

Hi @Gordon Creel,

Thank you for submitting your question on Microsoft Q&A.

This error indicates that your application is unable to create a trusted TLS (SSL) connection with login.microsoftonline.com. The key part of the error “UntrustedRoot” means that the certificate chain provided by the server does not link back to a root certificate authority (CA) that your App Service worker (or container) recognizes as trusted.

In Azure App Service, this issue usually occurs due to one of these three common causes:

1. Missing CA bundle in a custom Linux container

If you're using a custom Linux container, or the App Service Linux environment has a minimal trust store, the operating system may not include the required DigiCert or Microsoft root certificates. These are the certificates used by Microsoft Entra ID (login.microsoftonline.com). Without these trusted roots, your app cannot validate the server’s certificate, which results in an UntrustedRoot error.

2. TLS inspection, corporate proxy, or Azure Firewall forced tunneling

In some environments, outbound HTTPS traffic is intercepted for inspection. When this happens, the proxy or firewall re-signs the certificate using its own internal root CA. Since App Service cannot install custom root certificates in multitenant environments, it will not trust the proxy's certificate. TLS inspection only works if the proxy’s root CA is trusted by the application host which is not possible in standard App Service. For these scenarios, App Service Environment v3 is required.

3. Private DNS override or routing traffic to a non-Microsoft endpoint

If DNS has been modified (intentionally or accidentally), your app may be resolving login.microsoftonline.com to an internal or incorrect IP address. That host may present a self-signed or internal certificate, causing the certificate chain to break. This is less common but still important to verify.

Identify the root cause:

You can run these checks directly from your Web App using Kudu or SSH.

Verify the TLS handshake and certificate chain:

Use curl -v to test the TLS connection

curl -v https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

This command shows whether the TLS negotiation succeeds. You should see a normal TLSv1.2 or TLSv1.3 handshake without certificate errors.

If you see an UntrustedRoot or certificate verify failed message, continue to the next step.

Inspect the full certificate chain:

curl -v https://login.microsoftonline.com

Check the certificate chain displayed:

The chain should include well-known roots such as DigiCert Global Root G2 or Microsoft RSA Root CA 2017. If instead you see a private enterprise root CA, that means your outbound traffic is being intercepted by a TLS-inspection proxy or firewall.

If the chain verification succeeds but the root CA looks unfamiliar, that’s a strong signal of TLS inspection.

Confirm DNS resolution

nslookup login.microsoftonline.com

Verify that the hostname resolves to Microsoft-owned IP addresses.

If it resolves to an internal or non-Microsoft IP: A private DNS override is redirecting traffic. Fix DNS so it resolves to Microsoft’s public endpoint.

Solution

You’re running App Service on Linux or a custom container:

Install or refresh the OS CA certificates so DigiCert/Microsoft roots are trusted.

Debian/Ubuntu base image

FROM mcr.microsoft.com/dotnet/aspnet:8.0
RUN apt-get update \
 && apt-get install -y --no-install-recommends ca-certificates \
 && update-ca-certificates \
 && rm -rf /var/lib/apt/lists/*

Alpine base image

FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine
RUN apk add --no-cache ca-certificates \
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine

Rebuild and deploy. This ensures the trust store includes the DigiCert/Microsoft roots that Entra ID uses. Azure’s CA details page shows the common roots used across Microsoft endpoints. If you’re not using a custom container, note that App Service on Linux can have a minimal CA store; adding the required CA(s) at runtime or via environment/bootstrap is a known approach.

Your app is VNET‑integrated and outbound traffic goes through Azure Firewall / Corporate proxy with TLS inspection:

Best fix: Disable TLS inspection (MITM) for Microsoft identity endpoints, so the original DigiCert/Microsoft chain reaches your app.

If your security policy requires TLS inspection: run the app in App Service Environment v3 and install the proxy’s root CA into the worker so re‑signed certificates are trusted.

Windows App Service hitting endpoints with private CA:

You can upload public certificates and make them available to your app code with WEBSITE_LOAD_CERTIFICATES, but modifying the machine trusted root store in multitenant App Service is limited; ASE is recommended when you must trust a private root for outbound TLS.

Reference:

https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-ca-details?tabs=root-and-subordinate-cas-list

https://learn.microsoft.com/en-us/azure/app-service/network-secure-outbound-traffic-azure-firewall

https://techcommunity.microsoft.com/blog/azurepaasblog/ssltls-connection-issue-troubleshooting-test-tools/2240059

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.