SSL off-loading in Application Request Routing

One of the features that has not been called out explicitly in Application Request Routing (ARR) documentations is SSL off-loading.  This is a feature in which the communications between the clients and the ARR server are done via SSL while the communications between the ARR server and the content servers are done via clear text.  In this scenario, SSL is terminated at the ARR server.

This feature is designed to better utilize the resources on the content servers.  The task of decrypting and encrypting SSL requests and responses is "off-loaded" to the ARR server and the cycles saved by not performing such task can be spent on process additional user requests.

So, how do you configure SSL off-loading in ARR?  We will work on enhancing the user experience in later releases, but in CTP1, here is how you can do it.  As you may know, ARR relies on URL Rewrite module to inspect the incoming requests and determine which server group to route the requests based on the rewrite rules.  Given this, in order to route all traffic to the server group via HTTP, you can simply state this in the URL Rewrite module UI as shown below:

In some cases, though, you may not want to use SSL off-loading.  One such example would be if the applications on the content servers expect certain communications to be requested via SSL.  (If this is true, in most cases, appropriate changes are made to the applications so that SSL off-loading can be used.  For example, Windows Live ID - formally Passport ID - has specific APIs for enabling SSL off-loading.  However, this may not be possible in all situations.  For instance, it is possible that the deployment schedule of ARR is not aligned with the deployment schedule of the updated applications.)

In such situations, ARR can be configured so that SSL off-loading is not used.  Note, though, that ARR does not support CONNECT tunneling.  The SSL is still terminated at the ARR server, but the ARR server can be configured so that it will make SSL connections with the content servers.  To do this, you will need to write two rules in the URL Rewrite module.

First, we are going to determine if the request is made via SSL.  If so, it will forward the request to the content server via SSL:

Note that the Stop processing of subsequent rules check box is selected. 

Secondly, we are going to route the remaining requests via HTTP:

In either of the two cases above, appropriate server certificate must be imported on the ARR server.  In the SSL off-loading case, however, the server cerficiate does not need to be imported on the content servers.  In the second case where the SSL off-loading is not used, the server certificate must be imported on all of the content servers.

2 Comments

  • "In either of the two cases above, appropriate server certificate must be imported on the ARR server. In the SSL off-loading case, however, the server cerficiate does not need to be imported on the content servers. In the second case where the SSL off-loading is not used, the server certificate must be imported on all of the content servers."

    This last sentence is confusing to me. On the non SSL offload scenario the server certificate (which server, the ARR front-end or that particular server's certificate). Need to be imported? how come? imported how? The back-end server's certificate resides on the content server.

    I wish this SSL offload could be better documented, because I actually need to use it on a non SSL offload scenario.

    After reading much about this, my understanding is that ARR decrypts the "message" to be able to check the relevant HTTP headers, etc... and then encrypts the message again against the content server where the ARR forwards the requests to. The re-encryption of the message is done under the context of the content server certificate.

  • My interest in this article is that I have a back-end http server, which is a custom (not IIS) standalone exe, and I want to use IIS7 to do SSL offloading because the back-end app does not do SSL. That's what this article started out by saying it was all about, and it's what it said that ARR is all about.

    However, all we get in the end is a simple URL Rewrite rule, that uses "Rewrite" as the Action.
    - no mention of server farms
    - no mention of the "Route to Server Farm" routing option that installing ARR specifically provides within URL Rewrite.

    The solution provided (ie. first image, before the article digresses into how to avoid SSL offloading) seems to indicate that ARR does not need to be installed at all !
    Instead it seems to say: "Just capture everything that's bound, reroute it to a http address, and IIS will do the decryption & encryption for you." What does that have to do with ARR?

    If I don't need ARR to do what I want, then that's fine.
    But the role or necessity to install ARR is not made clear to me by this article.

Comments have been disabled for this content.