Configuring Citrix Netscaler for SharePoint SSL Offloading

Posted on Posted in citrix, load balancer, loadbalancer, Netscaler, sharepoint

I came across an interesting issue today and found that there was not a lot of info on the web about it, so as with lots of things on this blog I thought as it was not really noted about before I would document it here.

The scenario was SSL (HTTPS) connections from the outside of a company to their SharePoint site are required – so no HTTP connections. But inside the company it is all HTTP connections to different SharePoint sites! Therefore SharePoint has been set up such that the Citrix Netscaler is doing SSL Offloading and presenting a HTTP connection to SharePoint, but that SharePoint knows to return HTTPS in all the URL’s so that connections from outside remain working.

The problem here is that users on the outside had been typing in the host name for the site without HTTP and as the Netscaler was not listening on port 80 the connection was timing out. The client wanted the HTTP connection to redirect to the HTTPS version of the site.

So first the redirection. This is quite easy – you create a new virtual server for HTTP (TCP port 80) that is not bound to any service but is listening on the same IP address that the HTTPS virtual server is bound to. In the advanced tab of the HTTP virtual server you enter the value to redirect to if the service is unavailable. This URL should be the https:// url for the site.

Once the HTTP virtual server is configured it will appear as down as there are no services bound to it – this is fine. As the virtual server is down it will redirect to the specified URL. Note that rewriting rules can also be used to achieve the same end.

The following picture shows the HTTP and HTTPS service. The HTTPS service is listening on 443 but going to a service on port 80 – in other words SSL offloading.

Virtual Servers

And this one shows the 443 listener connecting to the HTTP service

VS-HTTPS

The problem with this is that the user connects to port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and is redirected to port 443, which redirects to port 80 on SharePoint and as SharePoint does not know about the SSL offload in place returns a HTTP link to the home page. The user is redirected to the home page on port 80 and… …etc. etc. Internet Explorer and Chrome just keep going around and around and never get anywhere. If you turn on the developer tools in both browsers IE will show you each redirect on the network tab. Chrome will just show it failing to connect. It was from IE that we saw the issue.

We need to tell the HTTPS virtual server that it is to add a header to the session telling SharePoint that SSL offloading is in place. This header is “front-end-https” and the value is “on”. Neither the header or value are case sensitive.

To turn on this header on the HTTP request (that is, the connection from the user to SharePoint) then you need to go to the Policies tab of the HTTPS virtual server and add a new Rewrite Request.

The following picture shows this in place, but what you need to do is add to this rewrite policy a rewrite action check that this action is working

VS-HTTPS-Rewrite-Policy

The rewrite policy needs to have a name and a new action. The action needs a name and a type. The type is INSERT_HTTP_HEADER and the header name is”front-end-https”. Note this is not case sensitive, but also is not Front_End_Https which has been used with Exchange Server in the past. The value for the header is needed in quotes and is “on”.

If you click Evaluate to check the action you will need to enter a test expression and a HTTP sequence of data. For testing purposes I use !HTTP.REQ.HEADER(“front-end-https”).EXISTS which reads to evaluate to true if the header does not exist. To test the rule enter HEAD fqdn and a line feed. The blank line is important or you get protocol errors. If the HTTP protocol text does not contain front-end-https: on then the rule will evaluate to true and add the header.

The following picture shows the action settings:

VS-HTTPS-Rewrite-Policy-Action

And the following shows the rule settings:

VS-HTTPS-Rewrite-Policy-Rule

Once your policy has been created you should be able to browse to HTTP for SharePoint, be redirected to HTTPS/SSL and have SharePoint know to offload the SSL to the load balancer, and so respond with a HTTPS link even though the connection was over port 80.

5 thoughts on “Configuring Citrix Netscaler for SharePoint SSL Offloading

  1. Hi Brian.. nice article. I could configure remote access to our sharepoint webserver over Netscaler with https and it works fine 🙂

    But now I have another problem and I hope you can help me. Internaly we have a Sharepoint server and it is possible to use it with Microsoft OneDrive for Business. When a client is in the internal network, the connection with the local application OneDrive for Business to the Sharepoint Server works fine and I have a new drive in Windows Explorer. We use http.

    When I try to connect with the app Microsoft OneDrive for Business from home (external network through Netscaler https), the app ask for username and password and after clicking “Synchronize” I receive the following error message:

    (traduction from german): The storage location of the Sharepoint-Website was not found. Please check the storage location address.

    Internaly I use the same address only with http instead of https and it works fine.

    Have you got an idea why?

    Thank you and Regards,
    Roberto

    1. No I’m not an expert in SharePoint, but on the load-balancer do you pass through HTTPS to SharePoint or do you terminate the HTTPS session and then pass HTTP through? If the first, do you have a certificate on the SharePoint server – as you say you use HTTP internally. On the second, if SharePoint sees a HTTP connection it might respond with a HTTP connection, but the client made a HTTPS connection and so is expecting a response on that protocol and the response never comes back. In the second option, you need to tell SharePoint that SSL is being offloaded and then it will return an HTTPS header for a HTTP connection. I’ve no idea if SharePoint supports SSL offload though – but this is where I would start to look!

  2. Hi Brian,
    thanks a lot for this very helpful article. We implemented this policy (SSL offload) on our Netscaler (balancing our SharePoint farm) and it always worked well. Since we upgraded our SharePoint 2013 to the latest patch (The SP2013 farms are now patched to 15.0.4893.1000 (Jan 2017 CU)) we have several issue related to the search/crawl function and to the download of the document: the front end server seems that try to search the object using https protocol instead of http and it finds no results.
    As far as you know do we have to change this SSL offload policy in some manner in order to fix this issue?
    Thanks a lot
    Best Regards

Leave a Reply

Your email address will not be published. Required fields are marked *