Azure Application Gateway Client-Server Concepts
Azure Application Gateway
This post explains how I think about Azure Application Gateway and how I try to explain it to others.
If you understand the fundamentals, feel free to jump to the Client-Server Perspectives below.
How you request a website
When you open up your browser and type in a web address and hit enter your browser sends a HTTP GET request to the address that you typed in. It sends this with some information like your current IP address and other information that is stored in request headers.
The server should then reply with the content of the site and response headers (probably).
The browser then renders the content of the site applying any CSS styles and running any javascript. Simple!
But what is the server from the perspective of the the user?
The Server
The server from the users perspective is the name of the website that they typed in. Lets say contoso.com. contoso.com has an IP address that is associated with it linked by DNS.
That IP address could point to different types of server or services:
- Directly to the web server
- A load balancer
- Layer 7 (Application) like a reverse proxy (what Azure Application Gateway effectively is)
- Layer 4 (Transport) like an Azure Load Balancer
Load Balancing
I’ll whiz through an explanation of an Azure load balancer first for completeness. An Azure load balancer only understands the IP addresses and ports. It does not have a concept of domain names or HTTP headers. This means that one IP address can be used for a single service unless you move away from standard ports (like a load balancer listening on port 81 or 444 for web traffic).
A layer 7 aware load balancer, like Azure Application Gateway, can listen for multiple services on the same IP address and port because it also understands the hostname the client has requested (in this case contoso.com). That detail is passed to the the Application Gateway so when a request hits a single IP address and port the gateway understands what backend pool to route the traffic to.
The DNS names contoso.com, news.contoso.com and blog.contoso.com can all resolve to a single IP on the Application Gateway.
Client Server Perspectives
With the fundamentals out of the way lets have a think about the client and server. This is how I think about the Application Gateway and how I think how it clicks for others who are less familiar with how a reverse proxy works.
So the Application Gateway is both the client and the server depending on the perspective you’re viewing it from.
Why? The Application Gateway terminates the request from the client and then makes a new request to the backend pool. In between the terminated request from the client and the connection to the backend the Application Gateway can do additional processing such as adding or removing headers or TLS offloading if the backend is using HTTP.
Certificates
So now we understand that the Application Gateway is the client and the server lets start to break down how certificates works on the Application Gateway. Lets consider the below:
An important note I’ll point out is that the listener on the Application Gateway is listening for https://contoso.com and the backend pool is listening for https://contoso.
An assumption I’ll make here is that the listener on the Application Gateway is listening on a public IP address. The concepts are identical for internal networks too but I want a clear delineation between external and internal traffic.
Client –> Application Gateway
The public HTTPS listener on the Application Gateway should have a certificate that is signed by a public certificate authority. External users connecting to the public endpoint will need to trust the certificate presented by the Application Gateway or they will see a certificate warning before they reach your site.
If you apply a certificate signed by an enterprise certificate authority (such as Active Directory Certificate Services) to the public listener then external users are highly likely to see a certificate warning. Enterprise users from enterprise devices may trust the certificate depending on the setup of the devices.
In the example described in the diagram above the certificate signs contoso.com only. The listener must be configured for this domain only; any child domains (such as news.contoso.com) can’t be signed by this certificate. In this case, child domains should be added as a new listener with an additional certificate that can sign the child domain.
Application Gateway –> Backend Pool
Assuming the client successfully connects to the Application Gateway the gateway will then attempt a new connection to the backend pool. The backend pool should have a certificate that is trusted by the Application Gateway. This means that the certificate can be publicly signed or signed by an enterprise certificate authority. This is still the case if the listener on the Application Gateway is public and the connecting client doesn’t trust your enterprise certificates. The Application Gateway is the client in this connection, not the user.
Looking at the name the web server is bound to in our example we can see that a public certificate is not possible because the name the server is listening on is https://contoso. There’s no top-level domain (.com, .net, etc). We could change the binding to include the top-level domain and the public certificate would be valid. If we assume we can’t do that then a certificate that signs contoso is required on the backend pool which will likely need to come from an enterprise certificate authority.
As the Application Gateway is the client in this connection it must trust the certificate that the backend pool presents. The Application Gateway will need the public keys of the enterprise PKI that signed (or could sign in future) the certificate associated with the backend pool. The Connection Health blade in Application Gateway is quite descriptive when there is an issue with the certificate trust to the backend pool.
Thanks for reading, I hope you’ve learnt something new or failing that at least enjoyed the read. Until next time!