Site icon TheWindowsUpdate.com

Walkthrough: Configuring end-to-end TLS with Application Gateway and Internet Information Services

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Permalink: https://aka.ms/ftaisve2essl

 

Are you looking to configure end-to-end TLS to a backend web server that hosts multiple sites with a wildcard certificate? This blog provides a walkthrough of configuring an Application Gateway with multi-site listeners and a wildcard certificate with end-to-end TLS. Application Gateway is a web traffic (HTTP/HTTPS) load balancer and web application firewall that can be used as an ingress solution for a variety of web application backends, including virtual machines.

 

The FastTrack for Azure team recently helped a customer migrate an application from on-premises to Azure. The on-premises configuration included physical servers with IIS-based web applications running on Windows Server 2016. The first phase of the migration was a simple lift-and-shift to virtual machines and introduced an Application Gateway as the front-end ingress solution.

 

The IIS server was configured with multiple websites and accepted traffic on different sub-domains for each website. Each IIS site was configured with the same wildcard certificate for the domain name being used. The Azure architecture started simple, with a single Application Gateway with one public front-end IP address and one backend pool: a single web server.

Figure 1 - Overall architecture diagram

 

IIS configuration

The IIS configuration is fairly simple and uses multiple IIS sites. The sites in IIS are configured with bindings for port 443 and a domain name for each web app in the binding. Figure 2 displays the IIS configuration for the webapp1 site. The selected certificate for each site is a wildcard certificate for the domain, *.hugelab.net.

Figure 2 - IIS binding configuration

 

Application Gateway configuration

The overall configuration of the Application Gateway includes one frontend IP address and one backend pool, the IIS server. Then for each site, the following components are configured:

The configuration of the frontend IP address and the backend pool follow the default configuration that is found in the corresponding documentation.

Health probe

By default, a listener will use a built-in health probe using the HTTP settings that you define to communicate and verify the health of the backend pool before sending traffic. If you are using an App Service or a single site configuration, the default health probe will most likely return healthy. If you have multiple sites defined or are using a wildcard certificate, you might receive the following error in the Backend Health:

 

 

 

 

“The Common Name (CN) of the backend server certificate does not match the host header entered in the health probe configuration (v2 SKU) or the FQDN in the backend pool (v1 SKU). Verify if the hostname matches with the CN of the backend server certificate.”

 

 

 

 

Additionally, when trying to access the site through the Application Gateway, you receive error 502 Bad Gateway.

The solution for this is to create a custom health probe for each site that matches the domain name configured in IIS and in the corresponding HTTP setting. Figure 3 displays the configured health probe.

 

Figure 3 - Custom probe settings

 

HTTP settings

An Application Gateway requires HTTP settings to determine several settings for the communication from the Application Gateway to the backend pool, including:

For this configuration, the specific configuration details are for the certificate, hostname, and custom probe settings.  Settings for each are:

Note: * indicates the default configuration and did not apply in our scenario.

 

The backend IIS server uses a wildcard certificate from a trusted third-party CA (In this scenario, the certificate is issued from Digicert.) Therefore, the Use well-known CA certificate option is set to Yes. If the backend pool were using an “unknown” or internal CA, then this option must be set to No, and you would need to upload the public trusted root and intermediate certificates that correspond to the certificate that the backend pool is using.

The IIS server binding is set to listen for a specific domain name but with a wildcard certificate. Therefore, the binding name and certificate Common Name (CN) don’t exactly “match”. The hostname configuration is set to Override with specific domain name, and the domain used matches the corresponding site in IIS. Finally, the custom probe is set to the previously configured health probe. Figure 4 displays the HTTP setting configuration.

Figure 4 - HTTP settings

 

Listener

The Listener for each site is a typical configuration using a single domain name configuration. The listener for each site uses the same frontend IP address and accepts traffic on 443. The listener for Site 1 is configured to accept hostname webapp1.hugelab.net and is configured to present clients with a wildcard certificate that was uploaded directly to the Application Gateway.

Figure 5 displays the listener configuration.

 

Figure 5 - Listener settings

 

Rule

The rule configuration is also standard and brings together the configured listener, HTTP setting, and backend pool.

 Figures 6 and 7 display the rule configuration with the selected components.

 

Figure 6 - Rule settings - Listener

Figure 7 - Rule settings - Backend targets

 

Summary

The key component of this deployment is in the configuration of the health probe and HTTP settings for each of the sites. In this scenario of using a wildcard certificate with multiple sites in IIS, the default health probes might not recognize the IIS server as being healthy. By adding the custom health probe associated with each domain name, we can check the status of each site running on IIS and match the domain names in the Application Gateway to the IIS server.

Exit mobile version