Set Up Two Thales CipherTrust Cloud Key Manager Appliances in OCI, Create a Cluster between them, and Configure One as a Certificate Authority
Introduction
Organizations increasingly seek greater control over their cryptographic keys in today’s cloud-first landscape to meet security, compliance, and data sovereignty requirements. Thales CipherTrust Cloud Key Manager (CCKM) offers a centralized solution for managing encryption keys and secrets across multicloud and hybrid environments, including Oracle Cloud Infrastructure (OCI). A key feature of this architecture is support for Hold Your Own Key (HYOK), allowing you to retain complete control over your encryption keys even when using third-party cloud services.
This tutorial walks you through the complete setup of two Thales CCKM appliances in OCI, including:
- Deploying two CCKM instances.
- Creating a high availability cluster between them.
- Configuring one of the appliances as a Certificate Authority (CA) for issuing and managing internal certificates.
By the end of this tutorial, you will have a robust and scalable CCKM environment that supports key use cases such as Bring Your Own Key (BYOK), HYOK, and centralized key lifecycle management. This setup is ideal for enterprises looking to extend their key control into the cloud while adhering to the highest data security standards.
Note: In this tutorial, the terms Thales CipherTrust Cloud Key Manager (CCKM) and Thales CipherTrust Manager are used interchangeably. Both refer to the same product.
Objectives
- Task 1: Review the OCI virtual cloud network (VCN) infrastructure.
- Task 2: Deploy the first Thales CCKM appliance.
- Task 3: Perform initial configuration on the first Thales CCKM appliance.
- Task 4: Deploy the second Thales CCKM appliance and perform initial configuration on the CCKM.
- Task 5: Review the connection between the Thales CCKM appliances Remote Peering Connection (RPC).
- Task 6: Configure DNS.
- Task 7: Configure the first Thales CCKM appliance as a Certificate Authority (CA).
- Task 8: Create a cloud service provider (CSR) for both Thales CCKM Appliances and sign them by the CA.
- Task 9: Configure Thales CCKM appliance clustering.
Task 1: Review the OCI Virtual Cloud Networks (VCN) Infrastructure
Before deploying the Thales CCKM appliances, it is essential to understand the underlying OCI network architecture that will support them.
In this setup, we are using two separate VCNs:
- One VCN is in the Amsterdam (AMS) OCI region.
- Second VCN is in the Ashburn (ASH) OCI region.
These two regions are connected through a RPC, enabling secure and low-latency communication between the CCKM appliances across regions. This cross-region connectivity is essential for high availability, redundancy, and clustering of the CCKMs.
The CCKM appliances will be deployed in public subnets within each VCN for this tutorial. This approach simplifies initial access and management over the internet, for example, through SSH or the web interface. However, it is important to note that best practice in production environments is to deploy these appliances in private subnets and manage access through a bastion host or a stepstone (jump) server. This reduces the exposure of the appliances to the public internet and aligns with a more secure network posture.
We will deploy the CCKMs within this reviewed VCN setup in the next task.
Task 2: Deploy the first Thales CCKM Appliance
Before deploying the first Thales CCKM appliance, we must ensure the required image is available in OCI.
While the official Thales documentation typically recommends opening a support case to obtain an OCI Object Storage URL for directly importing the CCKM image into OCI, we will be using an alternative method.
We have received a local 610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.ova
file from Thales. Instead of using the provided URL, we will:
- Extract the
.vmdk
file from the.ova
archive. - Upload the
.vmdk
file to an OCI Object Storage bucket. - Create a custom image in OCI from the
.vmdk
file. - Deploy the CCKM instance using this custom image.
This method gives us complete control over the image import process and is especially useful in air-gapped or custom deployment scenarios.
-
Save the
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.ova
file inside a new folder on the local disk. -
Extract the
.ova
file. -
Notice the
.vmdk
file in the extracted folder.
With the OCI network infrastructure, we are ready to deploy the first Thales CCKM appliance in the Amsterdam (AMS) region. Log in to the OCI Console.
-
Navigate to Storage, Object Storage and click Buckets.
-
Make sure you are in the correct Compartment and click Create Bucket.
-
Enter the following information and click Create to finish.
- Bucket Name: Enter
CCKM_Bucket
. - Storage Tier: Select Standard (default).
- Leave all other settings at default (unless encryption or access policies are required for your use case).
- Bucket Name: Enter
-
Click the newly created OCI Object Storage bucket.
-
Scroll down.
-
Click Upload.
-
Enter the following information.
- In Object Name Prefix, enter
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA
. - Leave all other settings at default.
- Select your
.vmdk
file (for example,k170v-2.19.0+14195-disk1.vmdk
) from your local machine and click Upload and wait for the process to complete.
- In Object Name Prefix, enter
-
When the upload is finished, click Close.
-
Notice that the
.vmdk
file is uploaded.
After uploading the .vmdk
file to your OCI Object Storage bucket, follow these steps to import it as a custom image.
-
Go to the OCI Console, navigate to Compute and click Custom Images.
-
Click Import Image.
-
Enter the following and click Import Image.
- Name: Enter
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA
. - Operating System Version: Match the OS inside the CCKM image (check Thales documentation—typically a version of Debian or Ubuntu).
- Select Import from an OCI Object Storage bucket.
- Bucket: Select the bucket.
- Object: Select the object we uploaded in the previous section (the
.vmdk
file). - Image Type: Select VMDK.
- Name: Enter
-
Scroll down.
-
The import state is in progress, with a percentage completed while importing.
-
When the image import is completed, the image will be available.
-
Go to the OCI Console, navigate to Compute and click Instances.
-
Click Create Instance.
-
Enter the following information.
-
Name: Enter instance name. For example,
CCKM-1
. -
Select any available AD in the selected region (for example,
AD-1
in Amsterdam).
-
-
Click Change image under the Image and shape section and select Custom Images.
-
Enter the following information and click Select Image.
-
Select My images.
-
Select Custom images.
-
Custom image name: Select your imported image. For example,
610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA
.
-
-
Select Shape (
VM.Standard.E5.Flex
) and configure OCPU and memory.Note: Check the minimum specification requirements from Thales for CCKM (usually at least 2 OCPU / 8 GB RAM).
-
Select your existing VCN and subnet. Use a Public Subnet if you want direct SSH/web access (or private subnet with Bastion if following best practices).
-
Select Automatically assign private IPv4 address and Automatically assign public IPv4 address.
-
In Add SSH keys, select Upload public key files and upload a
.pub
file. This key will be used to access the VM through SSH. Click Create.The instance is in PROVISIONING state.
-
When the PROVISIONING has been completed successfully, the instance state will change to RUNNING. Notice the public and private IP addresses we will need for configuration and management later.
-
To test SSH, use Royal TSX application, and configure the SSH session.
-
In the credentials tab of the Royal TSX session, specify the username. For example,
ksadmin
. -
Make sure you also select the corresponding Private Key File.
-
Log in to the newly deployed CCKM with SSH.
-
We will use the web GUI to configure the CCKM.
-
Browse to the public IP address or private IP if you connect internally using your web browser.
-
Any CA cannot validate the self-signed certificate, so click Advanced.
-
Proceed with the connection anyway.
-
You might see the following error, which means that not all services on the instance have been started. Wait for all the services to start; this can take up to 5 minutes.
-
When all services are started, you get a message that all services are okay.
-
Log in with Username as
admin
and Password asadmin
. After the first log in, you will be prompted to change the password. -
Change the password by following the instructions.
-
Log in using your new password.
-
Notice that you are logged in, and the CCKM has been deployed successfully.
The following image illustrates the current state of our deployment so far.
Task 3: Perform Initial Configuration on the First Thales CCKM Appliance
Now that the first CCKM appliance is deployed and accessible, it is time to perform the initial configuration. This includes setting up the system clock using an NTP server and activating the evaluation license or the actual license provided by Thales.
These steps ensure the appliance is operating with accurate time critical for certificate management, logging, and synchronization and is fully functional during the evaluation or setup phase.
-
Navigate to Admin Settings, NTP and select Add NTP Server.
-
Enter a reliable NTP server’s hostname or IP address (for example,
169.254.169.254
(Oracle’s public NTP Server IP) or your organization’s internal NTP source) and click Add NTP Server. -
Notice the message that the NTP Server was added successfully. Click Close.
-
Verify that the time is synchronized correctly.
-
Go to Admin Settings, Licensing and click Start CipherTrust Platform Evaluation.
-
Scroll down.
-
Click Start CipherTrust Platform Evaluation.
-
It will take a few minutes before the license is activated.
-
Review the activated license.
Task 4: Deploy the Second Thales CCKM Appliance and Perform Initial Configuration
Follow the steps provided in Task 2 and Taks 3 to deploy the second CCKM in the ASH region.
-
Make sure the second CCKM is deployed and RUNNING.
-
Test the connection between SSH and the second CCKM.
-
Test the connection between web and the second CCKM.
The following image illustrates the current state of our deployment so far.
Task 5: Review the Connection between the Thales CCKM Appliances RPC
To prepare for high availability and clustering between the two Thales CCKM appliances, it is essential to ensure proper connectivity between the regions in which they are deployed.
In our setup, a RPC has been established between the Amsterdam (AMS) and Ashburn (ASH) OCI regions. This RPC enables secure, low-latency communication between the two VCNs where each CCKM appliance resides.
What has been configured:
- Remote Peering Connection (RPC) is established and active between AMS and ASH.
- Routing tables are appropriately configured to ensure traffic between the two VCNs is forwarded correctly.
- Security lists in both regions are currently configured to allow all ingress and egress traffic. This is done to simplify Proof of Concept (PoC) testing and eliminate connectivity-related issues during the initial setup and clustering process.
Note:
- In a production environment, it is strongly recommended to restrict traffic to only the required ports for clustering and management.
- Refer to Thales documentation for the exact port requirements (for example, TCP ports like
443
,8443
,5432
, and others used by the CCKM cluster protocol).
This cross-region network setup ensures that the CCKMs can communicate seamlessly during the cluster creation process, which we will address in one of the following sections.
Task 6: Configure DNS
Proper DNS resolution is required to enable seamless communication between the two appliances. This is especially important for secure clustering, certificate handling, and overall service stability.
Note: From this point forward, we will refer to the Thales CCKM appliances as Thales CipherTrust Manager, short for CyberTrust Manager.
While using a custom internal DNS server, we are leveraging OCI DNS services with a private DNS zone in this deployment. This allows us to assign meaningful, Fully Qualified Domain Names (FQDNs) to the Thales CipherTrust Managers and ensures they can communicate across regions without relying on static IPs.
- Private DNS Zone Name: Enter
oci-thales.lab
. - Scope: Select Private.
- Associated VCNs: Both AMS and ASH VCNs (to allow cross-region name resolution).
We have created two A records within the oci-thales.lab
zone, pointing to the private IPs of each Thales CipherTrust Manager appliance:
Hostname | FQDN | Points to |
---|---|---|
ctm1 |
ctm1.oci-thales.lab |
Private IP of Thales CipherTrust Manager in AMS |
ctm2 |
ctm2.oci-thales.lab |
Private IP of Thales CipherTrust Manager in ASH |
Using FQDNs makes managing certificates and cluster configurations easier and avoids coupling the configuration to fixed IPs.
-
Go to the OCI Console and navigate Virtual Cloud Networks. Make sure you are in the AMS region.
-
Click the VCN.
-
Click the DNS Resolver (for that VCN).
-
Click the Default Private View (for that DNS Resolver and VCN).
-
Click Create Zone.
-
Enter the following information and click Create.
- Zone Name: Enter
oci-thales.lab
. - Compartment: Select the correct one.
- Zone Name: Enter
-
Click the zone.
-
Click Manage Records.
-
Click Add record.
-
To create A Record for
ctm1
, enter the following information.- Record Type: Enter A - IPv4 address.
- Name: Enter
ctm1
. - TTL: Leave default (for example,
300
).
-
Enter private IP of Thales CipherTrust Manager in AMS as RDATA (IP Address) and click Save Changes.
-
Create a second A record for
ctm2
.- Record Type: Enter A - IPv4 address.
- Name: Enter
ctm2
. - TTL: Leave default (for example,
300
).
-
Enter private IP of Thales CipherTrust Manager in ASH as RDATA (IP Address) and click Save Changes.
-
Click Publish Changes.
-
Repeat the same steps you followed for AMS now in ASH to allow DNS name resolution in ASH.
To validate that DNS is working as expected, SSH into one of the Thales CipherTrust Manager instances and run ping ctm2.oci-thales.lab
from the first Thales CipherTrust Manager (running in AMS).
The FQDN will be resolved to the correct IP address, and when the RPC, routing and security lists are correctly configured, the ping is successful.
Repeat the ping from CTM2 (running in ASH) to confirm bidirectional resolution.
Task 7: Configure the first Thales CCKM Appliance as a Certificate Authority (CA)
The first time a CipherTrust Manager is started, a new local CipherTrust Manager Root CA
is automatically generated. This CA is used to issue initial server certificates for the interfaces available in the system. So there is no need to create a new one.
Note: Make sure you are on the AMS Thales CipherTrust Manager.
-
Click CA and select Local.
-
Review the local automatically generated CA (CipherTrust Manager Root CA) we will use to create and sign CSRs.
The following image illustrates the current state of our deployment so far.
Task 8: Create a CSR for both Thales CCKM Appliances and Sign by the CA
With both CyberTrust Manager appliances deployed and DNS configured, it is time to enable secure, certificate-based communication between them. Since the AMS Thales CipherTrust Manager and ASH are configured as the CA, we will use the AMS Thales CipherTrust Manager to generate and sign certificates for both appliances.
-
The high-level steps will be:
-
Generate Certificate Signing Requests (CSRs) for Thales CipherTrust Managers (AMS and ASH) on the AMS Thales CipherTrust Manager.
-
Use the AMS Thales CipherTrust Manager CA to sign both CSRs.
-
Install the signed certificate on each Thales CipherTrust Manager.
-
This ensures all Thales CipherTrust Manager-to-Thales CipherTrust Manager communication is trusted and encrypted, a critical requirement for cluster formation and secure API access.
Note: Perform these steps only on the AMS Thales CipherTrust Manager.
-
Log in to the Thales CipherTrust Manager AMS Console.
-
Navigate CA and click CSR Generator.
-
Enter the following information and click Generate CSR and download Private Key.
- Select Generic CSR.
- Common Name: Enter the Thales CipherTrust Manager’s FQDN. For example,
ctm1.oci-thales.lab
. - Display Name: Enter a name. For example
CTM1 (AMS)
. - Algorithm: Select ECDSA.
- Size: Select 256.
- Subject Alternative Name: Also include the FQDN here. For example
ctm1.oci-thales.lab
.
Note: The private key will be automatically downloaded.
-
Click Download CSR to download and save the generated
.csr
file. -
Repeat the same steps (still on the Thales CipherTrust Manager AMS CA).
-
Enter the following information and click Generate CSR and download Private Key.
- Select Generic CSR.
- Common Name: Enter the Thales CipherTrust Manager’s FQDN. For example,
ctm1.oci-thales.lab
. - Display Name: Enter a name. For example
CTM2 (AMS)
. - Algorithm: Select ECDSA.
- Size: Select 256.
- Subject Alternative Name: Also include the FQDN here. For example
ctm2.oci-thales.lab
.
Note: The private key will be automatically downloaded.
-
Click Download CSR to download and save the generated
.csr
file.
To keep track of the generated Certificate Signing Requests (CSRs) and private keys, creating a clean folder structure on your local machine or a secure admin server is a good practice. Here’s a simple example structure:
-
Navigate to CA, Local and select the CA.
-
Click Upload CSR.
-
Use the Thales CipherTrust Manager’s FQDN (for example,
ctm1.oci-thales.lab
) as Display Name and copy the content of the generated CSR in the CSR field. -
Select Server as Certificate Purpose and click Issue Certificate.
-
Click the three dots at the end of the signed certificate entry and click Download to download the signed certificate for CTM1.
-
Repeat the same steps (still on the Thales CipherTrust Manager AMS CA).
-
Use the Thales CipherTrust Manager’s FQDN (for example,
ctm2.oci-thales.lab
) as Display Name and copy the content of the generated CSR in the CSR field. -
Select Server as Certificate Purpose and click Issue Certificate.
-
Click the three dots at the end of the signed certificate entry and click Download to download the signed certificate for CTM2.
-
Rename and store the signed certificates in the created folder structure.
In addition to signing the individual Thales CipherTrust Manager certificates, the CA Root Certificate is a critical piece of the trust chain. This root certificate establishes the foundation of trust for all certificates issued by your Thales CipherTrust Manager, acting as the CA.
-
Navigate to CA, Local, click the three dots at the end of the Thales CipherTrust Manager AMS CA and click Download to download the Root CA certificate of Thales CipherTrust Manager AMS CA.
-
Store the downloaded root cert in the created folder structure.
-
The next step is to create a full certificate chain file that bundles your signed certificate, the CA root certificate, and your private key into a single file.
This is required by applications or appliances like Thales CipherTrust Manager for seamless TLS configuration.
-----BEGIN CERTIFICATE----- Signed CTM1 Cert by CA -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Root CA Cert -----END CERTIFICATE----- -----BEGIN EC PRIVATE KEY----- Private Key -----END EC PRIVATE KEY-----
-
Do this for both Thales CipherTrust Managers and store the newly concatenated certificate files in the created folder structure.
-
After creating the signed certificates on the CA and preparing the complete certificate chain files, the next step is to upload them to each Thales CipherTrust Manager appliance.
Let us start with the first CTM1 running in AMS.
-
Navigate to Admin Settings, Interfaces, click the three dots of the web interface and select Renewal Certificate Options.
-
Select Upload/Generate and click Ok.
-
Upload the full chain certificate for CTM1 using the PEM format and click Upload Certificate.
-
Again, click the three dots of the web interface and select Renewal Certificate Options.
-
Select Apply and click Ok.
-
Click Apply.
-
Click Services Page.
-
Click System Restart.
-
Click Restart Services to restart the server and web services to activate the new certificate.
-
Repeat the same steps for CTM2 running in ASH.
-
To test the newly signed certificate in your local environment using Google Chrome, you first need to install it and its CA chain into your operating system’s trusted certificate store.
This is out of the scope of this tutorial, but we will show you how we tested the new Thales CipherTrust Manager certificates signed by the Thales CipherTrust Manager AMS CA.
-
Open the Google Chrome browser settings, navigate to Privacy and Security and click Security.
-
Click Manage certificates.
-
Click Local certificates and in the Custom section, click Installed by you.
-
We have already imported the full chain certificates and root certificate on the local OS.
This is also where you can import the certificates; this Import button will bring you to the OS-level certificate settings.
-
Because we have not configured the DNS server on the internet, we are updating local
/etc/hosts
file with the manual host entries to test the certificates from local machine using the FQDN. -
Browse to the CTM1 FQDN using Google Chrome and click the security settings.
-
Click Connection is secure.
-
Click Certificate is valid.
-
Review the Issued to details.
Task 9: Configure Thales CCKM Appliance Clustering
Clustering Thales CipherTrust Cloud Key Manager (CCKM) appliances enables high availability and load balancing for cryptographic key management. This ensures continuous service and fault tolerance in your security infrastructure.
Clustering is configured entirely from the management console of a single (primary) Thales CipherTrust Manager appliance (in this example, the Thales CipherTrust Manager running in AMS). Use this appliance’s interface to create the cluster and add other Thales CipherTrust Manager appliances as cluster nodes.
-
Navigate to Admin Settings, Cluster and click Manage Cluster.
-
Click Add cluster.
-
Click Next.
-
Enter the hostname of the AMS Thales CipherTrust Manager (which is the CTM1 in AMS with private IP 10.222.10.111).
We do not intend to use (or create) a cluster over the internet using the public IP, so we are using the private IP address in both fields.
-
Click Add Cluster.
-
Notice that this machine has created a new cluster and is part of its cluster.
-
In the same AMS CTM1, click Manage Cluster and select Add Node to add the ASH CTM2.
-
Specify the ASH Thales CipherTrust Manager IP address as the node to add to the cluster. We can use the DNS name here.
-
Click Add Node.
-
A new browser window/tab will be opened to the ASH CMT2. If you are not logged in to the ASH CMT2, you might get a login prompt first.
-
Some cluster configuration activity will happen in the background.
-
Click Join to confirm the joining.
-
Some more cluster configuration activity will happen in the background.
-
Click Finish! to confirm the Success message.
-
If the newly opened browser window/tab is still open, you can close it manually.
-
In the AMS CTM1, click Finished to confirm.
-
At first, the newly added node (ASH CTM2) will appear down. Wait for a few minutes so the cluster can detect its presence.
-
You might also see an error message at the top of the screen. This means that the cluster is still in configuration mode. Wait a few minutes for the message to disappear.
To verify if the Thales CipherTrust Manager cluster configuration is done correctly and is healthy, you can check CTM1 and CTM2.
-
In CTM1, navigate to Admin Settings and click Cluster.
- Notice that the IP address
10.222.10.111
is from this server (AMS CTM1). - Notice the other node (
10.111.10.32
) from the remote server (ASH CTM2).
- Notice that the IP address
-
In CTM2, navigate to Admin Settings and click Cluster.
-
Notice that the IP address
10.111.10.32
is from this server (ASH CTM2). -
Notice the other node (
10.222.10.111
) from the remote server (AMS CTM1).
-
The following image illustrates the current state of our deployment so far.
Next Steps
In this tutorial, you successfully set up two Thales CCKM Appliances within OCI, established a secure cluster between them, and configured one appliance as the CA. You have built a highly available, secure key management environment by following the step-by-step process from deploying the appliances and configuring the network infrastructure to creating and signing CSRs and enabling clustering. This setup ensures robust cryptographic operations with centralized certificate management, optimizing security and operational resilience in your OCI environment.
If you want to implement Hold Your Own Key (HYOK) using Thales CipherTrust Manager without OCI API Gateway option, follow this tutorial: Set up OCI Hold Your Own Key using Thales CipherTrust Manager without OCI API Gateway.
If you want to implement Hold Your Own Key (HYOK) using Thales CipherTrust Manager with the OCI API Gateway option, follow this tutorial: Set up OCI Hold Your Own Key using Thales CipherTrust Manager with OCI API Gateway.
Related Links
Acknowledgments
- Author - Iwan Hoogendoorn (Cloud Networking Black Belt)
More Learning Resources
Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.
For product documentation, visit Oracle Help Center.
Set Up Two Thales CipherTrust Cloud Key Manager Appliances in OCI, Create a Cluster between them, and Configure One as a Certificate Authority
G37767-01
Copyright ©2025, Oracle and/or its affiliates.