Problem with the same custom domain with Azure-managed certificate on both an app service and a Front Door endpoint?

I have an app service with a custom domain and an Azure managed certificate, which has worked fine for years. Recently I added a Front Door profile and of course added the same custom domain to that, with a certificate created by Azure Front Door.

In this process the DNS records for the domain were updated so that the A record is now an ALIAS to the AFD resource, and the CNAME for www points to the AFD endpoint.

However, recently Azure reported this error on the app service:

Auto-Renewal Failed... for Apex domain we must have the A record mapped to the 
webapp IP. For subdomain, we must have CNAME mapped to the webapp name.

This seems to imply that once Front Door is deployed, the web app itself can no longer have a custom domain. But there is advice from MS online that you should "Preserve the original HTTP host name between a reverse proxy and its back-end web application".

MS also states that

For HTTPS connections, Azure Front Door expects that your origin presents a certificate from a valid certificate authority (CA) with a subject name matching the origin hostname.

So I am confused about how to do this. (Maybe I have misunderstood.)

Can I have a custom domain with an Azure managed certificate on both AFD and the app service? If not, how do I meet the best practice on ensuring the original HTTP host name requested by the user also matches the app service host name?

Front Door should pass the original host header (example.com) when it forwards the request to the backend. The tricky part is TLS between Front Door and App Service.

• You don’t have to give up TLS between Front Door and App Service, but you do need to make sure the certificate served by the App Service matches the host header that Front Door sends. Since Azure-managed certificates on App Service require DNS pointing directly to the app, and yours now points to Front Door, those certs won’t auto-renew anymore.

You have two ways to go about it.

Use the App Service's default domain :

• You can set the backend host in Front Door to the app’s default hostname like yourapp.azurewebsites.net. That way, the TLS certificate that App Service provides (which is always valid for azurewebsites.net) will match the request, and Front Door will be happy.

In this case, you still preserve the original host header (example.com) so that your app behaves as if the request came in with that domain.

Example config:

"backend": {
  "address": "yourapp.azurewebsites.net",
  "hostHeader": "example.com",
  "protocol": "Https"
}

This avoids the need to manage certificates manually.

Use a custom certificate on App Service :

• If you really need Front Door to connect to App Service using example.com as the hostname (both in the host header and the TLS SNI), then App Service must present a valid TLS certificate for example.com.

Since Azure-managed certs won’t work anymore in this case, you’d need to bring your own certificate (from Let’s Encrypt, DigiCert, etc.), upload it to App Service, and bind it to the custom domain.

This gives you full TLS all the way through, but now you’re responsible for renewing and managing that cert.