SSL Termination with Web Application Proxy and AD FS 2012 R2


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

Comments (13)

  1. Hi Tristan,

    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.



  2. SSL Termination with Web Application Proxy and AD FS 2012 R2
    thank you

  3. Hi Tristan,

    What are you expecting to see and how are you determining if this is happening or not?

    There are 2 key timeouts involved here:-

    WAP token lifetime – when this expires the client will be redirected to adfs for a new token. If the adds sso cookie is still valid the new wasp token will be issued without any user intervention (unless the relevant rpt requires auth for each token request.

    Adfs sso cookie lifetime – this is an adfs property and determines how long the client can obtain tokens from the adfs server without reauthentication.

    If you’re expecting the client to reauth after 2 minutes then it’s not going to happen due to the adfs sso cookie still being valid.



  4. Tristan Watkins says:

    Hi Ian,

    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.



  5. Tristan Watkins says:

    Thanks Ian. That’s all very helpful. Yeah, I was meaning content notifications on Twitter, but also that it becomes a way to raise 140 character questions with the team, or even for you to solicit ideas about helpful content.

    I didn’t know anything about the WAP RPT property. Thanks for that. Very helpful. I will have a look at that now.

  6. Tristan Watkins says:

    Hi Ian. After updating the Token Lifetime to two minutes in Set-AdfsWebApplicationProxyRelyingPartyTrust, I don’t see any changes. Is there anything special I need to do. Do I need to re-publish the trusts or anything? I’ve tried restarting AD FS and WAP

  7. Tristan Watkins says:

    Thanks Ian. I just managed to bottom some of that out by disabling an account and refreshing access after three minutes. I noticed that the EdgeAccessCookie was not reissued, and that I re-gained access after enabling the account. It’s great to learn that
    this control exists, and that it works in line with the WebSSO lifetime. Thanks a lot for your help with this. I’ll look forward to your post on auth flow.

  8. Anonymous says:

    Hi everyone, this blog took a bit longer to get out than we’d planned but we hope it’s worth

  9. Jag Nagra says:


    We are replacing our existing reverse proxy solution with WAP and its working well. The existing implementation of the reverse proxy used user certificates on devices (customers who are not joined to our domain) which would form the 1st part of the challenge
    / response followed by forms authentication. Is there a method in which we can continue to use the existing certs on client devices with WAP?


  10. Anonymous says:

    Ci sono casi dove è necessario installare un WAP/ADFS Proxy ma non si ha a disposizione un server

  11. anonymous says:

    + 1 for this auth flow blog discussion. Its very confusing what to expect. This page seems to be the best source of info at the moment, and its not official microsoft documentation

  12. Tom says:

    Great article, which has solved one of my issues (where we had SSL-offloading between our WAP and ADFS servers).
    Something else I’m tackling, (which may or may not be suitable for this forum) is a slow connection to my WAP servers, after a period of inactivity. To expand, I mean this; If I am constantly accessing the two proxy’s, lets say using the ‘adfs/ls/IdpInitiatedSignon.aspx’ URL, then there are no problems. However, if I don’t access the URL for several hours (I haven’t been able to work out exactly how long just yet, but it’s at least 3), there is a period (for that initial connection) of 20+ seconds, where the page is just waiting to load. I’ve searched the web, and can’t find anything similar. Do you have any idea’s what may be causing this? My next obvious steps are to get Wireshark on the servers, and see if I can spot anything unusual.

  13. JohnnyM2000 says:

    And how do I configure the ADFS WAP not to terminate the SSL certificate? I have no Load Balancer, only the ADFS WAP is in use.
    I rely on a client certificate which is causing me some problems.

Skip to main content