Change root cert only in cert used by Front Door

Question

Change root cert only in cert used by Front Door

Mattia 36

Hello,

in a website published through Front Door (classic), we have been using certificates issued by Sectigo, who started using their new root certificates in June.

We renewed the certificate in the past weeks, and the .pfx I created and uploaded to the Key Vault contained the new root certificate.

Unfortunately, an application that needs to connect there doesn't recognize the new root yet and it's proving to be paid to update the set of CA, so I wanted to change the root -and only the root- to the previous one that is signed by another CA. That's fine to do, since the intermediate is unchanged and cross-signed; in fact I have accidentally being used the same certificate with the "old" chain in another place successfully.

I created a new .pfx with the new cert but old chain:

% openssl pkcs12 -info -in foo.pfx
...
Certificate bag
Bag Attributes
    localKeyID: 22 32 98 41 54 73 10 FB BE 8B 27 FE 5A 64 B7 F9 17 23 60 36
subject=CN=*.XXXXXXXXXXXX
issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
.....
Certificate bag
Bag Attributes: <No Attributes>
subject=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
......
Certificate bag
Bag Attributes: <No Attributes>
subject=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
issuer=C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority

Nevertheless, Front Door does not seem to pick this. I also tried explicitly selecting this certificate in the drop-down instead of "Latest", but as I can clearly see using openssl s_client:

% openssl s_client -showcerts -connect XXXXXXXXX:443  </dev/null 2>&1|grep -C 4 R46
Connecting to 2620:1ec:27:e621::cafe:e621
depth=2 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
verify return:1
depth=1 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
verify return:1
depth=0 CN=XXXXXXXXXX
--
1TOMkqZgk/ygV2PmUrhdM6KfuwVooWZHSbtJo+PFmyBeoQA+TONNVTVRFSLSAktr
mHVXR9JpJKaGzoIEd+WwjnPRefIX2V1176I=
-----END CERTIFICATE-----
 1 s:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
   i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
   a:PKEY: RSA, 3072 (bit); sigalg: sha384WithRSAEncryption
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2036 GMT
-----BEGIN CERTIFICATE-----
MIIGTDCCBDSgAwIBAgIQOXpmzCdWNi4NqofKbqvjsTANBgkqhkiG9w0BAQwFADBf
--
7ABvc7BYSQubQ2490OcdkIzUh3ZwDrakMVrbaTxUM2p24N6dB+ns2zptWCva6jzW
r8IWKIMxzxLPv5Kt3ePKcUdvkBU/smqujSczTzzSjIoR5QqQA6lN1ZRSnuHIWCvh
JEltkYnTAH41QJ6SAWO66GrrUESwN/cgZzL4JLEqz1Y=
-----END CERTIFICATE-----
 2 s:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
   i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
   a:PKEY: RSA, 4096 (bit); sigalg: sha384WithRSAEncryption
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2046 GMT
-----BEGIN CERTIFICATE-----
MIIFijCCA3KgAwIBAgIQdY39i658BwD6qSWn4cetFDANBgkqhkiG9w0BAQwFADBf

Which is the new self-signed root, not the old one.

What could I possibly be missing here? Thank you in advance.

Anonymous

2025-09-22T08:40:54.81+00:00
Hi Mattia,

Thanks for your detailed question on Microsoft Q&A!

As you renewed your TLS/SSL certificate for Azure Front Door (classic) with a new Sectigo root certificate. Your client app doesn’t trust this new root yet, so you want Azure Front Door to serve the old root certificate chain while keeping the leaf and intermediate certificates the same. You tried creating a new .pfx with the old root cert chain and uploaded it to Key Vault, but Azure Front Door still serves the new root.

This is because:

Azure Front Door (Classic) does not allow custom certificate chains. Even if you upload a .pfx with a specific root or intermediate, Front Door will:

Rebuild the chain automatically using the leaf certificate

Ignore the root and intermediate certificates in your .pfx

Use the default chain trusted by Azure’s platform

This behavior is documented and intended to ensure consistency and security across Azure’s global edge network.

https://xtls-v4.hkg1.meaqua.org/en-us/azure/frontdoor/front-door-custom-domain-https?tabs=powershell#certificate-management

What You Can Do

Use Azure Front Door Standard/Premium:

Azure Front Door (Standard/Premium) does support custom certificate chains via Key Vault integration. If migrating is feasible, this would allow you to:

Upload a .pfx with your preferred chain

Serve the exact chain (including older root) to clients

https://xtls-v4.hkg1.meaqua.org/en-us/azure/frontdoor/front-door-custom-domain-https?tabs=powershell#bring-your-own-certificate

Update Client Trust Store:

