Summary

In a previous post I wrote about loading to the trusted root store on Windows Web Apps inside ASE, in order to trust privately issued certs. This is required if you connect over SSL to internal endpoints using privately issue certs, or make connections between sites in that ASE and use a private CA cert for the HTTPS binding.

Here I’ll share some comments that should help achieve a similar thing on Linux sites.

The reason for this post is to co-locate and explain a few important points about this setup which are a bit unclear.

Overview:

Documenting several common solutions for various Azure Front Door/App Gateway + App Service scenarios.

Why:

Proper configuration of any WAF or frontend proxy in front of App Service is an essential web infrastructure task for users. Even large organizations have trouble with this. Accurately understanding the scenario and possible solutions directly impacts the user’s ability to be successful using these Azure products.

Scenario:

This issue can surface in various ways. One of the most common issues is an unexpected redirect to and disclosure of the internal Azurewebsites.net hostname.

Client request passing through any frontend load balancer (AFD / AppGW / Cloudflare / WAF / etc) receives HTTP 301/302 redirect with Location response header revealing the backend Web App’s internal hostname (azurewebsites.net). This can commonly occur on trailing slash, post-auth redirect, or any URL the app code constructs based on request Host header.

Overview

The ability to track and audit changes to websites is a common requirement among enterprises. This audit trail helps to identify who made changes and when, either accidentally or maliciously. When running an application on a local server there are many options to achieve this, however when running in Azure App Service we must rely on the features that the platform offers because there is no access to the machine itself.

How to

We will split this discussion into two parts, first to discuss configuration/setting changes and second for file system changes.

A recent addition to Service Endpoints support is Microsoft.Web. Exactly as Service Endpoints for Azure Storage and Azure SQL allowed private access from a subnet to those PaaS services, Microsoft.Web Service Endpoints finally allows simple secure access to a backend App Service.

There are two parts to this setup:

• Service Endpoints for Microsoft.Web must be enabled on the Application Gateway’s subnet
• This subnet must be whitelisted in the Access Restrictions configuration for the backend Web App

By default applications running in an App Service will only have the normal public CAs in the trusted root store. This means that SSL connections against endpoints with a privately issued certificate will fail as untrusted. One common error message in this scenario is “SSL Certificate problem: unable to get local issuer certificate”.

A common scenario for this might be hosting 2 App Services inside an ILB ASE, one frontend and one backend, and making HTTPS calls from one -> to the other. Another scenario would be connecting from the Web App to an on-prem API secured with a self-signed or privately issued certificate.

The official Azure documentation is here: https://docs.microsoft.com/en-us/azure/app-service/environment/certificates#private-client-certificate.

The first step is to ensure that the target hostname is resolvable from the Web App, if it is hosted only in internal DNS. This step is possible for all App Services. Installing certs to the trusted root store is only currently possible using the more expensive App Service Environment (ASE).

Many developers would like their website to have support for IPv6 connectivity. Unfortunately IPv6 is not yet widely supported for most Azure services, including App Service, which includes Web Apps/Function Apps/Bot Service/etc.

The good news is that this is possible to achieve using Azure Front Door as a frontend, which does support IPv6. The Azure Front Door will then reach the Web App over IPv4.