CipherTrust Manager clustering errors during installation and configuration most commonly occur when the appliance cannot resolve node hostnames because the hostnames are not yet present in the appliance’s internal DNS Hosts table. The error codes NCERRInternalServerConnectFailed (Code 8) appear on both initial cluster creation and secondary node addition. This is distinct from an external DNS problem: even with external DNS correctly configured, the CipherTrust Manager appliance uses its own internal hostname resolution for cluster operations. The recommended action: add all cluster node hostnames to the Admin Settings > DNS Hosts table on each appliance before attempting cluster creation or node addition.
Quick Answer: How Do You Fix the CipherTrust Manager Clustering Error?
Navigate to Admin Settings > DNS Hosts on each CipherTrust Manager appliance and add the hostname-to-IP mapping for every node in the cluster (including the appliance’s own hostname). Then retry cluster creation or node addition using hostnames. After the cluster is successfully configured and verified, you can remove the DNS Hosts entries. The full step-by-step procedure is in the Solution section below. For CipherTrust Manager deployment guidance and key management integration, see Encryption Consulting HSM Services and key management overview.
Error Messages
- A generic connection error occurred while creating the cluster. This type of error typically occurs when the host is invalid. Please retry using a valid IP or hostname. Code 8: NCERRInternalServerConnectFailed
- Failed self-connection check. This type of error typically occurs when the host is invalid. Please retry using a valid IP or hostname. Code 8: NCERRInternalServerConnectFailed
Description: The Scenario
Consider a deployment with 4 CipherTrust Manager nodes (cm01.ec.com, cm02.ec.com, cm03.ec.com, cm04.ec.com) to be added to a cluster. The standard procedure is to select one node as the primary, create the cluster from it, and then add all remaining nodes to that cluster using either the hostname or the IP address of each node.
Hostnames are recommended over IP addresses for cluster configuration from a networking standpoint: hostnames remain stable through IP changes (infrastructure migrations, DHCP renewals) and are easier to manage at scale. However, the errors above are encountered when hostnames are used during cluster creation, even in environments where external DNS is correctly configured.
Root Cause
The CipherTrust Manager appliance cannot resolve the hostname of the node being referenced during cluster operations. CipherTrust Manager uses its own internal network stack for cluster communication and does not rely solely on the external DNS resolver configured for the host network. If the hostnames of the cluster nodes are not present in the appliance’s local DNS Hosts table (Admin Settings > DNS Hosts), the appliance cannot resolve them, producing the NCERRInternalServerConnectFailed error regardless of whether external DNS is correctly configured.
This is a common source of confusion: administrators verify external DNS is working, confirm the hostname resolves from a workstation, and still encounter the error because the appliance’s internal hostname resolution has not been configured.
Solution: Step-by-Step Resolution
This example uses cm01.ec.com as the primary node from which the cluster is created and cm02.ec.com, cm03.ec.com, and cm04.ec.com as secondary nodes to be added.
-
On cm01.ec.com, navigate to Admin Settings > DNS Hosts.
-
Add all 4 CipherTrust Manager node hostnames with their corresponding IP addresses to the DNS Hosts table on cm01.ec.com. Include cm01.ec.com’s own hostname in the table.
-
Navigate to Clustering on cm01.ec.com and create the cluster using cm01.ec.com’s own hostname as the primary node address.
-
Before adding each secondary node from cm01.ec.com, go to each secondary node (cm02.ec.com, cm03.ec.com, cm04.ec.com) and add two DNS Hosts entries to each: the primary node’s hostname (cm01.ec.com) and the secondary node’s own hostname. For example, on cm02.ec.com, add entries for both cm01.ec.com and cm02.ec.com. This ensures both nodes can resolve each other’s hostnames for the two-way cluster communication required during node addition.
-
Once all DNS Hosts entries are in place on the primary and secondary nodes, return to cm01.ec.com and add each secondary node using its hostname. Complete node testing to confirm the cluster is operational.
-
After the cluster is created, all nodes have been added, and cluster function has been verified, remove the DNS Hosts entries from all CipherTrust Manager appliances and confirm that clustering continues to function correctly with external DNS resolving the hostnames.
Failure-Mode Guidance
- Error persists after adding DNS Hosts entries: verify the entries are saved correctly and the hostname-to-IP mapping is accurate. A typo in the hostname or IP address produces the same error as a missing entry. Confirm by navigating back to Admin Settings > DNS Hosts and reviewing each entry before retrying cluster creation.
- Secondary node addition fails but cluster creation succeeded: the secondary node’s DNS Hosts table does not include the primary node’s hostname and its own hostname. Both must be added to the secondary node before it can be added to the cluster from the primary.
- Cluster fails after removing DNS Hosts entries: external DNS is not resolving the hostnames correctly from the appliance’s network perspective. Either restore the DNS Hosts entries as a workaround, or investigate why the external DNS resolver is not reachable or not returning the correct records from the appliance’s network stack.
- Partial cluster state after a failed node addition: if a node addition fails midway, do not retry without first removing the incomplete node entry from the cluster configuration. Adding a partially joined node a second time can leave the cluster in a more difficult state to recover from.
- NCERRInternalServerConnectFailed on a previously working cluster: if this error appears on a cluster that was previously operational, check whether the DNS Hosts entries were removed prematurely (before external DNS was verified), whether IP addresses of any nodes changed (breaking external DNS records), and whether network connectivity between nodes is still functioning on the required ports.
CipherTrust Manager in the Key Management Context
CipherTrust Manager is a key management platform that centralizes cryptographic key lifecycle management: key generation, storage, distribution, rotation, revocation, and access control policy enforcement across enterprise environments. Clustering CipherTrust Manager nodes provides high availability for key management operations: if one node becomes unavailable, other nodes in the cluster continue serving key requests without interruption.
For organizations using CipherTrust Manager, it integrates with HSMs for hardware-backed key protection, with PKI infrastructure for certificate authority key management, and with enterprise key management workflows covering the full key lifecycle. A correctly configured cluster is the foundation for highly available, auditable key management operations. See our post on 10 Enterprise Encryption Key Management Best Practices for broader key management guidance.
Conclusion
The CipherTrust Manager NCERRInternalServerConnectFailed (Code 8) clustering error is almost always caused by missing hostname entries in the appliance’s internal DNS Hosts table rather than an external DNS failure. The resolution is straightforward: add all node hostnames to the DNS Hosts table on each appliance involved in the cluster operation, create or join the cluster using hostnames, verify cluster function, and then clean up the DNS Hosts entries. Following the correct order for adding nodes (adding both the primary and secondary node’s own hostname to each secondary node before initiating the node addition from the primary) prevents the most common secondary node addition failures. For ongoing CipherTrust Manager configuration, HSM integration, and key management support, see Encryption Consulting’s services.
Frequently Asked Questions
What causes the CipherTrust Manager NCERRInternalServerConnectFailed clustering error?
The appliance cannot resolve the hostname of the node being referenced during cluster creation or node addition. Even with external DNS correctly configured, CipherTrust Manager uses its own internal hostname resolution. Adding node hostnames to Admin Settings > DNS Hosts on each appliance resolves the issue.
Should I use IP addresses or hostnames for CipherTrust Manager clustering?
Hostnames are recommended: they remain stable through IP address changes and are easier to manage at scale. However, hostnames must be added to each appliance’s DNS Hosts table before cluster operations, since CipherTrust Manager uses its own internal resolution rather than relying solely on external DNS.
Can I remove the DNS Hosts entries after the cluster is configured?
Yes. Once the cluster is successfully created, all nodes have been added, and cluster function is verified, DNS Hosts entries can be removed from each appliance. Verify that cluster operations continue correctly after removal, confirming external DNS is resolving the hostnames from the appliance’s network.
What is the correct order for adding nodes to a CipherTrust Manager cluster?
1. Select primary node and add all node hostnames to its DNS Hosts table; create the cluster using the primary node’s own hostname. 2. On each secondary node, add the primary node’s hostname and the secondary node’s own hostname to the DNS Hosts table. 3. From the primary node, add each secondary node by hostname. 4. Verify cluster function, then remove DNS Hosts entries from all appliances.
What happens if CipherTrust Manager clustering fails midway?
Verify DNS Hosts entries on all involved appliances; check appliance logs for specific error codes; confirm network connectivity between nodes; and if the cluster was partially created, remove incomplete node entries before retrying. Do not attempt to add a partially joined node without first removing it cleanly from the cluster configuration.
Why does CipherTrust Manager need its own DNS Hosts table if external DNS is configured?
CipherTrust Manager uses its own internal network stack for cluster communication, which may not route through the same DNS resolver as the external network. Adding hostnames to the DNS Hosts table ensures resolution for cluster operations is handled locally, independent of external DNS availability, which is especially important during initial setup or in air-gapped environments.
