In SSL offload and acceleration
In Citrix ADC 12.1
In Citrix ADC
In All products
Product Documentation
In SSL offload and acceleration
In Citrix ADC 12.1
In Citrix ADC
In All products
Citrix ADC 12.1 Citrix ADC 13.0
View PDF

Architecture overview

January 25, 2019
Contributed by:  C

The three entities that are part of a Citrix ADC-Thales deployment are a Thales nShield Connect module, a remote file server (RFS), and a Citrix ADC.

The Thales nShield Connect is a network-attached hardware security module. The RFS is used to configure the HSM and to store the encrypted key files.

Hardserver, a proprietary daemon provided by Thales, is used for communication between the client (ADC), the Thales HSM, and the RFS. It uses the IMPATH secure communication protocol. A gateway daemon, called the Hardserver Gateway, is used to communicate between the Citrix ADC packet engine and the Hardserver.

Note: The terms Thales nShield Connect, Thales HSM, and HSM are used interchangeably in this documentation.

The following figure illustrates the interaction between the different components.

Thales architecture overview

In a typical deployment, the RFS is used to securely store keys generated by the HSM. After the keys are generated, you can securely transfer them to the ADC and then use the GUI or command line to load the keys to the HSM. A virtual server on the ADC uses Thales to decrypt the client key exchange to complete the SSL handshake. Thereafter, all the SSL operations are performed on the ADC.

Note: The terms keys and application key tokens are used interchangeably in this documentation.

The following figure illustrates the packet flow in the SSL handshake with the Thales HSM.

Figure 1. SSL Handshake Packets Flow Diagram with Citrix ADC Using Thales HSM

SSL handshake with Thales

Note: The communication between the ADC and the HSM uses a Thales proprietary communication protocol, called IMPATH.

Architecture overview

January 25, 2019
Contributed by:  C

In this article

Edit this article