Scoring an A+ at with Citrix Access Gateway in 2020


First of all, I’m not a Citrix product expert, I’m just an IT Security Engineer. This blog article is talking about how you can score an A+ rating on SSL Labs with your Citrix Access Gateway. The way to gain the A+ rating on SSL Labs has been explained in different articles on the internet. For the company I work for, I’ve created a Security Paper with all of the changes required to gain the A+ rating and my idea was to share this document online with the community.

I will walk you through all of the changes I have made on the Citrix Access Gateway to get the A+ rating. In each section, I will do a short explanation of the changes. I will show you how the changes can be made via the CLI and then via the GUI. Do you have any improvements for this paper, let me know!


Make sure that you’re Access Gateway is running on the latest firmware. At the time of writing, the Citrix Access Gateway is running on firmware version NS12.1

Encryption protocols

Make sure that you enable TLSv1.2 and TLSv1.3. You can disable TLSv.1.0 and TLSv1.1. SSLv3 [RFC6101] is an obsolete and insecure protocol, you should already have disabled SSLv3 since there is a known vulnerability known as the POODLE. I regularly come across Netscalers and Access Gateways where SSLv3 is still enabled.

Live blog on SSLv3 protocol vulnerability ‘POODLE’


To disable the TLS/SSL-version described as above and enable TLSv1.2 and TLSv1.3.

set ssl vserver [Name_of_NetScaler_vServer] -ssl3 DISABLED -tls1 DISABLED -tls11 DISABLED -tls12 ENABLED -tlsS13 ENABLED


To change the encryption protocols, please follow the steps below:

  1. Go in the navigation menu to Citrix Gateway;
  2. Click on Virtual Servers and select the virtual server and click on Edit;
  3. Navigate to SSL Parameters and make sure that only TLSv12 and TLSv13 are selected.


Custom Cipher Groups

The predefined DEFAULT Cipher Group which is enabled by default contains legacy ciphers that have to be considered as insecure. To ensure that the Access Gateway is not using weak ciphers you have to create a custom defined cipher group.

My recommendation is to note the creation date of the cipher group in the name of the cipher group. By adding the creation date to the name of the cipher group, it’s handy for later use. You know when the group was created and when new ciphers become available from a later date, that you need to add them to the cipher group.

It’s important to add the ECDHE ciphers at the top of the group, this is necessary for the configuration of Perfect Forward Secrecy with ECDHE. See the Perfect Forward Secrecy section for more information..


add ssl cipher SecureCiphers_20200610
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-ECDHE-ECDSA-CHACHA20-POLY1305
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES-256-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES-128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-AES128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-DHE-RSA-CHACHA20-POLY1305
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES-128-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES-256-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.2-AES128-GCM-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.3-AES256-GCM-SHA384
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256
bind ssl cipher SecureCiphers_20200610 -cipherName TLS1.3-AES128-GCM-SHA256


