Setting up two Thales CipherTrust Cloud Key Manager (CCKM) Appliances inside OCI, create a cluster between them and configure one of them as Certificate Authority (CA)

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 multi-cloud 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 inside 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 guide, you will have a robust and scalable CCKM environment that supports key use cases such as BYOK (Bring Your Own Key), 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

CCKM vs CTM In this tutorial, the terms CCKM (CipherTrust Cloud Key Manager) and CTM (CipherTrust Manager) are used interchangeably. Both refer to the same product.

The Steps

• [ ] STEP 01: Review the OCI VCN Infrastructure
• [ ] STEP 02: Deploy the first Thales CipherTrust Cloud Key Manager (CCKM) Appliance
• [ ] STEP 03: Do the initial configuration on the first Thales CipherTrust Cloud Key Manager (CCKM) Appliance
• [ ] STEP 04: Deploy the second Thales CipherTrust Cloud Key Manager (CCKM) Appliance and do the initial configuration on the CCKM
• [ ] STEP 05: Review the connection between the Thales CipherTrust Cloud Key Manager (CCKM) Appliances (RPC)
• [ ] STEP 06: DNS Configuration
• [ ] STEP 07: Configure the first Thales CipherTrust Cloud Key Manager (CCKM) Appliance as a Certificate Authority (CA)
• [ ] STEP 08: Create a CSR for both Thales CipherTrust Cloud Key Manager (CCKM) Appliances and sign them by the CA
• [ ] STEP 09: Configure Thales CipherTrust Cloud Key Manager (CCKM) Appliance Clustering

STEP 01 - Review the OCI VCN Infrastructure

Before deploying the Thales CipherTrust Cloud Key Manager (CCKM) appliances, it's essential to understand the underlying Oracle Cloud Infrastructure (OCI) network architecture that will support them.

In this setup, we are using two separate Virtual Cloud Networks (VCNs):

• One VCN is in the Amsterdam (AMS) OCI region.
• The other VCN is in the Ashburn (ASH) OCI region.

These two regions are connected via a Remote Peering Connection (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's 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'll deploy the CCKMs within this reviewed VCN setup in the next step.

STEP 02 - Deploy the first Thales CipherTrust Cloud Key Manager -CCKM- Appliance

• Official Thales documentation for CCKM version 2.19: [Oracle Cloud Deployment]

Before deploying the first Thales CipherTrust Cloud Key Manager (CCKM) appliance, we must ensure the required image is available in Oracle Cloud Infrastructure (OCI).

While the official Thales documentation typically recommends opening a support case to obtain an Object Storage URL for directly importing the CCKM image into OCI, we'll be using an alternative method.

We've received a local .ova file from Thales (610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA.ova). 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.

• Store 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're ready to deploy the first Thales CipherTrust Cloud Key Manager (CCKM) appliance in the Amsterdam (AMS) region.

• Log in to the [OCI Console].
• From the navigation menu, go to:

   Storage → Object Storage → Buckets

• Make sure you're in the correct Compartment.
• Click Create Bucket.

• Configure the following:
  • Bucket Name: e.g., CCKM_Bucket
  • Storage Tier: Standard (default).
  • Leave all other settings at default (unless encryption or access policies are required for your use case).
• Click Create to finish.

• Click on the newly created Storage Bucket.

• Scroll down.

• Click Upload.

• Configure the following:
  • Object Name Prefix: e.g., 610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA
• Leave all other settings at default.
• Select your .vmdk file (e.g., k170v-2.19.0+14195-disk1.vmdk) from your local machine.
• Click Upload and wait for the process to complete.

• When the upload is finished, click on Close.

• Notice that the .vmdk file is uploaded.

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

• In the [OCI Console], go to the navigation menu.
• Navigate to:

   Compute → Custom Images

• Click Import Image.

• Configure the following:
• Name: e.g., 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).
• Import from an Object Storage bucket (the one we created in the previous section).
• Select the object we uploaded in the previous section (the .vmdk file).
• Image Type: vmdk
• Click Import Image.

• 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.

• In the [OCI Console], open the navigation menu.
• Navigate to: Compute → Instances.

• Click Create Instance.

• Name your Instance, e.g., CCKM-1.
• Choose any available AD in the selected region (e.g., AD-1 in Amsterdam).
• Scroll down.

