Azure App Service intermittently serves different SSL certificate chains for the same hostname and certificate

Hi Alex,

Thanks very much for the detailed response.

Yes, I can confirm that the third certificate in the original PFX is the correct Starfield R1-to-G2 cross-certificate, with SHA-256 fingerprint:

26A93D60039077654C0DDA1FB634AF5F5C114C7AC1F0D449B1C9D2178B028FF

We verified this against Starfield's official repository, along with the R1v1 intermediate certificate. Both matched exactly.

The PFX uploaded to Azure contained the wildcard leaf certificate and both CA certificates, so the issue wasn't caused by an incorrect or missing certificate in the supplied bundle.

Following customer reports of browser certificate errors, I purchased a replacement wildcard certificate issued under the DigiCert hierarchy, generated a new PFX and updated the Azure App Service bindings.

This has resolved the access problems, and subsequent testing has shown consistent certificate-chain delivery.

I've also opened a production support case with Microsoft Azure. Although the immediate problem is resolved, I'd still like to understand why App Service intermittently omitted the cross-signed certificate when it was present in the uploaded PFX.

Thanks again for your help.

Anthony

Hi Anthony Burns & thx for join me at Q&A platform,

ur OpenSSL results are pretty strong evidence that something is inconsistent in the TLS termination path. You're getting the same leaf certificate, same serial number, same public IP, and same TLS version, but two different certificate chains across repeated connections.

The important detail here is the new Starfield R1 certificate hierarchy. The expected compatibility chain is:

Wildcard certificate > Starfield TLS Intermediate CA DV - R1v1 > Starfield TLS Root CA - R1 (cross-signed by Starfield G2)

That third certificate matters because some clients don't yet trust the newer Starfield R1 root directly. The cross-signed certificate provides an alternative path to the older, widely trusted Starfield G2 root.

So the two-certificate chain isn't necessarily invalid for every client, but it can definitely explain why some browsers report NET::ERR_CERT_AUTHORITY_INVALID while Windows succeeds using its local certificate store.

Could this be inconsistent App Service front-end configuration? Yes, that's a reasonable hypothesis. Azure App Service terminates TLS at its front ends, and the same public IP doesn't guarantee that every connection reaches the same front-end instance.

The fact that both chains appear shortly after reissuing and rebinding the certificate makes incomplete propagation or inconsistent chain selection worth investigating. But the evidence doesn't yet establish whether the difference comes from front-end caching, certificate-chain construction, or another part of the TLS infrastructure.

Microsoft's App Service documentation requires uploaded PFX certificates to contain the complete certificate chain, but it doesn't document a customer setting that forces every TLS front end to serve a particular cross-signed chain. So having all three certificates in the PFX is necessary, but your results show that we still need to verify what the front ends actually present.

I'd check one detail before escalating: confirm that the third certificate inside the PFX is specifically Starfield TLS Root CA - R1 to G2 Cross Certificate, not the self-signed Starfield R1 root. GoDaddy publishes both, and they aren't interchangeable for clients that rely on the G2 trust path.

You can compare the third certificate's SHA-256 fingerprint against GoDaddy's official repository:

https://certs.godaddy.com/repository/

If that matches, I'd open a production-impacting Azure App Service support case and ask engineering to investigate inconsistent certificate-chain presentation across TLS front ends.

Include the affected hostnames, public IP, App Service resource IDs, certificate thumbprint, binding types (SNI or IP SSL), UTC timestamps, and samples of both the two- and three-certificate handshakes. The OpenSSL output and SSL Labs results are particularly useful here.

I'd specifically ask engineering to confirm whether all front ends have received the updated certificate chain, whether App Service is rebuilding the chain from its certificate stores, and whether a supported front-end certificate refresh or configuration correction is required.

I wouldn't recommend repeatedly deleting and recreating production SSL bindings, especially when the correct leaf certificate is already being served. Restarting the web app probably won't help either, because inbound TLS termination happens before requests reach the application.

One question: have you confirmed that the third certificate in the PFX has the SHA-256 fingerprint 26A93D60039077654C0DDA1FB634AF5F5C114C7AC1F0D449B1C9D2178B028FF? That's the Starfield R1-to-G2 cross-certificate published by GoDaddy, and confirming it would help narrow down whether this is a certificate packaging issue or an App Service front-end issue.

Given the reproducible handshake differences and real browser trust failures, I'd treat this as a legitimate production TLS incident requiring App Service engineering investigation.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer