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(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too