• Click Change image under the Image and shape section.
• Select the Custom Images tab.

• Select My images.
• Select Custom images
• Choose your imported image (e.g., 610-000612-025_SW_VMware_CipherTrust_Manager_v2.19.0_RevA)
• Click Select Image,

• Select a shape (e.g., VM.Standard.E5.Flex) and configure OCPU and memory.

> Check the minimum spec requirements from Thales for CCKM (usually at least 2 OCPU / 8 GB RAM).

• Select your previously created VCN and subnet
• Use a Public Subnet if you want direct SSH/web access (or private subnet with Bastion if following best practices)

• Assign the IP address automatically.
• Enable Assign a public IPv4 address/
• Scroll down.

• Upload a .pub file
• This key will be used to access the VM via SSH.
• Scroll down.
• Click on Create

The Instance state will be PROVISIONING.

• 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, I am using an application called Royal TSX, where I configured the SSH session.

• In the credentials tab (of the Royal TSX session), I have specified that the username should be ksadmin.

• Make sure you also select the corresponding Private Key.

• 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 can not 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 have started; this can take up to 5 minutes.

• When all services are started, you get a message that all services are okay.

• Log in using:
• Username: admin
• Password: admin

• After the first login, 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 diagram below illustrates the current state of our deployment so far.

STEP 03 - Do the initial configuration on the first Thales CipherTrust Cloud Key Manager -CCKM- Appliance

Now that the first CCKM appliance is deployed and accessible, it's 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
• Select Add NTP Server

• Enter a reliable NTP server's hostname or IP address (e.g., 169.254.169.254 (Oracle's public NTP Server IP) or your organization's internal NTP source).
• Click Add NTP Server

• Notice the message that the NTP Server was added successfully.
• Click on Close.

• Verify that the time is synchronized correctly.

• Go to: Admin Settings → Licensing.
• Click Start CiperTrust Platform Evaluation.

• Scroll down.

 

• Click Start CiperTrust Platform Evaluation.

• It will take a few minutes before the license is activated.

• Review the activated license.

STEP 04 - Deploy the second Thales CipherTrust Cloud Key Manager -CCKM- Appliance and do the initial configuration on the CCKM

Follow the steps provided in steps 02 and 03 to deploy the second CCKM in the ASH region.

• Make sure the second CCKM is deployed and RUNNING.

• Also, test the connection between SSH and the second CCKM.

• Also, test the connection between WEB and the second CCKM.

The diagram below illustrates the current state of our deployment so far.

STEP 05 - Review the connection between the Thales CipherTrust Cloud Key Manager -CCKM- Appliances with RPC

To prepare for high availability and clustering between the two Thales CipherTrust Cloud Key Manager (CCKM) appliances, it's essential to ensure proper connectivity between the regions in which they are deployed.

