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:

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.

image

Objectives

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:

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.

image

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:

  1. Extract the .vmdk file from the .ova archive.
  2. Upload the .vmdk file to an OCI Object Storage bucket.
  3. Create a custom image in OCI from the .vmdk file.
  4. 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.

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.

After uploading the .vmdk file to your OCI Object Storage bucket, follow these steps to import it as a custom image.

The following image illustrates the current state of our deployment so far.

image

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.

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.

The following image illustrates the current state of our deployment so far.

image

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:

Note:

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.

image

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.

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.

image

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.

image

Repeat the ping from CTM2 (running in ASH) to confirm bidirectional resolution.

image

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.

image

The following image illustrates the current state of our deployment so far.

image

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.

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.

image

Note: Perform these steps only on the AMS Thales CipherTrust Manager.

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:

image

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.

image

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.

To verify if the Thales CipherTrust Manager cluster configuration is done correctly and is healthy, you can check CTM1 and CTM2.

The following image illustrates the current state of our deployment so far.

image

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.

Acknowledgments

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.