Since July 19th I’ve encountered an issue with Azure web apps calling each other server side, something that previously worked flawlessly now fails with 403 errors. I believe it’s likely to be related to their recent TLS 1.2 initiative mentioned in this blog post - https://blogs.msdn.microsoft.com/appserviceteam/2018/05/02/breaking-change-for-sni-ssl-hostnames-on-azure-app-service/
The problem occurs when I’m doing server-side http requests (browsers not involved). I’m only encountering the issue when both endpoints are using custom domains employing Cloudflare so I’m reaching out in the hope someone can help me understand what the issue might be and maybe help me arrive at a solution.
An example of the failing call:
topomap.co.nz is making a request server-side to the url provided in the query parameter, permitwatch.co.nz in this case.
topomap.co.nz is using Cloudflare’s Full SSL, with the certificate loaded server side in Azure being the same wildcard domain certificate used by https://tiles-1.topomap.co.nz/ (my map tiles are hosted elsewhere on a non-Azure service). In Azure the binding is SNI SSL.
permitwatch.co.nz is using Cloudflare’s Flexible SSL option. No other ceriticates involved.
If I replace either topomap.co.nz or permitwatch.co.nz with an some-app-name.azurewebsites.net equivalent (the default url used by Azure before adding a custom domain) everything works seamlessly again.
The 403 seems to be coming directly from permitwatch.co.nz as there’s no Cloudflare branding on the message displayed.
I can use https://www.topomap.co.nz/proxy.ashx to call out to any other non permitwatch.co.nz without issue e.g.
And just to provide a bit of background - I’m proxy’ing files to avoid CORS issues for people wanting to overlay GPS tracks etc. on to the map. People who mostly lack the technical expertise to setup CORS their side of things e.g.
Thanks in advance for any insights that anyone can provide.
I’ve put in place a horrible hard-coded hack in place (redirecting to alternative urls) so the following will now work:
but to still test without the hack in place &test can be added to the end of the url: