We’ve had a number of questions around using SSL Termination with Web Application Proxy and AD FS 2012 R2. In this blog we’ll look at when you can and can’t use SSL Termination and some of the considerations around this.
What do we mean by SSL Termination?
SSL Termination (or SSL Bridging depending on your preference) is where a device between a client and a target server terminates the SSL connection in front of the target server and then sets-up a new connection to the target server. This behavior is commonly seen with Network Load Balancers, Reverse Proxy servers and other devices with an interest in inspecting and accessing the application data being sent over the SSL connection.
This might be done to make traffic routing decisions, add HTTP headers with additional information to the request, carry out content inspection etc.
Note - we are specially talking about termination of the SSL traffic not the underlying TCP/IP connection.
So, can I use SSL Termination with Web Application Proxy and AD FS 2012 R2?
To bridge or not to bridge, that is the question, and there are 3 answers to this – Yes, No and Maybe :-)
As with all these things the answer is really “It Depends” and we have 3 main areas of consideration here:-
SSL Termination between
Can you use SSL Termination
Web Application Proxy and ADFS 2012 R2
Client and Web Application Proxy / AD FS Proxy*
Web Application Proxy and Published Web Server
* a Web Application Proxy server also performs the AD FS Proxy role
Let’s look at each of these in turn to understand why we can/can’t use SSL Termination and the reasons behind this.
1) SSL Termination between Web Application Proxy and AD FS 2012 R2
There is no discussion or debate on this one – it’s a definite No.
The reason for this is because the Proxy Trust relationship between Web Application Proxy and AD FS 2012 R2 is based on Client SSL Certificates.
A Client SSL Certificate is only available to the endpoint where the SSL Connection is established. When you terminate SSL in front of the AD FS 2012 R2 server, the AD FS server no longer sees the Web Application Proxy server Proxy Trust certificate breaking the authorization channel between the two. This will lead to Event ID 442’s and issues similar to those discussed in the following blog:-
2) SSL Termination between Client and Web Application Proxy / AD FS Proxy
This scenario is a little less clear although strictly speaking from a product perspective the answer is No. The reason for this is that some product features will break if you terminate SSL in front of Web Application Proxy server. Specifically the following features will not work:-
- Workplace Join / Device Registration- Client SSL Certificate authentication
As you may have guessed, these features rely on Client SSL Certificate negotiation which, as we already discussed, will break if the SSL Connection is terminated in front of the Web Application Proxy server.
If you do not plan to use the above features, then terminating SSL in-front of Web Application Proxy should be fine, although we’d caveat that with the fact that this is not a scenario that we have tested to any degree of depth.
If you do terminate SSL in-front of the Web Application Proxy server then you have some added complexity in whether your terminating device (Hardware Load Balancer, Reverse Proxy etc) sends an SNI header when it makes the SSL Connection to the Web Application Proxy server.
An SNI header should be sent in the SSL Server Hello and this should match the external FQDN of the published application. The following blog talks in a lot more detail about what SNI is, why it’s important and workarounds to support non-SNI clients:-
The following F5 article is also a good reference in terms of how to configure an F5 hardware Load Balancer to send an SNI header when SSL Termination is in use:-
As you can see, using SSL Termination in-front of Web Application Proxy reduces functionality and introduces complexity but, if you are aware of the issues it can work and can bring some benefits e.g. a Hardware Load Balancer can add x-forwarded-for header to inbound client HTTP request.
3) SSL Termination between Web Application Proxy and Published Web Servers
There are currently no issues we are aware of with using SSL Termination between Web Application Proxy and published Web Servers so at this point in time it’s a Yes :-).
As mentioned above the main issues with SSL Termination is the impact it has on Client SSL Certificate usage. As Web Application Proxy is acting as a Reverse Proxy for the published server any Client SSL Certificate will be not seen by the published Web Server so, as long as the device carrying out the termination, does not adversely interfere with the HTTP traffic things should work fine.
If the Web Server is using SNI based certificate bindings then you would also need to be aware of the SNI considerations discussed above when the device makes the onward SSL connection to the target web server.
SSL Termination / SSL Bridging is a commonly used configuration especially with Hardware Load Balancers.
There are some scenarios where using SSL Termination will definitely break Web Application Proxy / AD FS 2012 R2 functionality. Specifically, when SSL Termination is used between the Web Application Proxy and AD FS 2012 R2 servers it will break the Proxy Trust relationship.
It can also leads to a reduced level of functionality when used between the clients and Web Application Proxy server although, if you do not need features that are Client SSL Certificate based such as Workplace Join or Client SSL Certificate authentication, then SSL Termination in front of Web Application Proxy can work OK.
If you do carry out SSL Termination in-front of the Web Application Proxy server then you need to understand your devices SNI capabilities when it establishes the new SSL Connection to the Web Application Proxy server.SSL termination between the Web Application Proxy server and the published web servers should be fine and not cause any issues assuming that the terminating device does not adversely interfere with the HTTP traffic and any SNI requirements are met.
As always, let us know if you have any comments or questions. We’re currently working on a Hardware Load Balancer health check blog at the moment to follow up on this one.
Ian Parramore, Senior Escalation Engineer, Web Application Proxy support team
SSL Termination with Web Application Proxy and AD FS 2012 R2
It would be really good if you guys established a presence on Twitter, if you don't already have one? I'm not sure this information is getting out there as quickly as it might be, and it's incredibly useful.
Anyway... I wondered if you would be able to devote one of these posts to the EdgeAccessCookie and whether there are any controls available to adjust timeouts to different values for extranet users (globally or per-relying Party)? We'd normally expect these
controls in a reverse proxy, and they appear to be missing in the WAP. I jotted down some of these thoughts on the Geneva forum before this blog existed but there hasn't been much response.
Thanks for the feedback, it's great to hear input on what you guys would like to see.
I'm just about to head out of the office for a couple of weeks but I'll have a chat with the rest of Blog team when I get back about Twitter. I'm guessing you were thinking about us using this for content notifications?
In terms of the EdgeAccessCookie and overall auth flow and architecture I agree we should definitely do something on this. It's something we have talked about here but we've been trying to prioritise our content based on where we've see an immediate need. I'll
probably start to draft something in the next few weeks.
From a timeout perspective this is a topic we've been having some internal discussions about so it's definitely an area we're looking at. There are already timeouts you can control as the WAP token has it's own defined lifetime in ADFS - you can access the
WAP RPT properties using the Get-AdfsWebApplicationProxyRelyingPartyTrust PowerShell cmdlet. I'll make sure I include some details on this and other relevent token lifetimes in the auth flow blog.