Hardware Security Module Reading Time: 8 minutes

How to Integrate a Thales Hardware Security Module and a CipherTrust Manager: On-Premises?

When working with different security products, one of the many devices you run into is Hardware Security Modules or HSMs. HSMs are devices designed to securely store encryption keys for use by applications or users. The Thales Luna HSM can be purchased as an on-premises, cloud-based, or on-demand device, but we will be focusing on the on-demand version.

Another option available for the Thales Luna HSM is a PED-authenticated version versus the password-authenticated version. The PED-authenticated Hardware Security Module uses a PED device with labeled keys for roles within the HSM, with PINs correlating to the PED keys. This is a way of creating role separation between the different roles on the HSM. The password-authenticated version only requires a typed-in password, and a PED device is not required. This guide can be used for both types of HSM.  

The CipherTrust Manager from Thales works as a centralized key management device, allowing users to generate, manage, destroy, export, and import encryption keys for client and application uses. Working alongside the CipherTrust Manager (CM) can be an HSM that will store the keys that the CM will use.

The CM also has the same options available to it as the Luna HSM, however, if the HSM in use is a PED-authenticated HSM, then the CM must also be PED-authenticated. The same rule is in place for password-authenticated HSMs. Before we move into the integration steps, there are a few pre-integration steps that must be discussed.  

Pre-Integration Steps 

Before integrating an HSM and CM, a few steps must be done in the process beforehand. The most important task to complete beforehand is ensuring that both the HSM and CM have been fully configured. This includes the network configuration, SSH configuration, and the NTP server setup.

When integrating a Hardware Security Module and a CipherTrust Manager, they must use the same NTP, or Network Time Protocol, server so that the times are set the same between the two devices. Additionally, the HSM must be reachable across the network by the CM. This means that the CM and HSM must be on the same subnetwork so that the pinging and accessing of the HSM can be done from the CM.

Also, having remote access to the HSM and CM is important, as sitting in a data center with the CM and HSM can become overwhelming so being able to reach the devices remotely is vital. We will not go over how to configure an HSM and CM in this guide, as this is a long and involved process that you can reach out to www.encryptionconsulting.com for assistance in. Instead, we will focus on the major steps involved in the process of integrating a Hardware Security Module and a CipherTrust Manager.


 When working through these integration steps, you first want to ensure a number of different elements are in place and working properly. This begins with ensuring the CM can reach the HSM. This can be done through a number of steps, but the simplest is SSHing into the CM and pinging the IP address of the HSM. This will allow you to be certain that communication between the HSM and CM is in place properly.

Another step is to ensure that both devices are updated to the latest software and firmware versions. This will ensure that all security patches are implemented that need to be in place. One final step is to ensure that the NTP server is working properly with both devices. Without the NTP servers running properly, the integration of the two devices will fail.  

HSM Integration Steps 

To begin integrating the HSM and CM, certificates must first be created. This can be done through the Lunaclient used with the HSM. This software is downloaded from the Thales Knowledge Center, when using a customer support portal login. Once the Lunaclient is downloaded you will need to run the following command: 

cd “C:\Program Files\Safenet\lunaclient” 

From here, you can run the command vtl createcert -n <cert name>. This will create a certificate and private key in the C:\Program Files\Safenet\lunaclient\cert\client directory. From the same lunaclient directory, the command pscp.exe admin@<HSM_IP>:server.pem server_<HSM hostname>.pem should be run for each HSM being integrated.

This will transfer the server certificates of each HSM to the lunaclient directory under the name of server_<HSM hostname>.pem. We specify a different name than server.pem only because if there are multiple HSMs being integrated, the old server.pem certificates would be replaced with the new ones imported in. Now that you have all this information, we will need to get the partition label and the partition serial number of the partitions associated with the CM. This is done by sshing into the HSM via the command ssh admin@<HSM IP>.

