Changing my Citrix NetScaler VPX based website from http to https and scoring an A+ in SSL labs test


Last update: July 12 2018

This blog is about NetScaler versions up to 12. Find later versions here

January 2020: It’s pretty outdated by now, as some of the proposed encryption methods are outdated and there are serious concerns about TLS1.0 and TLS 1.1. Read Thomas’s blog from here.
Citrix NetScaler load balancing and content switching servers will only score an C in quality labs SSL test, no matter if you use a VPX, MPX or SDX. There are several reasons for this. You could probably say, Citrix is to be blamed for this, but I don’t agree: It’s the end users to be blamed. They don’t upgrade their browsers, and can’t benefit of new encryption methods; because of this we can’t just go for security! We have to consider compatibility too.

This blog is based on an excellent blog by Steven Wright in Citrix Blogs. I have an other blog about scoring an A+ on NetScaler Gateway (Unified Gateway). The other one is a bit less informative …

This blog tries to tell you what to do and which compatibility issues you might face …

So, what does it take to score an A+ in a NetScaler?

there are several things to be done:

  1. Use an SHA2 certificate
  2. Disable SSL v2, v3 and probably also TLS v1 and v1.1 (this will score a B)
  3. Create a cypher set including just secure cyphers (this will score an A-)
  4. Enable Diffie-Hellman key exchange (this will score an A)
  5. Add a strict-transport-security header into the server response (this will score an A+)

Let’s give it a try!

I set up a new content switching server for I test it using Quality labs SSL test


To be honest: this is a disaster!

1 Use a SHA2 or better certificate

There is not much to say. SHA 1 certificates should not be available any more. Current standards are SHA 2 and SHA3. If you currently use a SHA1 certificate handle it back, your CA will usually update it for free as SHA1 certificates are no more supported by all browsers.

2. Disable SSL v2, v3 and probably also TLS v1 and v1.1 (score of B!)

This is an easy one. Open your virtual Server and locate SSL parameters. Deselect SSLv3 (and probably TLSv1 and TLSv1.1 as well, depending on clients you have to support)


commanl line:

set ssl vserver cs_ssl_webserver -ssl3 DISABLED

optional we could also append -tls1 DISABLED -tls11 DISABLED to disable TLSv1 and TLS v1.1

Following clients need to use SSL v.3:

  • Windows XP with Internetexplorer 6

Following clients will only support TLS 1.0:

  • Android up to Jelly Bean (4.3)
  • search engine Baidu (it’s important if you publish MP3 files!)
  • Windows up to Vista, Windows 7 with Internet Explorer 10 or before
  • Windows Phone 8 with internet explorer 10
  • Java up to 8u31
  • Open SSL 0.9.8 and before
  • Mac OS X 10.8

(source: SSLlabs)

2 a. An other requirement (just check)

Check advanced SSL settings (Traffic management -> SSP, its on the right side, down): Deny SSL Renegotiation should be set to non secure


not too bad. But not really good either. The most important sentence here is: This server accepts the RC4 cipher, which is weak. Grade capped to B. There is a big security issue about GCM based ciphers! See CTX220329 or here!

3. Create a cypher set including just secure cyphers (this will score a A-)

You could copy default cyphers and remove all these RC4 ones. This will be the most flexible solution. And you’d be able to connect from every country, no matter which one.

What about the last sentence? “From every country”? Umpf. There is an attack to SSL, it’s rather hard to do, but highly efficient: During session establishment a client will offer connection methods, and a server will select the best one this server supports. To do so you need to control a core router. Some governmental organizations exactly do this. I’m traveling a lot. I have seen weak encryption in some countries.

Which cyphers do we need as a minimum requirement? Just the best ones supported by clients, if we go for security. SSL Labs helps: These are the cyphers actually used:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256 Bt
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128 Bt
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 2048 bits   FS 256 Bt
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 2048 bits   FS 128 Bt
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 Bt
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 Bt

So we create a cypher suite containing just these cyphers! If we take a closer look we see which cyphers will get used by which browser; actually only some of these cyphers are used!

But stopp: there is something else to say:

  • These TLS_DHE_RSA_WITH_AES_*_CBC_SHA (0x33)   suites are never used. So we may skip these.
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA is a really weak one (112 Bit!!!), and it’s only used by Windows XP boxes. You should remove it, if you don’t need to support XP boxes
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is just used by Java and Apple’s iOS 9
  • TLS_RSA_WITH_AES_128_CBC_SHA  is used by Android up to 2.3.7 only. You may skip it if you don’t have to support Gingerbread.

If you only support TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, you will be able to connect using Android beginning with Ice Cream Sandwich (4.x), Widows beginning with Vista, Windows Phone, Open SSL from 0.9 and 1.0.1 but not 1.0.2, Mac OS X from 10.6.8, iOS from 6.0.1 (available for iPhone from 3GS)

So how to do it? in Traffic Management -> SSL -> Cipher group create a new cipher group and add the desired ciphers into it.

