GPCC agent fails mTLS authentication on Standby Coordinator host due to certificate/key mismatch

Products

• VMware Tanzu Data
• VMware Tanzu Greenplum

Issue/Introduction

In Greenplum Command Center (GPCC) 7.x running on Greenplum 7.x, the GPCC UI drops host telemetry for the Standby Coordinator host across the Cluster Realtime Status, Host Metrics, and Storage Usage views.

During GPCC startup, installation, or certificate rotation, you may observe the following errors in installer logs or console output:

RunCommandOnEachHost failed on host: <standby-host>, output: mv: cannot stat '/usr/local/greenplum-cc-<version>/conf/certs/gpcc.key.new': No such file or directory
Command: mv -f /usr/local/greenplum-cc-<version>/conf/certs/gpcc.crt.new /usr/local/greenplum-cc-<version>/conf/certs/gpcc.crt && mv -f /usr/local/greenplum-cc-<version>/conf/certs/gpcc.key.new /usr/local/greenplum-cc-<version>/conf/certs/gpcc.key
gRPC mTLS: swap coordinator cert on standby <standby-host>: mv: cannot stat '/usr/local/greenplum-cc-<version>/conf/certs/gpcc.key.new': No such file or directory

Additionally, the agent.log on the affected Standby Coordinator host reports mTLS authentication errors:

private key does not match public key

Environment

• Product: Greenplum Command Center (GPCC) 7.x (e.g., GPCC 7.7.0)
• Database: Greenplum Database 7.x (e.g., Greenplum 7.8.4)
• Configuration: GPCC auto-generated gRPC mTLS certificates enabled

Cause

During GPCC startup and installation, an internal remote execution command uses an unquoted shell command string to swap auto-generated gRPC mTLS certificates on the Standby Coordinator node.

The public certificate (gpcc.crt.new) is moved to gpcc.crt successfully, but the secondary command to move the matching private key (gpcc.key.new) fails to execute (No such file or directory). This leaves the Standby Coordinator host with an updated public certificate paired with an old or missing private key.

Because the local certificate and key pair do not match, the ccagent on the standby host fails mTLS authentication with the primary coordinator and enters a continuous restart loop, resulting in a loss of host telemetry in the GPCC UI.

Resolution

This issue will be resolved in future maintenance releases of Greenplum Command Center (GPCC) 7.x. Please Subscribe to this article to receive automated notifications when updates and target fix versions become available.

Additional Information

Workaround 1: Manually Sync Certificate and Key Pair

To restore agent communication immediately without restarting installation:

1. Log into the Primary Coordinator host as the gpadmin user.

2. Manually copy the valid certificate and key files from the primary coordinator to the standby coordinator host:

scp $GPCC_HOME/conf/certs/gpcc.crt <standby_hostname>:$GPCC_HOME/conf/certs/gpcc.crt
scp $GPCC_HOME/conf/certs/gpcc.key <standby_hostname>:$GPCC_HOME/conf/certs/gpcc.key

3. Restart GPCC

gpcc stop
gpcc start

Workaround 2: Use Custom PKI Certificates

This issue specifically impacts auto-generated mTLS setups. Configuring GPCC to use custom SSL/TLS certificates (custom PKI) bypasses this internal certificate swap script path entirely.