AFD Standard managed cert shows "Deployed" in portal but edge serves the expired cert (profile-wide)

The described behavior matches a known class of Azure Front Door issues where the control plane shows a managed certificate as Deployed, but some edge nodes continue to serve an older certificate.

From the available information, the context provides only partial coverage of this scenario, so only the supported parts are addressed below.

1. Why “Deployed” while edge serves the previous/expired cert, and how to force edge to pick it up

The documented behavior for Azure Front Door managed certificates is:

• When switching between certificate types (managed ↔ BYOC), or when renewing, it can take up to an hour for the new certificate to propagate to all edge servers.
• During this period, Front Door can continue to use the previous certificate until domain ownership is revalidated and the domain state is Approved.
• For managed certificates, if DNS conditions for automatic renewal aren’t met (for example, CNAME not pointing directly to the Front Door endpoint, chained CNAMEs, A records, or apex domains with CNAME flattening), the domain can move into Pending Revalidation, and the CA will not issue or re-issue a new cert until TXT-based validation is completed.

Relevant documented points:

• “When switching to a managed certificate, Azure Front Door continues to use the previous certificate until the domain ownership is revalidated and the domain state becomes Approved.”
• “Azure Front Door automatically renews managed certificates… However, Azure Front Door won't automatically rotate certificates in the following scenarios: CNAME not pointing directly to the endpoint, chained CNAME, A record, apex with CNAME flattening. In these cases, 45 days before expiry the domain validation state becomes Pending Revalidation and a new DNS TXT record is required.”

If the domain can’t be validated, the state becomes Rejected and the CA rejects re-issuance.

There is no documented control-plane operation that forces a “hard” edge redeploy beyond:

• Ensuring the domain is Approved.
• Ensuring DNS (CNAME and TXT) meets the renewal requirements.
• Waiting for propagation (up to ~1 hour) after a successful deployment.

If, after the certificate state is Deployed and more than an hour has passed, some users still intermittently receive the wrong certificate, the official guidance is to:

• Confirm the certificate state is Deployed in the portal.
• Capture traffic from affected clients and verify:
  • The certificate presented is the unexpected one (for example, *.azureedge.net or an older cert).
  • The response includes x-azure-ref headers, confirming traffic is handled by Front Door.
• If all of the above are true and the issue persists, open a support request with the captured data and affected geography. This is the documented escalation path when an edge node doesn’t have the expected certificate loaded.

2. What causes profile-wide edge deployment to stall while another profile renews fine

The documentation does not describe a profile-wide “stall” condition or a specific cause where one profile’s edge deployment fails while another’s succeeds. It only states conditions under which automatic renewal and rotation of managed certificates will not occur:

• CNAME not pointing directly to the Front Door endpoint.
• Chained CNAMEs.
• Use of A records instead of CNAME.
• Apex domains with CNAME flattening.

In those cases, the domain moves to Pending Revalidation and requires a new TXT record for domain ownership validation.

Any behavior beyond these documented conditions (for example, a systemic profile-wide edge deployment stall with the control plane showing “Deployed”) is not covered in the provided material. The only supported guidance is to follow the troubleshooting steps for certificate issues and then open a support request if the problem persists after validation and propagation.

3. Domains in PendingRevalidation with matching _dnsauth records – is “Regenerate” correct, and does it re-trigger edge deployment?

The documentation states:

• DNS TXT records used for validation expire after seven days.
• If a TXT record was previously added, it must be replaced with a new TXT record; reusing the old value causes validation to fail.
• When a domain is in Pending Revalidation, a new TXT record is required to revalidate ownership.

Relevant points:

• “DNS TXT records expire after seven days. If you previously added a domain validation TXT record to your DNS server, you need to replace it with a new TXT record. Ensure you use the new value, otherwise the domain validation process will fail.”
• “If your domain can't be validated, the domain validation state becomes Rejected.”

The context does not explicitly describe a “Regenerate” button, but it does describe the need to refresh the validation token (for example, via Update-AzFrontDoorCdnCustomDomainValidationToken) to expedite creation of a new certificate. In practice, this corresponds to regenerating the validation token and then updating the _dnsauth TXT record with the new value.

Once:

• The validation token is refreshed, and
• The new TXT record is correctly published and visible, and
• The domain state returns to Approved,

Front Door will proceed with issuing/renewing the managed certificate and deploying it to the edge. The documentation notes that certificate deployment/rotation can take up to 72 hours for customer-managed certs via Key Vault; for managed certs, propagation is typically up to one hour.

So, for domains in PendingRevalidation:

• The correct recovery is to obtain a new validation token (for example, via the documented token refresh mechanism) and update the _dnsauth TXT record accordingly.
• After successful validation and the domain returning to Approved, the managed certificate will be reissued and deployed; edge deployment follows the normal propagation timelines.

If, after these steps and sufficient time, the edge still serves the wrong or expired certificate, the documented next step is to collect evidence (including x-azure-ref headers) and open a support request.

References:

• Domains in Azure Front Door
• Troubleshoot Azure Front Door certificate problems
• Troubleshoot custom domain issues in Azure App Service for web apps on Windows and Linux
• Troubleshoot Azure App Service certificates
• Cert Renewal - Microsoft Q&A
• Custom domain still validating after 12 hours - Microsoft Q&A
• DP 203 certificate expired a week ago - Microsoft Q&A
• Azure Deployment Takes 70 Minutes to Fail with Obscure Error - Microsoft Q&A
• Certificate Not Received - Microsoft Q&A