Once logged in, the command par list can be run to show all of the different partitions on the HSM, the serial numbers, and the partition labels. Once those are noted down, the final step is to make the CM a client of the HSM via the certificate we have created. This can be done by transferring the certificate file from the client device to the HSM with the following command from the lunaclient directory:  

pscp.exe ./cert/client/<client cert name>.pem admin@<HSM_IP>

Now that the client certificate is on the HSM, the client must be registered with the command client register -n <name of the client> -h <name of the client certificate without the .pem at the end>. Now that the client was successfully registered, a partition must be assigned to the client via the command

client assignpartition -c <client name> -p <partition name>.

These steps should be done for each HSM being integrated.  

CM Integration Steps 

Now that the CM has been set as a client of the HSM, we must directly connect these files with the CM. To do this, we need to log in to the GUI of the CipherTrust Manager via one of the IP addresses set up during network configuration. Once we go to the webpage https://<IP of the CM>, we can log in and go to the Admin Settings>HSM tab.

From here, we follow the steps as they are prompted. We need to provide the HSM IP address, the HSM server certificate, both the client certificate and key, the partition label, and the partition serial number. For the certificates, you will need to open, copy, and paste the contents of those files to the GUI. Additionally, the Crypto Officer password for the partition will need to be provided as well.  

Once these are provided, the GUI will ask if you want to replicate the keys in the partition across the environment. You should select yes to this option, as the data in the partitions will be lost if you do not. Once this has been done, the CM will restart itself and its services, ensuring it can connect to the HSM properly.

Once the reboot occurs, you can log back into the GUI and see that the HSM is now integrated. From here, you can add additional HSMs to the integration, requiring only the partition password, serial number, label, HSM IP, and the HSM server certificate. Now you have successfully integrated all of your HSMs with your Cipher Trust Manager! 

Known Issues and Workarounds 

Problem: HSM Seal not reachable from the CM GUI. 

Solution: If an error says the HSM seal is not able to be gotten when attempting to connect to the GUI, there is likely an issue with your client certificate. There is a rare bug when creating certificates with vtl createcert that causes a certificate to be created for 11 days instead of ten years. Change the extension of your client certificate to .cert and look at the expiration date of the certificate.

You will need to SSH into the CM and run the command kscfg system reset. You will lose the HSM configurations in place, but you will keep the SSH and network configurations. From here, you will need to refollow the steps for creating a client of the HSM with a new certificate. 

Problem: IP Address unreachable for the GUI 

Solution: If after updating the software of the CM you cannot seem to reach your IP addresses, you will need to setup the same IP address on every interface until you find the appropriate one. The issue is that when updating from version 2.0 to version 2.9, along the way there is a bug that may change the MAC address of the network interfaces to the incorrect ones.

They may say they are interface 1 or 0, but they are actually interface 2 or 3. This can be fixed by trying the same IP address on every interface until it works properly, and you can connect to it.  


As I mentioned, we did not go into detail here about the general configuration of the HSM and CM. These can be done on your own or with our assistance. To reach out to us for configuration help or assistance, go to our website www.encryptionconsulting.com. We can assist with assessments, planning, and implementation of HSMs, PKIs, CMs, and encryption advisory.

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.


About the Author

Riley Dickens is a graduate from the University of Central Florida, who majored in Computer Science with a specialization in Cyber Security. He has worked in the Cyber Security for 4 years, focusing on Public Key Infrastructure, Hardware Security Module integration and deployment, and designing Encryption Consulting’s Code Signing Platform, Code Sign Secure. His drive to solve security problems and find creative solutions is what makes him so passionate about the Cyber Security space. His work with clients has ensures that they have the best possible outcome with encryption regulations, implementations, and design of infrastructure. Riley enjoys following his passion of penetration testing in his spare time, along with playing tennis.

Explore the full range of services offered by Encryption Consulting.

Feel free to schedule a demo to gain a comprehensive understanding of all the services Encryption Consulting provides.

Request a demo