If migration isn’t possible, consider updating the client application’s CA trust store to include the new root certificate. This ensures compatibility with the default chain served by Front Door Classic.

Use Application Gateway or CDN:

If Front Door migration isn’t viable and you need full control over the certificate chain, consider using:

Azure Application Gateway with custom certificates

Azure CDN (Standard Akamai) which may offer more flexibility

Upload the full, correct certificate chain to Azure Key Vault:

The .pfx should contain the leaf, intermediate, and the desired root certificates in the right order. Azure Front Door will serve whatever chain it receives. I hope this helps to resolve the issue.

Thank you,

Pranitha
Mattia 36 Reputation points

2025-09-22T13:53:38.5066667+00:00
Thank you for your answer!

I see, so my options are:

update my application

change CDN type to the new one

Can I ask you to point out the exact quote in https://xtls-v4.hkg1.meaqua.org/en-us/azure/frontdoor/front-door-custom-domain-https?tabs=powershell#certificate-management that says that we can't import a whole chain? Because it says "You can use your own certificate through an integration with Azure Key Vault. Ensure your certificate is from a Microsoft Trusted CA List and has a complete certificate chain" and "The certificate must have a complete certificate chain with leaf and intermediate certificates, and root CA must be part of the Microsoft Trusted CA list" which actually made me believe it would also use them as provided.
Mattia 36 Reputation points

2025-09-24T07:31:04.49+00:00

Alright, I'm trying out Front Door Standard and I can confirm it is showing my certificate with the chain (including the root) that I want it to use. So that's fine for me.

However I can tell you that the wording in the documentation regarding the Classic is very misleading in this regard… I would recommend you to rewrite that part, but since Classic is going away soon and it's already impossible to create new profiles, it likely does not matter anymore at this point...

Guess this was the push I needed to move from Classic to Standard!

Thank you for your input, it was invaluable in this case.
Anonymous

2025-09-24T08:15:56.5166667+00:00

Hi Mattia,

Thank you very much for your feedback and for sharing your experience with Azure Front Door Standard. I'm really glad to hear that it's now displaying the certificate chain exactly as you intended.

I apologize for any confusion caused by the wording in the documentation regarding the Classic version. Your suggestion to improve the docs is extremely valuable, and I appreciate you bringing it to our attention. As you rightly pointed out, with Azure Front Door (Classic) being phased out and migration to Standard/Premium encouraged, we hope this transition becomes smoother for everyone moving forward.

Please let me know if you require further assistance.

Thanks!
Anonymous

2025-09-25T16:07:23.77+00:00

Hi Mattia,

Thank you so much for confirming that Front Door Standard is now displaying the certificate chain as expected and I’m glad to hear it’s working for you!

We truly appreciate your feedback regarding the documentation for Front Door Classic. You're absolutely right that the wording could be clearer, and with Classic being deprecated, we hope the transition to Standard continues to be smooth for everyone. Your insights are valuable and help us improve.

If this response helped resolve your issue, we’d be grateful if you could mark it as accepted so others in the community can benefit from your experience.

Thanks again for your thoughtful input!

2 answers

Your answer

Mattia 36 Reputation points

2025-09-22T13:53:38.5066667+00:00

Thank you for your answer!

I see, so my options are:

update my application

change CDN type to the new one

Can I ask you to point out the exact quote in https://xtls-v4.hkg1.meaqua.org/en-us/azure/frontdoor/front-door-custom-domain-https?tabs=powershell#certificate-management that says that we can't import a whole chain? Because it says "You can use your own certificate through an integration with Azure Key Vault. Ensure your certificate is from a Microsoft Trusted CA List and has a complete certificate chain" and "The certificate must have a complete certificate chain with leaf and intermediate certificates, and root CA must be part of the Microsoft Trusted CA list" which actually made me believe it would also use them as provided.
Mattia 36 Reputation points

2025-09-24T07:31:04.49+00:00

Alright, I'm trying out Front Door Standard and I can confirm it is showing my certificate with the chain (including the root) that I want it to use. So that's fine for me.

However I can tell you that the wording in the documentation regarding the Classic is very misleading in this regard… I would recommend you to rewrite that part, but since Classic is going away soon and it's already impossible to create new profiles, it likely does not matter anymore at this point...

Guess this was the push I needed to move from Classic to Standard!

Thank you for your input, it was invaluable in this case.
Anonymous

2025-09-24T08:15:56.5166667+00:00

Hi Mattia,

Thank you very much for your feedback and for sharing your experience with Azure Front Door Standard. I'm really glad to hear that it's now displaying the certificate chain exactly as you intended.

