Alternative to Application Gateway allowing backend pool SSL certificates to be ignored

Question

We host a host hundreds of client websites, using their public domains, on a cluster of Apache web servers in Azure. Due to the mass cost and complexity that would be involved in trying to maintain trusted SSL certificates for these client sites on the web servers, we use self-signed certs, but present valid client certs at a higher level via free and automated certificate management that AWS Cloudfront and ACM provides. Currently we load balance the traffic coming from CloudFront, to the web servers, via pair of virtual BigIP F5s, which don't care that the backend pool server certs are not valid/trusted. The end result is traffic is encrypted end-to-end and everything works.

Our goal is to move off of the F5s and onto an Azure native service to reduce costs and increase scalability. The obvious choice is using the Azure Application Gateway service, but maddingly the AppGw requires that the backend server's certificates be trusted and valid, and Microsoft doesn't provide a way to disable that requirement. We don't want to start using HTTP unencrypted traffic for the AppGw-to-Backend flow to bypass this for obvious reasons. I considered using the Azure Load Balancer service, but if we used that we'd need a way to restrict the traffic to only come from CloudFront, and there isn't a way that I can find in the Azure LB service that lets you do that in any form, such as using custom HTTP header validation. We could whitelist the CloudFront IPs in the LB's NSG, but those IPs constantly change and I don't want to manage or set up complex automation as the goal is to keep things simple and straightforward with the least amount of moving parts.

Seeing if anyone has any other suggestions?

Thanks,

Logan

Answer 1

@Kampsnider, Logan

Thank you for reaching out.

Based on your question above.

The obvious choice is using the Azure Application Gateway service, but maddingly the AppGw requires that the backend server's certificates be trusted and valid, and Microsoft doesn't provide a way to disable that requirement.

Yes, your understanding here is correct. If you wish to request this as a feature for Azure Application Gateway it will help if you could file a feedback item on the Azure Feedback portal here.Not sure if you are already aware of this but just sharing this as a suggestion:

I understand you have already mentioned

We don't want to start using HTTP unencrypted traffic for the AppGw-to-Backend flow to bypass this for obvious reasons.

Although if it helps incase if you choose to have TLS termination at Application Gateway. In Azure application gateway you can add backend pool member with Internal IP addresses. An application gateway can communicate with instances outside of the virtual network that it's in. In your case above you can add the Apache Web App server as backend pool member of Application Gateway using its private IP address. To establish this connectivity you can set-up virtual network peering between Application Gateway's Virtual Network and the Virtual Network Containing your backend server. You can find more details here.

• This way if the backend pool is configured using private IP address, the application gateway routes the request to the backend server by using its instance private IP addresses. Even though the traffic is not encrypted (HTTP) but this way the traffic is routed via Azure Private Network and does not traverse the internet. The scenario is also mentioned in the Network Security best practices here " Use Azure Application Gateway, an HTTP web traffic load balancer. Application Gateway supports end-to-end TLS encryption and TLS termination at the gateway. Web servers can then be unburdened from encryption and decryption overhead and traffic flowing unencrypted to the back-end servers."
• The above solution will also help improve backend performance and help in better utilization of the backend servers.
• Certificates only need to be purchased and installed on the application gateway and not all backend servers. This saves both time and money. You can also go through this preview feature TLS certificates management for listeners for better management of certificates.

Hope this helps! Please let me know if you have any additional questions regarding the suggestion above and we gladly continue our discussion. Thank you!