Although my 2016 update is still providing an A+ at SSL Labs, some NetScaler best practices have changed and now seems a good time to give you update.

Welcome to my fourth blog post on getting an “A+” score.

As always, I will detail how you can achieve an A+ quickly and easy, provide you with the copy and paste commands required, and give some notes about the firmware versions needed.

The cheat sheet for an “A”!

1. Make sure you are running a recent firmware release

• More detail is included lower in this article as to the differences in each version, but it was written using 12.0.57.24

2. Ensure TLSv1.2 is enabled on your vServer

• TLS1.2 is considered to be the only secure protocol version, and it has been enabled as a default on NetScaler since 10.5.57; however, if you recently upgraded, you may still need to enable it on your vServer. Without TLS1.2 your score will be capped at a “C”.

3. Disable SSLv3 on your vServer

• SSLv3 is vulnerable to the “POODLE” attack, considered insecure, and you will only score a “C” with it enabled. For continuity reasons, it is remains enabled by default and should be turned off.

4. Allow secure renegotiation

• The SSL renegotiation feature enables a client-server pair to perform a new SSL handshake sequence over an existing SSL connection and this has a variety of uses including for certificate authentication with NetScaler Gateway. To score higher an “A-” you need to enable secure renegotiation.

5. Ensure your certificate chain is complete.

• Certificates are not always signed by someone the endpoint inherently trusts; often they are signed by an intermediate.
• There are many possible intermediates, and if the browser does not have the one you require it will fail, or there will be a small delay while it is fetched from a third-party.
• To prevent failure or delay, you should install the intermediate certificate on NetScaler and link it to the server certificate; this will cause NetScaler to provide both when a client connects.
• Note that NetScaler need not provide the root certificate as the client should already know about this and trust it, for this reason, you don’t usually need to install the root and link it to the intermediate to provide a complete certificate chain.
• If you do not provide a complete certificate chain, then your grade will be capped at a “B”.

6. Create a custom cipher list that provides Forward Secrecy (FS) and preference secure AEAD cipher suites

• ECDHE (Elliptic Curve Diffie–Hellman Exchange) cipher suites provide Forward Secrecy (FS), which is a protocol feature that enables secure conversations that are not dependent on the server’s private key. Without this, your grade will be capped at a “B”.
• DHE suites (Diffie–Hellman Exchange) also offer FS; however, as DH requires considerably more computation on client and NetScaler, you may wish to keep it disabled (by not binding a DH key to your vServer) unless you have older clients that don’t support ECDHE.
• Enabling or disabling DHE won’t impact the SSLLabs score if ECDHE suites are available.
• AEAD (Authenticated encryption with associated data) cipher suites are the only approach without known deficiencies, and like ECDHE your grade will be capped at a “B” without these.
• Note that NetScaler will prefer ciphers in the order they are bound within your group; the binding order matters.

Turning your “A” into an “A+”

• Ensure your certificates do not have depreciated SHA1 signatures
• Implement Strict Transport Security by setting the “-HSTS ENABLED” flag that became available in 12.0.35.6

Copy and paste commands to reach the “A+”

A step-by-step guide

1. Ensure SSL3 is disabled and TLS1.2 is enabled

set ssl vserver Name_of_NetScaler_vServer -ssl3 DISABLED -tls1 ENABLED -tls11 ENABLED -tls12 ENABLED

2. Allow secure renegotiation initiated by the NetScaler or clients that support RFC5746

set ssl parameter -denySSLReneg NONSECURE

3. Create a new cipher group that preferences AEAD, ECDHE, and ECDSA cipher suites

add ssl cipher ssllabs-smw-q2-2018

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-ECDSA-AES128-SHA256

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-ECDHE-ECDSA-AES128-SHA

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-ECDHE-ECDSA-AES256-SHA

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher ssllabs-smw-q2-2018 -cipherName TLS1-AES-256-CBC-SHA

4. If you must support old legacy clients such as Internet Explorer 8 on Windows XP, you may need to add the following cipher suite to the end of your preference list.

bind ssl cipher ssllabs-smw-q2-2018 -cipherName SSL3-DES-CBC3-SHA

