An Azure service that provides a cloud content delivery network with threat protection.
Front Door Standard serves self-signed Sectigo Root R46 instead of uploaded cross-signed chain (BYOC)
We use Azure Front Door Standard with our own certificate (BYOC) from Key Vault: a Sectigo wildcard certificate *.example.com, issued by Sectigo Public Server Authentication CA DV R36.
The root Sectigo Public Server Authentication Root R46 is only trusted on iOS 17.4 and later. Older iOS devices fail with UntrustedRoot. To support them, we imported a new certificate version into Key Vault whose chain contains Root R46 cross-signed by USERTrust RSA Certification Authority:
*.example.com <- Sectigo Public Server Authentication CA DV R36
Sectigo Public Server Authentication CA DV R36 <- Sectigo Public Server Authentication Root R46
Sectigo Public Server Authentication Root R46 <- USERTrust RSA Certification Authority
We verified that the Key Vault version contains exactly this chain.
Front Door keeps serving the self-signed R46 instead:
0 s:CN=*.example.com
i:Sectigo Public Server Authentication CA DV R36
1 s:Sectigo Public Server Authentication CA DV R36
i:Sectigo Public Server Authentication Root R46
2 s:Sectigo Public Server Authentication Root R46
i:Sectigo Public Server Authentication Root R46
The documentation says:
"Cross-signed certificates are supported only on Azure Front Door Standard and Premium. [...] Front Door serves the certificate chain that you provide, so the uploaded chain must terminate at the intended trusted root."
What we tried
- A secret pinned to the new version, associated with the domains → Succeeded. After more than 24 hours, still the self-signed R46.
- Re-associating the domains with the Latest secret (which resolves to the new version) → Succeeded. No change.
- Isolated test: a new endpoint, a new custom domain and a new route, using the same secret. The brand new domain also serves the self-signed R46.
We checked directly against multiple edge IPs with openssl s_client -connect <edge-ip>:443 -servername <domain> -showcerts.
The same PFX on Azure App Service serves the cross-signed chain correctly.
Note: the leaf certificate (and its thumbprint) is identical in both Key Vault versions. Only the chain differs.
Questions
- Does Front Door rebuild the chain itself, or cache the certificate or chain by thumbprint, instead of serving the chain from Key Vault?
- Is there a way to make Front Door serve the cross-signed chain?
- Has anyone solved this for Sectigo R46 on Front Door Standard/Premium?