I apologize for any confusion caused by the wording in the documentation regarding the Classic version. Your suggestion to improve the docs is extremely valuable, and I appreciate you bringing it to our attention. As you rightly pointed out, with Azure Front Door (Classic) being phased out and migration to Standard/Premium encouraged, we hope this transition becomes smoother for everyone moving forward.

Please let me know if you require further assistance.

Thanks!
Anonymous

2025-09-25T16:07:23.77+00:00

Hi Mattia,

Thank you so much for confirming that Front Door Standard is now displaying the certificate chain as expected and I’m glad to hear it’s working for you!

We truly appreciate your feedback regarding the documentation for Front Door Classic. You're absolutely right that the wording could be clearer, and with Classic being deprecated, we hope the transition to Standard continues to be smooth for everyone. Your insights are valuable and help us improve.

If this response helped resolve your issue, we’d be grateful if you could mark it as accepted so others in the community can benefit from your experience.

Thanks again for your thoughtful input!

Answer 1

Hi Mattia,

Thanks for your detailed question on Microsoft Q&A!

"You can use your own certificate through an integration with Azure Key Vault. Ensure your certificate is from a Microsoft Trusted CA List and has a complete certificate chain."

"The certificate must have a complete certificate chain with leaf and intermediate certificates, and root CA must be part of the Microsoft Trusted CA list."

This means that when you upload your certificate to Azure Key Vault for use by Azure Front Door:

Your .pfx file must contain the complete chain, which includes the leaf certificate and the intermediate certificates.
The root CA certificate should be from a Microsoft Trusted CA List, meaning it must be an officially trusted root by clients and Microsoft’s platform.

However, crucially for Azure Front Door (Classic):

Azure Front Door Classic does not serve the root certificate from your uploaded chain.
Azure Front Door Classic automatically rebuilds the certificate trust chain on its side based on the leaf certificate and uses the root certificates trusted and distributed by Microsoft’s global network.
This means even if you upload a PFX with an older or custom root certificate, Front Door will ignore it and serve the root it trusts internally.
This behavior ensures chain consistency and security across Azure’s edge nodes but restricts control over which root certificate is actually presented to clients.

If you want explicit control over the entire certificate chain, including root:

Consider migrating from Azure Front Door Classic to Azure Front Door Standard or Premium, which support custom certificate chains with full Key Vault integration, allowing you to serve exactly the chain you upload.

I hope this helps to resolve the issue.

Thanks!

Answer 2

Hello,

I'm experiencing the exact same issue as Mattia with Azure Front Door Premium (not Classic). I have a Sectigo wildcard certificate with a cross-signed chain for backward compatibility with legacy devices, but AFD is serving the modern self-signed root instead of the cross-signed path I uploaded.

My setup:

Azure Front Door Premium (SKU: Premium_AzureFrontDoor)
Certificate stored in Azure Key Vault as PFX
PFX contains the complete cross-signed chain:
- Leaf: *.domain.com
- Intermediate: Sectigo Public Server Authentication CA DV R36
- Cross-signed Root: Sectigo Public Server Authentication Root R46 (issued by AAA Certificate Services)
- Old Root: AAA Certificate Services

What I see:

When I download the PFX from Key Vault and inspect it with openssl pkcs12 -info, it shows the correct cross-signed chain with AAA Certificate Services as the final issuer.

However, when I test with openssl s_client -connect login.domain.com:443 -showcerts, AFD is serving only 3 certificates ending with the self-signed Sectigo Root R46, completely ignoring the cross-signed path.

I need the cross-signed chain for compatibility with legacy systems that only trust the older AAA Certificate Services root (2004), not the newer Sectigo Root R46 (2021). The same certificate bundle works perfectly on nginx, serving all 4 certificates including the cross-signed root.

My question:

Mattia solved this by migrating from Front Door Classic to Front Door Standard. However, I'm already using Front Door Premium which should have even more features than Standard.

Does AFD Premium support serving custom certificate chains as uploaded, or does it automatically optimize/rebuild the chain like Classic did? If not, what are my options?

I've been working with Microsoft Support (case #2512040050001300) but haven't received a definitive answer yet on whether this is a service limitation or a configuration issue.

The documentation states "The certificate must have a complete certificate chain with leaf and intermediate certificates" but doesn't clarify whether AFD respects cross-signed certificate paths or automatically selects the "optimal" chain.

Additional context:

Custom domain provisioning state: Succeeded
Certificate type: CustomerCertificate
Same PFX works correctly on nginx with full cross-signed chain
Testing shows AFD serves the modern chain (3 certs) instead of the cross-signed chain (4 certs)

Any guidance on whether this is supported in AFD Premium is advised.

Thank you!

Share via

Change root cert only in cert used by Front Door

2 answers

Your answer