Despite the name (“SSL3”), it does contain a TLS1 cipher. However, it is a DES cipher that may be vulnerable to a SWEET32 attack, and I suggest you only enable it after balancing the increased risk against your need to support the legacy clients.

5. Unbind the DEFAULT cipher group from your vServer and bind the custom group.

unbind ssl vserver Name_of_NetScaler_vServer -cipherName DEFAULT

bind ssl vserver Name_of_NetScaler_vServer -cipherName ssllabs-smw-q2-2018

bind ssl vserver Name_of_NetScaler_vServer -eccCurveName ALL

6. Implement Strict Transport Security by setting the “-HSTS ENABLED” flag

set ssl vserver Name_of_NetScaler_vServer -HSTS ENABLED -maxage 157680000

7. Create and bind a DH key to the vServer if you need DHE suites

create ssl dhparam DH_Key_Name 2048 -gen 2

set ssl vserver Name_of_NetScaler_vServer -dh ENABLED -dhFile DH_Key_Name

You’re now protected!

That’s it! You will now score an “A+”.

Do remember however that ssllabs.com is just an opinion, and we’re not necessarily recommending this for your environment, as always testing is paramount.

How does my score compare to others?

SSL Labs have published this data here.

Reading the summary for April 03, 2018 we can see that ssllabs.com surveyed 137,971 sites and 42.9% were listed as having inadequate security and only 11.4% (15,673) managed an “A+”.

While this doesn’t sound great, it’s a significant improvement to the 6.5% achieving an “A+” when I wrote my last article in 2016.

Going above and beyond the “A+”

It’s human nature to try to be the best no matter the situation, and as many people have asked “is there more I can do?” it seems that securing vServers is no exception to this rule.

ECDSA and ECC certificates

ECDSA cipher suites allow you to use ECC certificates which, due to their smaller key size, are particularly helpful in environments where processing power, storage space, bandwidth, and power consumption are constrained. Hence, this feature might be particularly useful where you have smartphones and other handheld devices.

NetScaler VPX gained ECC certificate support in 12.0.57, and it is now possible to bind both an ECC and RSA certificate to the same vServers thus ensuring clients without ECC support continue to function.

When two certificates are bound NetScaler will hand out one or the other depending on the certificate suite negotiated at the start of the connection.

Although ECC certificates are not particularly new (support was added in OS X 10.6 and Windows Vista) they are not yet in mainstream use. When I attempted to buy one for my test site two of the certificate resellers I use couldn’t issue them at all, and the third had to process my request manually (thank you, Victoria!)

I’m sure someone will leave me a comment about a significant site that is using an ECC certificate but, I couldn’t immediately see one while writing this article and if you are one of the first it’s possible you’ll find browser issues that no one has seen yet.

If that hasn’t put you off, I’ve included technical details lower in this article.

OCSP stapling

OCSP (Online Certificate Status Protocol) is a way to discover if the CA has revoked a certificate. The concept is that the client will receive a certificate from the server and connect to the CA’s OCSP to check that it’s valid.

Unfortunately, this approach means that clients will reveal the site they are visiting (to the CA), as there will be a delay while the client connects to the CA’s OCSP service many browsers don’t perform this check.

With OCSP stapling the logic is reversed, and the NetScaler rather than client fetches the OCSP response. NetScaler then caches the response and provided the clients as they connect.

A potential flaw in this plan is that someone trying to use an invalidated certificate is unlikely to attach the response and it isn’t mandatory. Thankfully, this issue has been thought of and can be overcome by setting the “OCSP must-staple” flag when generating a CSR (certificate signing request).

There are some excellent articles on creating a CSR and my Comodo OCSP stapling configuration is lower in this article.

DNS CAA

Another item that is not yet widely used but that’s worth exploring is DNS CAA (Certification Authority Authorization).

DNS CAA is a mandatory method for CAs to validate they are authorised to issue certificates for a domain and to provide them with a contact if something goes wrong.

As you would configure DNS CAA on your DNS servers rather than NetScaler, I won’t go into the configuration here but, Scott Helme has an excellent blog on the topic.

Commands to go beyond the A+

How to create and install ECC certificates to use ECDSA ciphers

