Let's say we have a custom domain name on an Azure CDN endpoint (e.g. custom domain is www-mydomain-com) that uses an Azure CDN managed certificate.
The origin for the CDN endpoint is WordPress running on an Azure App Service - origin type = Web App.
The Azure App Service native hostname is mydomain-azurewebsites-net . It should be noted that at present the Azure App Service also has the same custom domain added (www-mydomain-com) with a valid publicly trusted certificate added.
DNS CNAME for www-mydomain-com resolves to the Azure CDN endpoint hostname (mydomain-azureedge-net).
The CDN endpoint origin is set with Origin host header blank, as per the tool tip provided by Azure portal: "The host header value sent to the origin with each request. If you leave this blank, the request hostname determines this value. Azure CDN origins, such as Web Apps, Blob Storage, and Cloud Services, require this host header value to match the origin hostname by default."
This all works well. From logging we can confirm that a client requests www-mydomain-com and requests to origin are also to www-mydomain-com.
If we change the Origin host header to mydomain-azurewebsitesnet, then i see some odd behaviour.
Client requests www-mydomain-com - and the page loads as normal - I can confirm this is a cache miss.
Client requests to another URL - www-mydomain-com/test - this is again a cache miss, however logs show a call to origin - hostname is as expected set to mydomain-azurewebsites-net .
What is weird is that the client is then directed to mydomain-azurewebsites-net/test and NOT www-mydomain-com/test .
If a client re-requests www-mydomain-com/test - the page loads normal from cache.
It appears that the original client request is proxied to the origin using the origin host header - on a cache miss. What I was expecting, is that requests are only ever served to clients from Azure CDN and that the CDN pulls the content from origin into cache when needed(using the set origin host headers).
What I would like to achieve is not having to add a publicly trusted cert on the App Service(just rely on the azurewebsite-net cert for the CDN to origin TLS connection).
Am I missing anything here or is this just a limitation of Azure CDN(I am not using Verizon or Akamai Azure CDN).
I logged an MS ticket and during the course of that troubleshooting, I had a light bulb moment. The call to origin with the mydomain-azurewebsitesnet host header results in the backend WordPress loading the page with relative links into cache with host mydomain-azurewebsitesnet. This means that all links within the page - even when served from cache, reference the origin host. One fix is to hard code links with host www-mydomain-com - this is not ideal.
Not sure why I thought of it, but further testing revealed that Azure CDN calls to origin using HTTPS - require the origin cert to have the host header on the cert BUT - the certificate does NOT have to be within its valid dates. I.e. you can use an expired cert with correct host name.
This allows me to achieve my original goal.
Azure CDN - leave origin host header blank - this means client host header passes through for origin requests - means my links all work correctly. The origin WebApp uses an expired cert that has the correct host listed(that matches host sent by client). Requests from CDN to origin on HTTPS still work.
This allows me to use an Azure CDN provided and managed TLS certificate(issued by DigiCert) and NOT have to worry about renewing and managing a certificate on the Azure App Service WebApp(expired cert still works).