Is it safe not bind CERT to azure traffic manager (in front of HTTPS only app service) host name?

Question

Say, I have two app service (HTTPS only is enabled):

https://myapp1.azurewebsites.net
https://myapp2.azurewebsites.net

I can call both app service endpoints using HTTPS successfully.

Then I created a traffic manager and add above two endpoints to traffic manager, say:

myapps.trafficmanager.net

After the traffic manager is created and endpoint added, the trafficmanger host name myapps.trafficmanager.net is also automatically added into custom domains of two app services. But without SSL binding to traffic manager host name.

Then if I call traffic manager endpoint using HTTPS: https://myapps.trafficmanager.net, I will got untrusted SSL cert error/warning. That is expected.

Since traffic manager just works on DNS level, the real request is actually send to the app service endpoint which has correct SSL cert binding. My question is:

From security point of view, is it safe to call the non-cert binding traffic manager endpopint using HTTPS in my code (say, using .NET HttpClient) but just ignore the cert error?

Answer 1

I recently set one of these up as well and fought with it for a bit. The short answer is that it is probably safe, but it sounds like you may be using the Traffic Manager incorrectly. You shouldn't be using the URL in the Traffic Manager as your end point if you want to use SSL. Instead configure your vanity domain name, mycoolsite.com to point to myapps.trafficmanager.net, using a DNS CNAME record.

If you want to use SSL and a single URL you should configure the custom URL and install an SSL cert at the service level. It should be same custom URL on both app services. This must be configured at in the app service, not in Traffic Manager.

I had to read this a few times to understand how it works under the hood, but it was helpful.

So in summary, to set it up properly, the steps would be:

1. Configure custom/vanity domain on both app services
2. Install the SSL cert on both app services
3. Setup and configure the Traffic Manager
4. Point the custom/vanity URL to the traffic manager using a DNS CNAME record