Scoring at least an A on SSL Labs has become one of most visible checks in terms of security. Although it doesn’t help you securing your application code, at least it “proves” that you are trying to keep communication as secure as possible. Now, all of you who have been in the NetScaler business for some time, know that security concerns are often perpendicular to business concerns. And if it doesn’t create some conflict at that level, there is always that one endpoint who isn’t able to communicate using the most recent features.

Fortunately, we’ve come a long way, and things are currently in a way better shape than about 5 years ago!

In order to configure SSL using the best practices, it is really worth reading up on what it all entails. There are many excellent resources out there, but some of the best come from the creators of SSL Labs:

Citrix ADC / NetScaler

Configuring an SSL-based virtual server on Citrix ADC/NetScaler can sometimes be a tedious task. It doesn’t need be, as long as you follow some of the guidelines below.

  • Avoid configuring SSL settings directly on the virtual server, as it allows you to version the settings through the ssl profile.
    It also gives you instant rollback should you break something in the process.
  • Create a SSL profile for each and every SSL-terminating virtual server individually, or at least for a select group of virtual servers.
    • Limiting the scope of virtual servers to which the SSL profile is bound, avoids unpleasant surprises when changing some settings over time. You don’t want to impact the business, right? wink



Let’s configure SSL in a few steps through the GUI, and we will check the intermediate results after each step.
Afterwards, a full command-line snippet will be provided, so you can get started right away.

Code for this article can also be found on GitHub:

IMPORTANT: As you will see in the end-result screenshot from SSL Labs, this will break compatibility with older clients. Make sure your clients can handle the new settings.

SSL Profile

Basic Settings

  1. Logon to your favorite network appliance and drill down the menu on the left-hand side:
    System –> Profiles –> SSL Profile
    SSL Profiles
  2. Select the default frontend profile “ns_default_ssl_profile_frontend” and click “Add”.
    It will look similar to this:
  3. Although these settings are not too bad, we can now go on and improve:
    • First of all, change the name of the profile: SSLP_FE_<name>
      I like to keep a naming convention so I can easily identify to which virtual server this profile will be bound.
    • Deny SSL Renegotiation: FRONTEND_CLIENT
    • SNI Enable: check if you want to do SNI or not
    • HSTS: Activate
      Max Age: 15552000 (180 days is the minimum value)
      Include Subdomains:
      Preload: Activate
    • Protocol:
      • SSLv3: Deactivate
      • TLSv1: Deactivate
      • TLSv12: Activate
      • TLSv13: Activate
      • Zero RTT Early Data: Deactivate
  4. Click OK to accept the new settings, and then click done to save the profile.
  5. Attach the SSL profile to your SSL-terminating virtual server, such as a content-switching or load-balancing virtual server.

Intermediate result

As you can see, even with the initial settings on the new SSL profile, we still get an F.
Time to update the supported ciphers on the SSL profile.

SSL Ciphers

SSL Ciphers are probably the most important aspect of configuring SSL, as you still end up with an incomplete setup by default. Although we have disabled insecure protocols in the previous step, there are still weak ciphers bound to the SSL profile.

Let’s remediate!

Cipher Group

  1. Go to the next section in the left-hand menu:
    Traffic Management –> SSL –> Cipher Groups
  2. Click “Add” to create a new cipher group, and you’ll get to the next screen:

  3. Configure the cipher group:
    • Cipher Group Name: CG_NSROOTBLOG_20200221
    • Click “Add” to configure the ciphers. It is important to bind them in the same order:
      • TLS1.3-AES128-GCM-SHA256
      • TLS1.3-AES256-GCM-SHA384
      • TLS1.3-CHACHA20-POLY1305-SHA256
      • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
      • TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
  4. When you’re done, click the “Create” button.

Note: It is currently impossible to get a 100% score on Cipher Strength when evaluating your configuration on SSL Labs if TLS1.3 is enabled and the ciphers above are configured. This is due to the last cipher configured: “TLS.1.3-AES128-GCM-SHA256”.

For more information, refer to the following issue at SSL Labs: TLS 1.3 Cipher Strength 90%?

SSL Profile

  1. Go back to the “SSL Profiles” through System –> Profiles –> SSL Profiles
    Open your previously created SSL profile.
  2. Click on “SSL Ciphers” in the right-hand menu.
    It should only show the default cipher group being bound.
  3. Click the pencil on the right to start editing the configured SSL ciphers.
  4. Click “Remove all”.
  5. Click “Add” and select the SSL cipher group you created in the previous section.
  6. Click “OK” and then “Done”.

