At the moment SSL termination is possible with Application Gateway but it doesn't cater for instances where client authentication is required (mutual auth). So if client auth is required, SSL needs to be passed through and terminated on each of the web servers. This increases load across the server farm and makes management of certificates more difficult since all certs need to be maintained on all servers. I believe this function is available with API Management but the additional cost is hard to justify if one doesn't require the other additional features. So having mutual SSL auth capability built into the Application Gateway would be fantastic.

Our product creates dynamic DNS zones for our customers, e.g. foo.z1.contoso.com, bar.z2.contoso.com, etc. We use Azure DNS for this. (Notice that we stripe our customer's domains across multiple zones (z1, z2), because Azure DNS has a max record count of 5000.)

So, to support this, we have a wildcard SSL certificate for each zone e.g. *.z1.contoso.com, *.z2.contoso.com.

In order to have Application Gateway provide SSL termintation for us, we obviously need to create Multi-site listeners for port 443. Unfortuantely, the 'Host' field on the Multi-site listener does not accept wildcard entries. Furthermore, specifying the host name 'z1.contoso.com' does not appear to cover all subdomains on z1.contoso.com.

So, in order to support this flow, we would be forced to to create a new Listener for *each* customer DNS zone we create. And as I'm sure you're aware, this is a **SLOW** operation, and presents scaling/throttling issues.

The inability to specify wildcards in the multi-site listener's Host field is preventing us from adopting Application Gateway.

Azure Web Apps support the ability to store an SSL certificate in a Key Vault secret. A certificate resource can be created that references the Key Vault secret. The App service will periodically check for an updated SSL certificate in the Key Vault. The Application Gateway needs to have the same support for storing the SSL certificates in the Key Vault. It should be able to reference a Key Vault secret that contains the SSL certificate in the listener and backend HTTP settings configuration. This capability will allow the management of SSL certificates for Application Gateway and the Web Apps in a single place.

Application gateway has a very low listener limit (20 listeners / certificates). This severely limits it's usefulness for multi-tenant/domain applications where a web farm / service hosts many endpoints. IIS itself has no such small limit, but due to constraints on certificate deployment in cloud services, Application Gateway is the only clear path to wide scale SNI based SSL hosting. With it's low limit, it does not come close to meeting our use case. I would suggest the limit be removed or set to a very high limit like 10k+ so many certificates could be bound to host many different domains.

After talking to one of your Senior Support Engineers, they suggested I made a feature request for this.

I'd like to be able to pause, hibernate or otherwise stop a resource group or subscription so that it incurs minimal costs when not in use. I'm suggesting resource group or subscription as one may be easier to implement than the other. Ideally this would be done through ARM but I’d settle for doing it via PowerShell if needed.

I appreciate that VMs can be deallocated but we found that a customer's solution was still using approximately £200 a month due to the application gateway, virtual network gateway and storage of VHDs for a system that is not doing anything. As the solution is not currently contractually in use by the customer at the moment (it is used for about a month twice a year), we have to take on the cost.

I suspect that there are other services that would still be charged: For example it's only fair that storage still be billed and static Public IP addresses probably need to be as well to stay reserved but I'd like a way to put everything else into a state where it stops being accessible and therefore stops incurring charges. I would also assume that things like VMs would need to be shut down and deallocated first else problems may arise.

In the meantime I have deleted the offending services and am in the process of copying the VHDs to local storage in order to delete the VMs as well to clear the storage costs. I intend to look into PowerShell scripts to recreate these systems before the next time they are needed but obviously this method is not ideal.

I would like to be able to selectively remove some cookies and some HTTP headers from all rule application scans, on a case by case basis.

Problem Statement:
The web application firewall functionality of the application gateway scans the entire HTTP message, without the ability to customize where the scan will occur.

This leads to false positives where scan pattern matches will detect suspicious characters in URL encoded blobs like security or access tokens, or in other arbitrary places like cookies.

The following Microsoft tools have caused this problem on my environment:
- Kudu tools for web applications
- API Gateway management portal

Currently the only option I have is to disable the rule entirely, or set the rule enforcement to detect instead of block mode, and have my ops people deal with reams of false positives.

I am attaching an example screenshot where the Kudu console's cookies are being detected as SQL Injection attacks

This is an issue with the WAF's configuration of OWASP.

When the WAF is in protection mode, it is currently not possible to use the js File API to upload files in a chunked manner to an application behind the Application Gateway. Some of the "chunks" get blocked by the firewall (see attached). This doesn't happen to all chunks but it is common enough that a 100mb file will probably encounter the issue.

I have created a barebones test website which reproduces the issue here: https://github.com/elexisvenator/AzureWAF-chunked-upload-test

I have contacted the OWASP ModSecurity project, who have responded that the Firewall rule in question is particularly problematic and is recommended to disable to prevent false positives. Too see their full response go to https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/827

I hope the Application Gateway team can update the WAF configuration as quickly as possible as this issue is currently preventing deployment of production applications.