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.
And this one shows the 443 listener connecting to the HTTP service
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
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:
And the following shows the rule settings:
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.
Leave a Reply