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
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
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.
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
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
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
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.