Udostępnij za pośrednictwem

End to End SSL with Azure Application Gateway

  • Artykuł

<Updated Service Note>
Please note that this capability has now been integrated into Application Gateway, and you no longer need to handle redirection on your IIS servers (though you still could if desired). Please see /en-us/azure/application-gateway/application-gateway-redirect-overview for more information.
</Updated Service Note>

Azure Application Gateway is a layer 7 load balancer with features such as SSL termination, WAF and multiple routing options. For web applications this is a great option for load balancing your applications across multiple back end servers where the Azure Load Balancer may not meet your requirements. In this post, I'll walk through an architecture that provides a public endpoint, end to end SSL leveraging separate certificates for the internal and external communication, and HTTP to HTTPS redirection on IIS. This can be deployed through the following Azure Resource Manager template, we'll talk through all the pieces here and how they work.

https://github.com/Azure/azure-quickstart-templates/tree/master/201-application-gateway-2vms-iis-ssl

Template Deployment

Review the README for the template to ensure you have the prerequisites completed. You'll need certificates available to properly deploy it, so take a quick read through it. To deploy the template, you can click the "Deploy to Azure" button. This will pop open the portal where you can fill in the parameters.
deploy-to-azure-button

Upon completion you'll have the following resources deployed:

  • VNet with two subnets (AppGatewaySubnet and WebSubnet)
  • Two Windows 2016 VMs with IIS installed. These will have a very basic static default page that will say which server you're on (Server 1 or Server 2) so you can see the load balancing in action.
  • Application Gateway with WAF enabled. SSL will be terminated on the Application Gateway and will also communicate to the back end servers via SSL.

appgwarch

Once deployed, connect to the URL of the Application Gateway via HTTP or HTTPS. You can find this in the frontend public IP address value on the Overview panel for the Application Gateway you just deployed.

appgw

If you are using self signed certificates on the Application Gateway you will get a warning message in your browser when you connect via HTTPS. This is expected as we cannot verify the certificates, but is expected. Once connected you should see pages with the below content, flipping between each server as you refresh the page (since session persistence is disabled). Making an initial connection via HTTP should redirect you to HTTPS.

server1 server2

End to end SSL

When you deploy the template you'll notice you need to provide some certificates. This is where the end to end SSL comes in to play. The front end certificate is your public certificate that terminates SSL on the Application Gateway. This will need to be in .pfx format and for the template will need to be converted to base-64 encoding so it can be uploaded in a text format. Details on how to do this conversion are available in the README.md in the repo. The back end certificate is the certificate that the web servers will use to communicate to the Application Gateway. In this template, we install the .pfx cert on the web servers, and also need the public key extracted so we can add it to the Application Gateway (both of these also in base-64 encoding for template deployment). This public key whitelists the back end servers so it talks with only authorized back end web servers. This can be the same key as the external key pair used on the front end, or an internal only key for enhanced security. Self signed certs are a quick option for a demo or test environment, for production you'd definitely want to use certs from a public certificate authority or from your internal certificate authority.

With these certificates in place traffic is encrypted to the Application Gateway, decrypted on the Application Gateway with the front end private key and scanned by the built-in WAF, then re-encrypted and sent to the web servers.

HTTP to HTTPS redirection

HTTP to HTTPS redirection is a feature that is not currently available on the Application Gateway. In order to perform this redirection, traffic is sent to the back end web servers over HTTP, the web servers redirect that traffic to HTTPS on the same URL, which then establishes an encrypted connection back through the Application Gateway. This redirection is accomplished with the URL Rewrite module for IIS and is set up on the VMs with the Azure PowerShell DSC extension during deployment. Similar mechanisms can be used for Linux based web servers as well.

Summary

Azure Application Gateway is a great layer 7 load balancing solution you can leverage in your Azure deployments and provides many features above the more basic Azure Load Balancer. Take a look through the documentation for detailed information on this service and for additional use cases.

Comments

  • Anonymous
    May 05, 2017
    Amazing information. Thanks for sharing.