Server is not sending the bridge certificate!!!!

Question

Server is not sending the bridge certificate!!!!

Bobby Cannon 0

Issue

Android phones check a certificate by following it back to a root authority the phone already trusts. This new certificate ends at a root that older Android phones do not have yet. The certificate provider included a second certificate that bridges it to an older root those phones do trust.

The good App Service Plan sends that bridge certificate, so phones connect. The bad App Service Plan trusts the new root itself, so it leaves the bridge certificate out. The phone then has nothing to connect the certificate to, and the connection fails.

Uploading the same file again does not change this. The bad App Service Plan decides which certificates to send, and Azure gives you no switch to make it send the bridge. A replacement certificate from that same provider still ends at the new root, so reissuing it produces the same result.

To fix it, either put the site behind Azure Front Door or Application Gateway, which will send the bridge certificate, or replace the certificate with one from an authority that older Android phones already trust.

Question

Why can I not tell the App Service Plan to send the bridge certificate?

I have two App Service Plans. One sends the bridge certificate and the other will not. Why?

Note

I uploaded the good server's PFX onto the bad server. It fails there also.

0 comments

1 answer

Your answer

Answer 1

Azure App Service does not expose a setting that lets an app or App Service Plan select and force a particular cross-signed intermediate chain; to guarantee the legacy Android chain, terminate client TLS at Azure Front Door Standard/Premium with the complete cross-signed chain, or use Application Gateway with the complete chain on its HTTPS listener.

Why the two plans behave differently

App Service terminates incoming TLS at its network front ends rather than in the web app. Consequently, application code and web-server configuration cannot control the certificate message sent during the handshake.^1^

For an uploaded private certificate, Microsoft requires the PFX to contain the complete chain. However, the documentation describes this as an import requirement; it does not provide an option or guarantee for selecting a particular alternate path from that PFX. Certificates are stored in an App Service webspace, defined by the resource group, region, and operating-system combination.^2^

Therefore:

Uploading the working PFX to the other plan does not guarantee identical chain presentation.
The difference can occur at the App Service front-end/deployment-unit level.
The claim that the “bad” plan omits the bridge specifically because it trusts the newer root is not established by the available App Service documentation. Server trust-store contents alone do not prove how the front end selected its transmitted chain.
Microsoft documents that App Service certificate hierarchies can change and that customers should not depend on a fixed chain for platform-managed certificates.^3^

Changing minimum TLS versions, rebinding the same certificate, or uploading that PFX again does not provide control over alternate-chain selection.

Supported way to force the compatibility chain

Azure Front Door Standard/Premium

Front Door Standard/Premium explicitly supports cross-signed certificates. Import the complete chain into Key Vault, including the cross-signed CA certificate leading to the older trusted root. Front Door serves the chain supplied, and that chain must terminate at the intended trusted root.^4^

Build the PFX with the leaf certificate, required intermediate certificates, and cross-signed CA certificate in the correct order.
Import it into an Azure Key Vault in the same subscription as the Front Door profile.
In Front Door profile → Domains, select the custom domain.
Choose a customer-managed certificate and select the Key Vault certificate.
Point the domain to Front Door and retain App Service as the origin.
Test the public Front Door hostname from the affected Android versions and inspect the externally presented chain.

Front Door requires a complete chain from an allowed CA, and the App Service origin must also present a valid certificate matching the configured origin hostname.^5^

Application Gateway

Alternatively, configure an HTTPS listener on Application Gateway and upload a PFX containing the entire chain—leaf, intermediates, and root. TLS then terminates at Application Gateway rather than App Service.^6^

This option is appropriate when regional gateway routing fits the architecture. Validate the chain actually presented by the gateway against every required Android version before production cutover.

If the two-plan difference needs investigation

Because the same hostname certificate and PFX produce reproducibly different chains on two plans, open an Azure Support request rather than repeating the upload. Include:

App Service names, plans, regions, and operating systems.
Certificate thumbprint and binding type, but not the PFX or private key.
UTC timestamps for tests against each endpoint.
Full certificate-chain captures from both endpoints.
A list of affected Android versions.
Confirmation that moving the same PFX reproduces the behavior.
The requested outcome: determine why the App Service front ends select different chains and whether the affected deployment unit can be remediated.

Do not move or scale the production app solely to force different infrastructure unless Azure Support recommends it; that is not a documented way to select a certificate chain.

References