Skip to main content

Configure Traffic Manager and Web Apps over SSL (HTTPS) using custom domain

In this topic we will cover what we shall do when we:
  • Configure Azure Traffic Manager on top of Web Applications hosted inside App Services 
  • Over HTTPS
  • With custom domain 
  • Client certificates
Context
When we are using HTTPS in combination with App Services, everything will go smooth. You just need to activate the HTTPS and upload client certificate, if you want to use a custom one.
Things are a little different when you want to configure HTTPS on top of Traffic Manager. In theory, the steps are clear and it should work as expected, but combined this with custom domain and client certificates things can end up with a 404 error code..

Initial Setup
Pre requirements: Web Apps are configured over SSL using custom domain and works as expected.
Let’s take a look on the base steps that needs to be done when you want such a configuration

  • Create an instance of Traffic Manager inside Azure Portal and add your Web Apps that you already configured for HTTPS
  • Add your custom domain to your DNS Record – this step is done in the tool provided by the company from where you bought the domain (you will need to add the Traffic Manager domain name
  • Wait for DNS change to propagete
  • Inside each Web App add to Custom Domains the CNAME that you want (e.g. www.rv.com)

We are done! You now need to access your application.

Surprise – 404
When you try to access your custom domain over SSL you get a 404 error code. If we look on the logs on each web application, we will not be able to find any 404 errors. The only thing that we could see would be the health check on each web site, that are done by traffic manager.
Let us analyze the problem. Traffic Manager is just a DNS proxy (level 3). This means that he does not handle any request, just making the right redirection. Traffic Manager will never return an error code like this, because is just a DNS proxy.
This means that error code comes from our web application. However, 404 is strange, especially if we cannot find any logs related to it. Inside Kudu, we will not be able to see any requests that are coming to our web application. This means only one things – the error code is appearing during the handshake of SSL.

Cause
We have configured the list of custom domain inside our web application to contain the one that we want to use. Automatically, Traffic Manager added his domain name inside each web application.
Nevertheless, for Traffic Manager you configured a custom sub domain that was not added in each Web Application.

Solution
You need to add the custom CNAME of your traffic manager inside each Web Application or you can use a SSL certificate without alternatives names. I usually prefer the first options, because I have better control. Not all the time I can control a certificate that was generated by a 3rd party.

Conclusion
This is that kind of configuration that you forget about it in one week, but each time you will lose a few hours to find the root cause.

Comments

  1. Hi. Really useful article though I'm struggling a little with the last part - the custom CNAME of my traffic manager appears to be already (automatically) added within the web app custom domains but I'm still seeing the 404 problem.

    How do you use an SSL certificate to get it working instead?

    Thanks,

    James

    ReplyDelete

Post a Comment

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP