Azure CDN Classic BYOC: "Multiple server (leaf) certificates" error with Sectigo PFX

Question

Azure CDN Classic BYOC: "Multiple server (leaf) certificates" error with Sectigo PFX

Cris Francisco 20

I am attempting to move from a Managed Certificate to Bring Your Own Certificate (BYOC) on an Azure CDN (classic) profile (Microsoft SKU) before the April 14th deadline.

The Setup:

Resource: Azure CDN Standard from Microsoft (classic).

Certificate: Sectigo Public Server Authentication (Root R46 -> Intermediate R36 -> Leaf).

Storage: Key Vault (Secret) as a Base64 encoded PFX with no password.

Permissions: CDN has Get secret permissions on the Key Vault.

The Problem: Every time I attempt to Save the custom domain settings with "Use my own certificate," the portal returns:

“Failed to update custom domain properties: The certificate chain includes multiple server (leaf) certificates.”

Troubleshooting already performed:

Surgical Rebuild: Used OpenSSL to extract the key, leaf, and intermediate separately and rebuild the PFX to ensure no duplicates exist.

Metadata Stripping: Used openssl x509 to strip all "Friendly Names" and attributes before bundling.

No-Chain Test: Attempted to upload a PFX containing only the leaf and private key.

Format Check: Verified the Secret Content Type is set to application/x-pkcs12.

Verified Status: Confirmed the Root (R46) is on the Microsoft Trusted CA list.

Opt-Out: I have already registered the DoNotAutoMigrateClassicManagedCertificatesProfiles feature flag as a safety measure.

Question: Is there a known issue with the legacy CDN Classic validator and the modern Sectigo R36 intermediate? How can I get this certificate bound to the domain when the portal's validation logic appears to be incorrectly flagging the intermediate as a second leaf?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @ Cris Francisco,

Welcome to Microsoft Q&A Platform.

It looks like the classic CDN (Microsoft SKU) validator is choking on the Sectigo R36 intermediate and flagging it as a second leaf cert. This is a known quirk in the legacy portal validation logic when it encounters a cross-signed intermediate.

Rebuild the PFX with only the leaf cert and the correct R36 intermediate (signed by your R46 root), and exclude the root entirely.
Download the “Sectigo Public Server Authentication R36 (signed by R46)” intermediate from Sectigo’s repo (not the cross-signed one).
Use OpenSSL to merge in this exact intermediate below your leaf, then build the PFX:

cat leaf.crt sectigo-r36-by-r46.crt > chain.pem  
openssl pkcs12 -export \
  -inkey leaf.key \
  -in leaf.crt \
  -in sectigo-r36-by-r46.crt \
  -out bundle.pfx \
  -nodes

• Verify the chain order in the PFX: openssl pkcs12 -in bundle.pfx -nokeys -info

Exclude the root certificate from the PFX. Classic CDN only needs leaf → intermediate. Including the root can trip its validator.

Bypass the portal’s buggy validation by using Azure CLI or PowerShell to bind your BYOC cert directly from Key Vault:

az cdn custom-domain enable-https \
  --resource-group MyRG \
  --profile-name MyCDNProfile \
  --endpoint-name MyEndpoint \
  --name www.contoso.com \
  --certificate-source AzureKeyVault \
  --vault-name MyKV \
  --secret-name myPfxSecret \
  --secret-version <version> \
  --vault-resource-id /subscriptions/.../vaults/MyKV

Hope this helps you get past the classic-portal validator. Once you have a clean leaf+R36 chain PFX and/or you push it via CLI, it should bind successfully!

Reference docs

Configure HTTPS on an Azure CDN custom domain (Classic BYOC): https://learn.microsoft.com/azure/cdn/cdn-custom-ssl?tabs=option-1-default-enable-https-with-a-cdn-managed-certificate

HTTPS and SSL config for Azure CDN: https://learn.microsoft.com/azure/cdn/cdn-http-https

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Cris Francisco 20 Reputation points

2026-04-11T01:12:36.4266667+00:00

Thank you so much for taking the time to respond so quickly! I was able to follow all of the steps outlined.

Update: I attempted the bypass via Azure CLI with a stripped PFX (Leaf + R36 intermediate only), but received (BadRequest) The certificate chain includes multiple server (leaf) certificates. This confirms the validation issue is at the API level. Since I've registered the opt-out flag, can an engineer assist with a backend manual binding?
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-04-11T01:50:23.0733333+00:00

Hi @ Cris Francisco,

The behavior you are encountering is expected with Azure CDN (classic, Microsoft SKU).

Since the same error occurs via both Portal and CLI, the failure is happening at the service API level, not due to the portal. The CDN Classic platform uses a legacy certificate validation pipeline that can incorrectly interpret certain certificate chains (including newer Sectigo intermediates like R36) as containing multiple leaf certificates.

At this time:

There is no supported way to bypass this validation

Backend/manual binding is not supported

The issue is a platform limitation, not a configuration issue

To resolve the issue permanently

Migrate to Azure Front Door (Standard/Premium) for full BYOC support
**OR**

Use a certificate chain from a different CA (e.g., DigiCert) known to be compatible with CDN Classic

Note: Starting August 15, 2025, Azure CDN from Microsoft (classic) will no longer support new domain onboarding or profile creation, refer these doc

I hope this information helps resolve your issue. Please feel free to ask if the provided solution does not help or if you have any additional questions.

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.