Firstly, good news, my custom cipher group includes ECDSA and you need only bind an ECC certificate.

The bad news is that you can’t create an ECC certificate request using the NetScaler GUI and must do so via the command line.

First, create a file called “req.conf” on your local computer with an edited version of the below. Note that “www.xn--80astk.com” is my test domain, the CN must be in the “alt_names” section, and O (organisation) / OU (organisational unit) will likely not be NA for you.

[req]

distinguished_name = req_distinguished_name

req_extensions = v3_req

prompt = no

[req_distinguished_name]

C = GB

ST = Nottinghamshire

L = Newark on Trent

O = NA

OU = NA

CN = www.xn--80astk.com

[v3_req]

keyUsage = keyEncipherment, dataEncipherment

extendedKeyUsage = serverAuth

subjectAltName = @alt_names

[alt_names]

DNS.1 = www.xn--80astk.com

DNS.2 = xn--80astk.com

Second, transfer the “req.conf” file into the “/nsconfig/ssl/” directory using SCP.

Third, login to NetScaler and switch to the shell, then enter the following commands.

cd /nsconfig/ssl/

Changes to the “/nsconfig/ssl” directory.

openssl ecparam -name prime256v1 -genkey -out newecc.key

Creates a new ECC key called “newecc.key”

openssl req -new -config req.conf -key newecc.key -out newecc.csr

Creates a new certificate signing request called “newecc.csr”

The “newecc.csr” file can now be downloaded from “/nsconfig/ssl/” using SCP, supplied to your CA of choice, and the resultant certificate copied back into the “/nsconfig/ssl/” directory.

Later, the certificate can be imported and attached to the vServer as usual via the GUI or with the commands

add ssl certKey "name of cert" -cert newecc.crt -key newecc.key
bind ssl vserver Name_of_NetScaler_vServer -certkeyName "name of cert"

Remember that both an RSA and ECC certificate can be bound to the vServer at the same time.

How to configure OCSP stapling

OCSP stapling is of real benefit if your certificates have the OCSP “must-staple” flag, which most don’t. An excellent guide to creating a certificate with the flag can be found on Scott Helme’s blog.

Please note that mandating the “must-staple” flag will cause issues if your CA’s OCSP servers stop working and you should consider this before implementation.

OCSP responders were added in 11.1.51.21 and are automatically created after a certificate is imported.

Unfortunately, it isn’t currently possible to modify the “INTERNAL_” responders that are automatically created and changes are required for certain providers such as Comodo, which needs the “Nonce” extension to be disabled.

To make modifications a new OCSP responder can be created with the same settings and the modifications applied.

After modification the new OCSP responder can be bound to an intermediate certificate.

bind ssl certKey COMODORSADomainValidation -ocspResponder modified_ocsp_comodoca_com -priority 1

All that remains is to activate OCSP stapling for the vServer and to ensure traffic from the NetScaler’s SNIP can reach the responder’s URL and port.

set ssl vserver <span lang="EN-GB">Name_of_NetScaler_vServer </span><span lang="EN">-ocspStapling ENABLED</span>

Firmware notes

Since I began to publish these articles, many customers have asked what is possible with their current firmware, so this time I thought it might be wise to include some notes.

• My 2016 blog article is still scoring an “A+” however, the 11.0.65.35 firmware it was written on was released before the “ROBOT” vulnerability.

• Servers affected by ROBOT vulnerability started to score an “F” from 1st March 2018.

• The ROBOT vulnerability was fixed in 12.0.53.22, 11.1.56.19, 11.0.71.22, and 10.5.67.13 — more details about this can be found here

• This article was written on 3rd May 2018 using 12.0.57.24

• ECC certificate support was added for VPXs in 12.0.57, however, it was available earlier for appliances with hardware SSL chips

• The HSTS (Strict Transport Security) flag became available in 12.0.35.6, before this a rewrite policy was required

• Please note that you should use either the flag or a rewrite policy, don’t use both or two HSTS headers will be inserted, which isn’t allowed.

• OCSP responders were added in 11.1.51.21

• Support for TLS1.2 was added (for VPX) in 10.5.57, it was available earlier for appliances with hardware SSL chips