Quand originHostHeader est vide, Front Door utilise le nom d'hôte de l'origine à la fois comme
en-tête Host et comme SNI de la connexion TLS. Il présente donc
agw-kasbah-prod.westeurope.cloudapp.azure.com ; l'Application Gateway répond avec son certificat
www.kasbah-voyages.ma, et comme enforceCertificateNameCheck est activé, Front Door coupe la connexion :
journal CertificateNameCheckFailed, réponse 502. Avec l'ancienne App Service, le nom
*.azurewebsites.net était couvert par le certificat de la plateforme : le problème n'existait pas.
Les serveurs sont sains (sonde de l'Application Gateway et test direct avec --resolve à 200), le WAF n'a
rien bloqué (il donnerait 403), et Front Door ne met pas en cache les 502.
Incident résolu
Analyse et correction
Correction : envoyer le bon nom à l'origine :
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 utilise ce nom pour le Host et le SNI ; le certificat correspond, l'écouteur HTTPS de
l'Application Gateway (filtré sur www.kasbah-voyages.ma) accepte la requête. Vérifier : curl -sI
redonne 200 et la requête Log Analytics montre des 200 / NoError.
Pour que cela ne recommence pas :
- pour toute origine qui n'est pas un service PaaS Azure, renseigner systématiquement l'en-tête d'hôte de l'origine avec le nom couvert par son certificat ;
- ajouter l'origine d'abord avec un poids faible ou une priorité de secours, et vérifier les journaux avant de retirer l'ancienne ;
- décrire Front Door en infrastructure as code avec un test (
curlvia le point de terminaison) dans le pipeline ; - alerter sur le taux de 5xx de Front Door (métrique
Percentage5XX).