This post has already been read 7292 times!
We can now move onto Part 7 and the final part of this series, The Nice Bits
The previous parts in this series can be found by using the below links.
The purpose of this last post if to streamline the user experience and make sure that everything works exactly as you want it to. I will cover 2 additional NetScaler Configurations that I think are essential when deploying any publicly facing web service.
- HTTP to HTTPS redirection
Harden Your NetScaler Unified Gateway and Content Switch
The following steps will need to be taken on BOTH your non-addressable NetScaler Gateway vServer AND your SSL Content Switch
Disable SSL 3 and Create Diffie-Hellman Key
First create a Diffie-Hellman key by going to Traffic Management and SSL. On the right you will see the option to create a Diffie-Hellman Key. Click that and give the key a new file name on the NetScaler and set the DH Parameter Size to 2048
Next open up your new NetScaler Gateway and edit the SSL Parameters for the gateway
Check to enable the DH Param, select your new key, set the refresh to 1000 and disable SSLv3
Another thing is to ensure that your public certificate assigned to the gateway has the full chain presented on the NetScaler WITHOUT the Root CA. Head over to Traffic Management – SSL – Certificates – Server Certificates
Right click on your public certificate and click on link
If you have uploaded your intermediary certificates to the NetScaler you can link them here. Do this for all intermediate certificates but don’t link right back to the root
Open the Advanced SSL Settings from Traffic Management – SSL
Change the Deny SSL Renegotiation to NONSECURE
Assign the following Ciphers to the NetScaler Gateway and remove the Default Group
Secure Transport Session Header
You will now create the Secure Transport Session header to be put into your NetScaler Gateway sessions to abide by SSL Labs best practice
Navigate to Rewrite Actions and create a new action
Fill out the details as shown below
Then create a Rewrite Policy
and fill out as shown below binding it to your new Rewrite Action
Once you have created this bind it to your NetScaler Gateway
Thats it – test your Gateway from SSL Labs and you should not receive a pretty decent rating.
NOTE: This procedure can and should where applicable be followed on all SSL vServers that you create on the NetScaler even if it is for brokering XenDesktop, StoreFront or Ticketing.
HTTP to HTTPS Redirection
One of the most annoying things I come across is when people don’t redirect HTTP to HTTPS on any secure web platform. Its such a basic thing that makes all the difference to the end user. I want to be able to type in citrix.chromesummit.com instead of https://citrix.chromesummit.com!
There are LOADS of different ways to do this using a NetScaler but in this article I am going to use a Content Switch running on the SAME IP address as my SSL Content Switch and a Responder Policy to redirect ALL inbound port 80 traffic to the port 443 Content Switch that is configured to handle my entry point. This is NOT always the best way to do this as sometimes you may want to allow port 80 inbound for some reason, in this case you would need to use Content Switching Policies and vServers to do the job.
Head over to App Expert – Responder – Actions and click to create a new action
Create an action with the following expression
"https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE
Make sure the response code is 302
Next head over to App Expert – Responder – Policies and click to create a new policy
Create a new Policy with the following
and bind it to the action you have just created
Next head over to Traffic Management – Content Switching – Virtual Servers and create a new Server. Give it a name, THE SAME IP ADDRESS as your existing Content Switch for login.chromesummit.com and citrix.chromesummit.com and select the protocol HTTP and port 80
Open up the Virtual Server and bind your Responder Policy to it.
Thats it. Your new Content Switch is now listening on port 80 and will throw everything that hits it to the SSL Content Switch on the same IP address.
The great thing about this is that you can re-use the Responder policy for any other vServers that you have created for example StoreFront. Create a new vServer on port 80 – bind it to an always up service and attach the same responder policy. Boom, all port 80 traffic for storefront will now hit port 443 automatically.
And that is a wrap. I hope you enjoyed the blog series and it has provided a good step by step guide in configuring Citrix XenDesktop, NetScaler, Federated Authentication and Google Accounts.
On a side note – if you google oAuth providers and just look at the list that is available – just imagine what NetScaler, FAS and oAuth could do for you next.
Once again I want to that Rick Dehlinger for giving me the chance to help out with Project Silverton and I am sure that there will be loads of great community content coming soon from it.
Dave Brett (@dbretty)