Intermediate result

The new scan reveals a much better score, but we aren’t there yet.

Key Exchange

Elliptic Curve Cryptography

From the previous intermediate result, we saw that we are close to a 100% score on all ratings.
As mentioned before, it is currently impossible to get a 100% score on Cipher Strength, due the limitation of the used OpenSSL library at SSL Labs and the way results are processed.

The last area for improvement comes at the “Key Exchange” level. By default, there are 4 ECC Curve Names bound to a SSL profile or a SSL virtual server. So let’s take the last step!

  1. Go back to the “SSL Profiles” through System –> Profiles –> SSL Profiles
    Open your previously created SSL profile.
  2. Click on the section for ECC Curve.
  3. Select the ECC Curve Name:
    1. P_224
    2. P_256
  4. Click “Unbind”
  5. Click “Close”
  6. Click “Done” to save the changes on the SSL Profile.


Final Result




Command-line Configuration

 add ssl cipher CG_NSROOTBLOG_20200221
bind ssl cipher CG_NSROOTBLOG_20200221 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256 -cipherPriority 1
bind ssl cipher CG_NSROOTBLOG_20200221 -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -cipherPriority 2
bind ssl cipher CG_NSROOTBLOG_20200221 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 -cipherPriority 3
bind ssl cipher CG_NSROOTBLOG_20200221 -cipherName TLS1.2-ECDHE-ECDSA-CHACHA20-POLY1305 -cipherPriority 4
bind ssl cipher CG_NSROOTBLOG_20200221 -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 5
bind ssl cipher CG_NSROOTBLOG_20200221 -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 6

add ssl profile SSLP_FE_NSROOTBLOG_SNI -sessReuse ENABLED -sessTimeout 120 -tls1 DISABLED -tls11 DISABLED -tls13 ENABLED -SNIEnable ENABLED -denySSLReneg FRONTEND_CLIENT -HSTS ENABLED -maxage 15552000
bind ssl profile SSLP_FE_NSROOTBLOG_SNI -eccCurveName P_384
bind ssl profile SSLP_FE_NSROOTBLOG_SNI -eccCurveName P_521
bind ssl profile SSLP_FE_NSROOTBLOG_SNI -cipherName CG_NSROOTBLOG_20200221 -cipherPriority 1

unbind ssl profile SSLP_FE_NSROOTBLOG_SNI -eccCurveName P_224
unbind ssl profile SSLP_FE_NSROOTBLOG_SNI -eccCurveName P_256
unbind ssl profile SSLP_FE_NSROOTBLOG_SNI -cipherName DEFAULT

add ssl profile SSLP_FE_NSROOTBLOG_NOSNI -sessReuse ENABLED -sessTimeout 120 -tls1 DISABLED -tls11 DISABLED -tls13 ENABLED -denySSLReneg FRONTEND_CLIENT -HSTS ENABLED -maxage 15552000
bind ssl profile SSLP_FE_NSROOTBLOG_NOSNI -eccCurveName P_384
bind ssl profile SSLP_FE_NSROOTBLOG_NOSNI -eccCurveName P_521
bind ssl profile SSLP_FE_NSROOTBLOG_NOSNI -cipherName CG_NSROOTBLOG_20200221 -cipherPriority 1

unbind ssl profile SSLP_FE_NSROOTBLOG_NOSNI -eccCurveName P_224
unbind ssl profile SSLP_FE_NSROOTBLOG_NOSNI -eccCurveName P_256
unbind ssl profile SSLP_FE_NSROOTBLOG_NOSNI -cipherName DEFAULT


RSA Key Size

In order to get 100% on Key Exchange, you will need a key size of 4096-bits!

Certificate Authority Chain

Although not explicitedly covered in this blogpost, it is worth noting that your SSL CA certificate chain must be configured correctly.
This means that you should link all intermediate ca certificates to the server certificate linked to your SSL virtual server.

It is imperative that the root ca certificate is not linked in the chain!

Credits to Daniel Weppeler (@_DanielWep) for the remark.


SSL Profile for virtual servers with or without SNI

The command-line scripts have been updated to include two ssl profiles, one with SNI enabled, one without SNI.

Thanks to Erik Bakker (@bakker_erik) for the remark.