When originHostHeader is empty, Front Door uses the origin host name both as the Host header and
as the SNI of the TLS connection. It therefore presents
agw-kasbah-prod.westeurope.cloudapp.azure.com; the Application Gateway answers with its
www.kasbah-voyages.ma certificate, and since enforceCertificateNameCheck is enabled, Front Door drops
the connection: log CertificateNameCheckFailed, response 502. With the old App Service, the
*.azurewebsites.net name was covered by the platform certificate: the problem did not exist.
The servers are healthy (Application Gateway probe and direct test with --resolve at 200), the WAF
blocked nothing (it would return 403), and Front Door does not cache 502 responses.
Incident resolved
Analysis and fix
Fix: send the right name to the origin:
az afd origin update -g rg-kasbah-edge --profile-name afd-kasbah --origin-group-name og-web -n origin-agw --origin-host-header www.kasbah-voyages.ma.
Front Door uses this name for the Host and the SNI; the certificate matches, and the Application
Gateway HTTPS listener (filtered on www.kasbah-voyages.ma) accepts the request. Check: curl -sI
returns 200 again and the Log Analytics query shows 200 / NoError.
To prevent it from happening again:
- for any origin that is not an Azure PaaS service, always set the origin host header to the name covered by its certificate;
- add the origin first with a low weight or a backup priority, and check the logs before removing the old one;
- describe Front Door as infrastructure as code with a test (
curlthrough the endpoint) in the pipeline; - alert on the Front Door 5xx rate (
Percentage5XXmetric).