In our setup, a Remote Peering Connection (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 (e.g., 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'll address in one of the following sections.

STEP 06 - DNS Configuration

• Official OCI documentation: [Creating a Private DNS Zone]

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 CipherTrust Cloud Key Manager (CCKM) appliances as CTM, short for Cyber Trust Manager.

While using a custom internal DNS server is possible, we are leveraging Oracle Cloud Infrastructure (OCI) DNS Services with a private DNS zone in this deployment. This allows us to assign meaningful, Fully Qualified Domain Names (FQDNs) to the CTMs and ensures they can communicate across regions without relying on static IPs.

• Private DNS Zone Name: oci-thales.lab
• Scope: Private
• Associated VCNs: Both AMS and ASH VCNs (to allow cross-region name resolution)

We've created two A records within the oci-thales.lab zone, pointing to the private IPs of each CTM appliance:

Hostname	FQDN	Points to
ctm1	ctm1.oci-thales.lab	Private IP of CTM in AMS
ctm2	ctm2.oci-thales.lab	Private IP of CTM in ASH

Using FQDNs makes managing certificates and cluster configurations easier and avoids coupling the configuration to fixed IPs.

• Make sure you are in the AMS region.
• In the OCI Console, open the navigation menu.
• Go to: Home → Virtual Cloud Networks

• Click on the VCN.

• Click on the DNS Resolver (for that VCN).

 

• Click on the Default Private View (for that DNS Resolver and VCN).

• Click Create Zone

• Choose:
  • Zone Name: oci-thales.lab
  • Compartment: Select the correct one
• Click Create

• Click on the created zone.

• Click on Manage Records

• Click on Add record

• Create A Record for ctm1:
  • Record Type: A.
  • Name: ctm1.
  • TTL: Leave default (e.g., 300).
• Scroll down.

• RDATA (IP Address): Enter private IP of CTM in AMS
• Click Save Changes

• Repeat to create a second A record for ctm2:
  • Record Type: A.
  • Name: ctm2.
  • TTL: Leave default (e.g., 300).
• Scroll down.

• RDATA (IP Address): Enter private IP of CTM in ASH
• Click Save Changes

• Click on Publish Changes.

• Repeat the same steps you did 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 CTM instances and run 'ping ctm2.oci-thales.lab` from the first CTM (running in AMS). The FQDN will be resolved to the correct IP address, and when the RPC + Routing + security Lists are correctly configured, the ping is successful.

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

STEP 07 - Configure the first Thales CipherTrust Cloud Key Manager -CCKM- Appliance as a Certificate Authority -CA-

• Official Thales documentation for CCKM version 2.19: [Certificate Authority]

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.

• Make sure you are on the AMS CTM.
• Click on the CA Menu
• Select Local
• Review the local automatically generated CA (CipherTrust Manager Root CA) we will use to create and sign CSRs.

The diagram below illustrates the current state of our deployment so far.

‌

STEP 08 - Create a CSR for both Thales CipherTrust Cloud Key Manager -CCKM- Appliances and sign them by the CA

• Official Thales documentation: [Creating a CSR on the Console]‌‌
• Official Thales documentation: [Signing a Certificate Request with a Local CA]
• Official Thales documentation for CCKM version 2.19: [Web Interface Certificate Renewal]

With both Cyber Trust Manager (CTM) appliances deployed and DNS configured, it's time to enable secure, certificate-based communication between them. Since the AMS CTM and ASH are configured as the Certificate Authority (CA), we will use the AMS CTM to generate and sign certificates for both appliances.

• The high-level steps will be:
• Generate Certificate Signing Requests (CSRs) for CTMs (AMS and ASH) on the AMS CTM.
• Use the AMS CTM CA to sign both CSRs
• Install the signed certificate on each CTM

This ensures all CTM-to-CTM communication is trusted and encrypted, a critical requirement for cluster formation and secure API access.

Perform these steps only on the AMS CTM.

• Log in to the CTM AMS web interface
• Navigate to: CA → CSR Generator

• Fill out the CSR form:
• Select: Generic CSR.
  • Common Name (CN): Use the CTM’s FQDN (e.g., ctm1.oci-thales.lab)
• Display Name: Use a name (e.g., CTM1 (AMS))
• Algorithm: ECDSA
• Size: 256
  • Subject Alternative Name (SAN): Also include the FQDN here (e.g., ctm1.oci-thales.lab)
• Click Generate CSR and download Private Key
• Note that the Private Key will be automatically downloaded.
• Scroll down.

• Click on Download CSR to download and save the generated .csr file.

• Repeat the same steps (still on the CTM AMS CA).

• Fill out the CSR form:
• Select: Generic CSR.
  • Common Name (CN): Use the CTM’s FQDN (e.g., ctm2.oci-thales.lab)
• Display Name: Use a name (e.g., CTM2 (AMS))
• Algorithm: ECDSA
• Size: 256
  • Subject Alternative Name (SAN): Also include the FQDN here (e.g., ctm2.oci-thales.lab)
• Click Generate CSR and download Private Key
• Note that the Private Key will be automatically downloaded.
• Scroll down.

• Click on 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 that I have used.

Navigate to: CA → Local. Select the CA.

Click Upload CSR.

• Display Name: Use the CTM’s FQDN (e.g., ctm1.oci-thales.lab)
• Copy the content of the generated CSR in the CSR field.

• Certificate Purpose: Server.
• Click Issue Certificate.

• Click on the three dots at the end of the signed certificate entry.
• Click on download to download the signed certificate for CTM1.

• Repeat the same steps (still on the CTM AMS CA).

• Display Name: Use the CTM’s FQDN (e.g., ctm2.oci-thales.lab)
• Copy the content of the generated CSR in the CSR field.

• Certificate Purpose: Server.
• Click Issue Certificate.

• Click on the three dots at the end of the signed certificate entry.
• Click on 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 CTM 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 CTM, acting as the Certificate Authority (CA).

• Navigate to: CA → Local.
• Click on the three dots at the end of the CTM AMS CA.
• Click on download to download the Root CA certificate of CTM 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 CTM 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 CTMs.
• 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 CTM appliance.
• Let's start with the first CTM1 running in AMS.

• Navigate to: Admin Settings → Interfaces.
• Click on the three dots of the web interface.
• Select Renewal Certificate Options.

• Select Upload/Generate.
• Click on Ok.

• Upload the Full chain cert for CTM1 using the PEM format.
• Click on Upload Certificate.

• Click on the three dots of the web interface (again).
• Select Renewal Certificate Options (again).

• Select Apply.
• Click on Ok.

• Click on Apply.

• Click on Services Page.

• Click on System Restart.

• Click on Restart Services to restart the server + 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 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 I will show you how I tested the new CTM certificates signed by the CTM AMS CA.

• Open the Google Chrome browser settings.
• Navigate to the Privacy and Security tab.
• Click on Security.

• Click on Manage certificates.

• Click on Local certificates.
• In the custom section, click on Installed by you.

• I have already imported the full chain certs + Root cert on my local OS.
• This is also where you can import the certificates; this button will bring you to the OS-level certificate settings.

• Because I have not configured the DNS server on the internet, I am updating my local /etc/hosts file with the manual host entries to test the certificates from my local machine using the FQDN.

• Browse to the CTM1 FQDN using Google Chrome.
• Click on the security settings.

• Click on Connection is secure.

• Click on Certificate is valid.

• Review the Issued to details.

STEP 09 - Configure Thales CipherTrust Cloud Key Manager -CCKM- Appliance Clustering

• Official Thales documentation for CCKM version 2.19: [Creating a New Cluster Configuration]

• Clustering Thales CipherTrust Cloud Key Manager (CTM) 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) CTM appliance (in our case, the CTM running in AMS).
• Use this appliance's interface to create the cluster and add other CTM appliances as cluster nodes.

• Navigate to: Admin Settings → Cluster.
• Click on Manage Cluster.

• Click on Add cluster.

• Click on Next.

• Type in the hostname of the AMS CTM (which is the CTM1 in AMS with private IP 10.222.10.111).
• I do not intend to use (or create) a cluster over the internet using the public IP, so I am using the private IP address in both fields.
• Click on Add Cluster.

• Notice that this machine has created a new cluster and is part of its cluster.

• On the same AMS CTM1 click on Manage Cluster (again).
• Select Add Node (to add the ASH CTM2).

• Specify the ASH CTM IP address as the nod to add to the cluster.
• I could have used the DNS name here, but I did not.
• Click on 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.

• Confirm the join by clicking on Join.

• Some more cluster configuration activity will happen in the background.

• Confirm the Success message by clicking on Finish!.

• If the newly opened browser window/tab is still open, you can close it manually.

• On the AMS CTM1 also confirm by clicking on Finished.

• 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 CTM Cluster configuration is done correctly and is healthy, you can check CTM1 and CTM2.

From CTM1:

• Navigate to: Admin Settings → 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).

From CTM2:

• Navigate to: Admin Settings → 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 diagram below illustrates the current state of our deployment so far.

Conclusion

In this tutorial, you successfully set up two Thales CipherTrust Cloud Key Manager (CCKM) Appliances within Oracle Cloud Infrastructure (OCI), established a secure cluster between them, and configured one appliance as the Certificate Authority (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 Oracle Hold Your Own Key (HYOK) using CipherTrust Manager without the API Gateway option, follow this guide: “Set up Oracle Hold Your Own Key (HYOK) with the CipherTrust Manager (without API Gateway option).”

If you want to implement Oracle Hold Your Own Key (HYOK) using CipherTrust Manager with the API Gateway option, follow this guide: “Set up Oracle Hold Your Own Key (HYOK) with the CipherTrust Manager (with API Gateway option).”