To change the custom cipher groups through the GUI, follow the steps below:

  1. Go to `Traffic Management;
  2. Navigate to SSL;
  3. Scroll down to Cipher Groups and click on Add to create a cipher group;
  4. Give this cipher group a name and add the secure ciphers to this group.


To bind this cipher group to an existing virtual server go to the Configuration tab and click on Citrix Gateway –> Virtual Servers. Modify the virtual server and click on the edit pencil near SSL Ciphers, make sure that you have removed the DEFAULT cipher group and add the newly created cipher group, in this example, called: SecureCiphers_20200610.


SSL Renegotiation

What’s the purpose of SSL/TLS Renegotiation? The SSL renegotiation process is the new SSL handshake process over an established SSL connection. The SSL renegotiation process can establish another secure SSL session because the renegotiation messages, including the types of ciphers and encryption keys, are encrypted and then sent over to the existing SSL connection.

The Access Gateway does not request the client to renegotiate SSL connection. However, if the client or the back end server initiates a renegotiation process, the appliance supports the process. If you are looking for a more in-depth explanation about SSL Renegotiation, I recommend to watch this Youtube video:


set ssl parameter -denySSLReneg NONSECURE


To change the custom cipher groups through the GUI, follow the steps below:

  1. Go to Traffic Management;
  2. Navigate to SSL;
  3. Click on Change advanced SSL settings;
  4. In the following screen change the Deny SSL Renegotiation to NONSECURE.


Perfect Forward Secrecy

The Perfect Forward Secrecy is a security measure that reduces the risk of being compromised by creating a unique session key for each transaction. If you want to take a closer look at the Perfect Forward Secrecy process, I recommend you to watch this Youtube video:

PFS can be configured on Access Gateway by configuring DHE or ECDHE ciphers. These ciphers ensure that the secret session key created is not shared on the wire (DH algorithm) and that the session key remains alive only for a short time (Ephemeral).


In this blog, I will only show you the configuration of Perfect Forward Secrecy with ECDHE. My recommendation is to configure ECDHE instead of DHE. ECDHE has better performance that DHE with the use of stronger ciphers. Check the References section for the Citrix document to configure Perfect Forward Secrecy with DHE.


Bind the four ECC Curves to the SSL Virtual Server.

bind ssl vserver <vServerName> -eccCurveName P_256
bind ssl vserver <vServerName> -eccCurveName P_384
bind ssl vserver <vServerName> -eccCurveName P_224
bind ssl vserver <vServerName> -eccCurveName P_521


To configure Perfect Forward Secrecy, follow the steps below:

  1. Go to Configuration;
  2. Navigate to Access Gateway;
  3. Select the server you want to edit;
  4. Go to the ECC Curve section and click on the ECC Curves.


Make sure that these four ECC Curves are binded to this server.


If you have followed my instruction to add the ECDHE ciphers at the top of the cipher group, the Perfect Forward Secrecy configuration properly.

Check your configuration

If you have followed my instruction to add the ECDHE ciphers at the top of the cipher group, the Perfect Forward Secrecy configuration properly. To check if Perfect Forward Secrecy is working, you can connect to the website. Through the Developers Tools in the Security tab, you can check the connection. Only if you see TLS1.2 with ECDHE (or with DHE), means that Perfect Forward Secrecy is well configured.


HTTP Strict Transport Security

The HTTP Strict Transport Security (also known as HTST) is a response header which is telling the clients that they have to use the HTTPS website, instead of HTTP. This web security mechanism is to prevent the Access Gateway against various attacks like man-in-the-middle attacks and cookie hijacking.


First, the Rewrite Action needs to be configured.

  1. Go to Configuration;
  2. Select AppExpert;
  3. Click on Rewrite;
  4. Select Actions;
  5. Click here on Add.
  6. Fill in the required fields:
Name: STS_Header
Header Name: Strict-Transport-Security Expression: “max-age=157680000”

The Expression value is in seconds.


After the creation of the Rewrite Action the policy needs to be created. Go into the same Rewrite panel to Policies and click on Add. Fill in the required fields:

Name: HSTS_Policy
Action: STS_Header (This is the previously created Rewrite Action)
Expression: True


Bind this policy to the Virtual Server:

  1. Go to Citrix Gateway;
  2. Navigate to Virtual Servers
  3. Select the virtual server that you want to attach to the HTST policy;
  4. Scroll down to the bottom of the screen at the Response Policies you add the newly created policy HSTS_Policy.

If you want to test if the HSTS Header is being inserted go to the web portal which is bound to the Virtual Server. Open in your favorite internet browser the Developer Tools –> Network, here you can see whether the STS Header is being inserted.


Complete Certificate Chain

To offer a complete certificate chain, you make sure that the Root CA certificate and the Intermediate certificate is also installed on the Citrix Access Gateway. You can bind those certificates to your certificate to get your chain complete. For more information how certificate chains work, I recommend to read this article: How certificate chains work.


To make your certificate chain complete, you have to download the certificate bundle (Linux) from your certificate provider. Then follow these steps:

  1. Go to Traffic Management;
  2. Navigate to SSL;
  3. Select Certificates
  4. Navigate to Server Certificates;
  5. Click on Install;
  6. Select the certificate bundle you have received from your certificate authority and click on Install.


After the installation, select your certificate and in the action button click on Link.


Select the just installed certificate bundle and click on OK.


The Certificate Chain is now complete.


A Certificate Authority Authorization (CAA) record, is a DNS-record which is designed to give domain owners an extra layer of security. The CAA record controls which Certificate Authority has the authorization to issue certificates of that domain. This prevents the issuance of a certificate by an unauthorized CA. On this website you can generate your own CAA record:

DNS CAA Generator

Fill in your domain (example: click on Auto-Generate Policy. The following DNS CAA record needs to be added to the DNS server of, in this example

Name            Type    Value    CAA     0 issue ""
                        0 issue ""
                        0 issue ""
                        0 issue ""


This post is licensed under CC BY 4.0 by the author.