05-03-2013 10:16 AM
I have read both the Sharepoint deployment guides for Stingray, and although very useful, they are mainly focused on setting up Stingray to load balance Sharepoint Web Front end servers, rather than going in to the details of how to handle SSL Decryption.
One guide briefly touches it, just saying that it should be enabled, but that's pretty much it.
The idea of Decrypting the SSL for Sharepoint is rather attractive, it lets you see what's going on in there, offload SSL Decrypt from the Front End server, virus check stuff before it hits the server even. But the problem I see with it, is that unless you re-encrypt, you end up having to send HTTP to the Sharepoint node, rather than HTTP and HTTPS. This is fine for anything HTTP, and will work HTTPS for other stuff like login pages using the the appropriate 'ChangeSite' rule, however, inside Sharepoint applications, where users have been uploading files, if you have not got HTTPS actually working on your Sharepoint deployment, Sharepoint will basically 404 any link to a file that is coming through the Stingray HTTPS decryption as Sharepoint itself thinks there is no HTTPS going on at all - it's only configured for HTTP.
So we found that the following situation arises for a file that has been uploaded in Sharepoint:
If we try to download (HTTPS)
We get a 404
However we can download (HTTP)
....but strangely if we try to download the file directly via HTTPS (not via link in Sharepoint)
That works as we have the global 'ChangeSite' rule in place (HTTP > HTTPS).
So it would be really good if someone could give us some pointers on how to figure out SSL Decryption with Sharepoint apps.
05-05-2013 03:13 PM
Firstly - I don't have recent experience with Sharepoint, so apologies if the following suggestions are useless or out of date, and if anyone can share better insight, please do!
A little research suggests that it's quite common to hit problems when you place a reverse proxy in front of Sharepoint, and the proxy changes the URL or protocol (HTTP/HTTPS) that clients use. Most articles point towards a Sharepoint configuration feature called 'Alternate Access Mappings'.
These two technet docs look like a good start:
Note that even though the documentation sometimes refers to a 'hardware load balancer', the principles are the same with Stingray (software load balancer) - both types of devices operate in the same fashion for this purpose.
It's possible that Sharepoint is not recognising the https URLs - in your example above, the only URL that failed was the one that referred to the resource via the https URL and was not rewritten or translated by Stingray so that it was presented to sharepoint as http.
Hope that this helps, best regards