Azure Front Door custom domain serving *.azureedge.net cert instead of AFD managed cert after subscription reactivation

The custom domain is correctly configured in the portal, but browsers are still seeing the default *.azureedge.net certificate. This matches the documented scenario where a Front Door edge node doesn’t have the expected certificate loaded or the managed certificate hasn’t fully propagated after a disruption (such as subscription suspension/reactivation).

Use these steps to verify and remediate:

1. Confirm certificate deployment status
   In the Azure portal, open the Front Door profile and go to the custom domain reports.securesolutions.co.za. Ensure:
   • Certificate state is Deployed (already green per description).
   • Validation state is Approved.
2. Verify what certificate is actually being served
   From a client in an affected region:
   • Browse to https://reports.securesolutions.co.za and inspect the certificate. Confirm that the CN is *.azureedge.net and not the custom domain.
   • Alternatively, use curl -Iv https://reports.securesolutions.co.za and check the certificate details.
3. Confirm traffic is going through Front Door
   Use browser developer tools or curl -v to inspect response headers and verify that an x-azure-ref header is present. This confirms the request is being handled by Front Door and not some other endpoint.
4. Check DNS and CNAME
   Even though the portal shows “Traffic is delivered securely,” re‑validate DNS:
   • Use a DNS lookup tool (for example dig reports.securesolutions.co.za) and confirm the CNAME points directly to the Front Door endpoint hostname, not via an intermediate record or A record.
   • If the CNAME is missing or chained, managed certificate rotation/propagation can fail.
5. Allow for propagation time
   After subscription changes or certificate re‑issuance, it can take up to an hour (and in some cases longer) for the managed certificate to propagate to all Front Door edge servers. If the subscription was just reactivated and the cert re‑provisioned, wait up to 60 minutes and retest.
6. Force a fresh certificate rollout (if still serving *.azureedge.net)
   If, after at least an hour, the domain still serves *.azureedge.net:
   • In the portal, open the custom domain and toggle HTTPS off (or switch temporarily to BYOC if available), save, then switch back to Front Door managed certificate and save again. This forces a new certificate issuance and deployment.
   • Wait for deployment to complete and retest with curl -Iv.
7. Escalate via support if the issue persists
   If all of the following are true:
   • The custom domain shows Certificate state: Deployed and Validation state: Approved for more than an hour.
   • DNS CNAME is correct and points directly to the Front Door endpoint.
   • Requests contain x-azure-ref but still receive *.azureedge.net as the certificate.
   Then one or more Front Door edge servers likely still lack the correct certificate. Collect:
   • The custom domain name.
   • Sample curl -Iv output showing the wrong certificate.
   • Geographic locations / IPs where the issue reproduces.
   • The Azure troubleshooting result mentioning RetryWithUpdatedVersion.
   Use this data to open an Azure support request so the platform team can refresh the certificate deployment on the affected edge nodes.

References:

• Troubleshoot Azure Front Door certificate problems
• Domains in Azure Front Door
• Azure Front Door - Custom Domain certificate provisioning is incorrect. - Microsoft Q&A
• AFD managed certificate not propagating to edge nodes after subscription reinstatement - Microsoft Q&A