Forward to server farm SSLRSS

7 replies

Last post Jul 25, 2011 09:32 AM by cordeirol

  • Forward to server farm SSL

    Dec 31, 2008 06:37 AM|ophth1|LINK

    hi! we are trying to setup the AAR on our server 2008 IIS7 as described in the MS documents.

    HTTP traffic is properly forwarded to the server farm. Furthermore, we need SSL traffic to be forwarded. We created the SSL rules as described in the blogs (* wildcard for all traffic for testing purposes, HTTPS on, forward to server farm, NO SSL offloading, because we need SSL connections between the internal servers, too).

    Doing this, https traffic results in an HTTP error 502.3 bad gateway. no further entries in the error logs of server2008.

    Any idea how to resolve this problem? Does all internal and external servers have to use the same SSL certificate or can they be different?


  • Re: Forward to server farm SSL

    Dec 31, 2008 12:20 PM|thomad|LINK

    I don't think this is supported by ARR due to architectural reasons.

    ARR is a module in the IIS pipeline. When the ARR module sees the request SSL encrypted data is already decrypted by HTTP.SYS.  And I think we currently have no way to forward SSL traffic.



    Thomas Deml
    Group Program Manager
    Internet Information Services
    Microsoft Corp.
  • Re: Forward to server farm SSL

    Dec 31, 2008 04:34 PM|anilr|LINK

    While Thomas is correct that you cannot do SSL tunneling using ARR - you can do SSL from ARR to the content-server - all request/responses would be decrypted and then re-encrypted - and you would have to pay the performance penalty for that.  The certificates would need to be deployed to both the ARR machine as well as the content server.  What is the win32 error code?  You can use winhttp tracing to get more details about SSL related errors.

    Also, why do you need SSL connection between ARR and the content server?  If it is just because of application code on the content server that checks for SSL, we have a helper module in the works that you will be able to install on the content server to "fake" SSL based on whether the original request to ARR was over SSL or not.

    Anil Ruia
    Software Design Engineer
    IIS Core Server
  • Re: Forward to server farm SSL

    Jan 01, 2009 05:43 AM|ophth1|LINK

    Hi! thanks for your reply!

    I assumed from the tutorials that ARR would need to decrypt and encrypt again the SSL traffic and hoped that the performance loss will be acceptable. There are no errors in the system log, but i'll try to catch some more SSL related errors with winhttp as you proposed.

    We need SSL connection between ARR and content server, because the content server unfortunately accepts SSL connections only. I know that we would not need SSL for internal connections, but I can't change this behaviour of the webapplication on the content server. Nevertheless, if there is a kind of helper module for IIS7 to "fake" the sSL connection, this could be of great help and would ease operation!! Is this available for download already?

    Furthermore, we are considering to use a real HTTP or HTTPS tunneling for another web application. Can you recomment any HTTP(s) tunnel product which work fine with IIS(7)?



  • Re: Forward to server farm SSL

    Jan 02, 2009 01:46 AM|anilr|LINK

    I don't know how much the overhead of double encryption would be - I was asking for win32 error code from IIS log. 

    So, you do not have the ability to have the content server also listen over http?  In that case, the helper module will not help you - the case where the helper module would be useful is when SSL is terminated at ARR, and while the connection to the content server is over http, you want application code on the content server to know that the real the client has connected over SSL (and also to get real client IP etc).

    The helper module is not yet released, will be released before ARR RTW.

    Anil Ruia
    Software Design Engineer
    IIS Core Server
  • Re: Forward to server farm SSL

    Mar 03, 2009 08:29 PM|anilr|LINK

    The helper module is now released here.

    Anil Ruia
    Software Design Engineer
    IIS Core Server
  • Re: Forward to server farm SSL

    Jul 22, 2011 01:13 PM|cordeirol|LINK

    I too have a similar scenario.

     my client -----> (ssl) -----> firewall (NAT port redirection) -----> (ssl) -----> ARR -----> (ssl) -----> application server

    Everything seems to work fine until ARR.

    This ARR is also serving other, non SSL content servers on my internal network, accepting HTTPS from external clients, but with the SSL offload enabled this is not problem and works fine; all my content servers accept plain HTTP anyway.

    The issue is with this new server that only accepts SSL. Reading the details of the HTTP over SSL protocol, I understand that ARR needs to read the encrypted payload, thus decrypt the message to be able to apply the rules, and then, forward the request to the final destination.

    When I disable the SSL offload I would think the ARR (as a client to the content server) is just probably injecting the received SSL message into the final server, thus saving the trouble to re-encrypt again (?!).

    Is this true?

    To resolve my issue, although I cannot change the final server SSL requirement, I can change it's certificates. Will this setting work if the exact same certificate used by ARR is used on the final server? (considering that the "injection" above is true).

    Is ARR clever enough to just decrypt the necessary bytes to extract the HTTP header HOST and to it's redirection magic, without loosing CPU time?

    I have tried to find this detailed information but it is not clear to me the exact meaning of the SSL offload setting, and the practical scenarios where it fits. 


    ARR SSL SSL offload certificates ARR

  • Re: Forward to server farm SSL

    Jul 25, 2011 09:32 AM|cordeirol|LINK

    Podering better on my own question above, and according to SSL protocol inner works, my sugestion could never work.

    My conclusion is, if the SSL offload is off, then the http paylod needs to be always reencripted again againts the content server.

    There is no other way around.

    Luis Cordeiro