If you use the GUI be careful to add ciphers in the correct order as the GUI does not allow to change priorities: the first cipher you add will get a priority of 1, the second one of 2 …


command line:

add ssl cipher JustSecureCyphers

bind ssl cipher JustSecureCyphers -cipherName TLS1-ECDHE-RSA-AES256-SHA -cipherPriority 1
bind ssl cipher JustSecureCyphers -cipherName TLS1-ECDHE-RSA-AES128-SHA -cipherPriority 2
bind ssl cipher JustSecureCyphers -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA -cipherPriority 3
bind ssl cipher JustSecureCyphers -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA -cipherPriority 4
bind ssl cipher JustSecureCyphers -cipherName TLS1-AES-256-CBC-SHA -cipherPriority 5
bind ssl cipher JustSecureCyphers -cipherName TLS1-AES-128-CBC-SHA -cipherPriority 6
bind ssl cipher JustSecureCyphers -cipherName SSL3-DES-CBC3-SHA -cipherPriority 7

bind ssl vserver cs_ssl_webserver -cipherName JustSecureCyphers


In my opinion an A- is a good result for a NetScaler, but it’s easy to score better (and better things are always the main enemy of good ones). So let’s continue: The most important sentence here is: “The server does not support forward secrecy with the reference browsers. Grade reduced to A-”

So it’s about forward secrecy.

4. Enable Diffie-Hellman key exchange (this will score an A)

There is a blog about this. I have written it about NetScaler Gateway, but it’s also valide for a load balancing or a content switching server..

Why is it important? It’s all about forward secrecy. What’s forward secrecy about? The word itself sounds a bit funny but highly mysterious. Well, it’s all about the private key. If I record sessions (e.g. during network traces) I will be able to decrypt it using the server’s private key. This is not desired as we will never know if the server’s private key will get stolen in future (that’s why we call it forward secrecy).

Let’s have a look at SSL session establishment: During the second part (“Change Cipher Spec”) the client will create a secret for a symmetric encryption and send it to the server. To keep it a secret we can’t send it in an unencrypted way, so we encrypt it using the public key of the server (contained in server’s certificate). If you steal the private key of the server (in NetScaler stored in /flash/nsconfig/ssl) you’ll be able to decrypt it and therefore decrypt all the communication following.

We avoid this by using Diffie-Hellman key exchange. Cyphers supporting Diffie-Hellman will always contain a DH in their names. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA is one of them. That’s why Quality SSL labs marks this cypher with FS, meaning forward secrecy.


Oh, God, my score up to A! That nasty – vanished. But is an A good enough? Isn’t there an A+ also?

5. Add a strict-transport-security header into the server response (this will score an A+)

So, to be absolutely clear: B was fine, A- was great, an A is a top rating. But it’s more or less easy to score an A+, it’s just an additional header, strict-transport-security with a content of max-age= and a number (in seconds). this header can be inserted easily using a NetScaler rewriting policy. What is this good for? Simple like that: It’s a request to client’s browser to not use anything else but SSL in communication with this very server for a certain time, even if there are http- links in it. This would protect communication from down grade attacks. down grade to HTTP, and therefore to a non secure communication. This header follows RFC 6797 and was introduced in 2012.

The policy:

If you apply this policy to a content switching server make sure there is no policy bound to a load balancing server with a goto end!

the first thing to do is creating the action:


So you see, this is a NetScaler rewriting action (Appexpert -> rewrite -> actions) of type INSERT_HTTP_HEADER. The header name has to be Strict-Transport-Security, and the value max-age=

If you want to include sub domains you should also specify the includeSubDomains parameter


add rewrite action rw_act_insert_STS_header insert_http_header Strict-Transport-Security "\"max-age=157680000\""

Next the policy


hm. I just filtered using a true value. If you want to allow for non- SSL connection in addition you would rather filter on something like CLIENT.SSL.IS_SSL


add rewrite policy rw_pol_enforce_STS true rw_act_insert_STS_header

add rewrite policy rw_pol_enforce_STS CLIENT.SSL.IS_SSL rw_act_insert_STS_header

Bind this policy to your web server!

This looks really great!!! A score of more than 95% using a NetScaler VPX! What does A+ mean? Exceptional!

Credits: Thanks to Stephen wright (Citrix) for his great entry at Citrix blogs

I would be more than just glad to see some feedback if you like it, or get annotations if you see some mistakes. Security is always work in progress, so go ahead and tell me about your thoughts!

About the author

Johannes Norz

Johannes Norz is a Citrix Certified Citrix Technology Advocate (CTA), Citrix Certified Instructor (CCI) and Citrix Certified Expert on Application Delivery and Security (CCE-AppDS).

He frequently works for Citrix international Consulting Services and several education centres all around the globe.

Johannes lives in Austria. He had been borne in Innsbruck, a small city (150.000 inhabitants) in the middle of the most beautiful Austrian mountains (


By Johannes Norz

Recent Posts

Recent Comments