Scoring an A+ at with Citrix Access Gateway in 2020

Make your Citrix Netscaler / Access Gateway a safer place


First of all, I'm not a Citrix product expert, I'm just a IT Security Engineer.This Security Paper is talking about how you can score an A+ rating on SSL Labswith you 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 I 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. On each section I will do a short explanation about 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 vulnerebility known as the the POODLE. I regularly come across Netscalers and Access Gateways where SSLv3 is still enabled.


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


Go to Citrix Gateway --> Virtual Servers and select the virtual server and click on 'Edit', navigate to SSL Parameters and make sure that only TLSv12 and TLSv13 are selected.

Enable TLSv1.2 and TLSv1.3

Allow Secure Renegotiation

Secure Renegotiation allows the changing of the details of a handshake after that the connection is established to the Citrix Access Gateway. By enabling this feature the client-server can repeat the negotiation on an existing connection, instead of dropping the connection to rebuild the handshake.


set ssl parameter -denySSLReneg NONSECURE


Go to Traffic Management --> SSL and click under 'Settings' on Advanced SSL Settings. Change the 'Deny SSL Renegotiation' to NONSECURE.

Allow Secure Renegotiation

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 cipher 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. This way you will 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.

NOTE: 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


Go to Traffic Managenet --> SSL --> Cipher Groups and click on 'Add' to create a cipher group, give this cipher group an name and add the secure ciphers to this group.

Add new Cipher 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.

Cipher Group

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 more in-depth explanation about SSL Renegotiation, I recommend to watch this Youtube video:


set ssl parameter -denySSLReneg NONSECURE


Go to Traffic Management --> SSL and click on Change advanced SSL settings. 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 Security Paper, 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


Go to Configuration --> Access Gateway select the server you want to edit and go to the ECC Curve section and click on the ECC Curves.

ECC Curve

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

Four ECC Curves for Perfect Forward Secrecy (FPS)

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. Go to Configuration --> AppExpert --> Rewrite --> Actions click here on Add. Fill in the required fields.

Name: STS_Header Type: INSERT_HTTP_HEADER Header Name: Strict-Transport-Security Expression: "max-age=157680000"

NOTE: The 'Expression' value is in seconds.

Rewrite Action

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

Rewrite Policy

To bind this policy to the Virtual Server, go to Citrix Gateway --> Virtual Servers and select the virtual server. 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 STS Header is being inserted go to the web portal which is bound to the Virtual Server. Open the Developer Tools --> Network, here you can see that the STS Header is being insterted.

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:

To make your certificate chain complete, you have to download the certificate bundle (Linux) from your certificate provider. In the Access Gateway go to Traffic Management --> SSL --> Certificates --> Server Certificates and click on Install.

Select the certificate bundle you have received from your certificate authority and click on Install.

Install Certificate Bundle (Linux)

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

Select the just installed certificate bundle and click on OK.

Select the CA Bundle certificate

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:

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 ""