Replacing the default Certificate Authority (CA) with a Custom CA in PPC

In a PPC deployment, Envoy and other internal components rely on a CA to establish trusted TLS communication.

By default, PPC uses an internally generated CA. PPC supports replacing the default CA with a custom CA that can be preserved and reused across cluster restore or migration.

Prerequisites

Before you begin, ensure that:

  • You have access to the PPC Kubernetes cluster (kubectl configured).
  • Openssl is installed.
  • Cert-manager is installed.
  • The eclipse-issuer ClusterIssuer exists.
  • You have permission to create secrets in the cert-manager namespace.

Perform the following steps:

  1. Custom CA certificates are available.

    a. Users already have existing CA certificates.

    To retrieve custom CA certificate and key from custom-ca-secret secret, run the following commands:

     ```bash
     kubectl -n cert-manager get secret custom-ca-secret   -o jsonpath='{.data.tls\.crt}' | base64 -d > <your-ca>.crt
    
     kubectl -n cert-manager get secret custom-ca-secret   -o jsonpath='{.data.tls\.key}' | base64 -d > <your-ca>.key
     ```
    

    b. Users generate custom CA certificates.

    For more information about generating New Certificate and Key with OpenSSL, refer to Openssl documentation.

  2. Copy the CA certificate to the jumpbox.

  3. To create a TLS secret containing the CA certificate and key, navigate to the folder where certificates are available and run the following command:

kubectl create secret tls custom-ca-secret \
  --cert=<your-ca>.crt \
  --key=<your-ca>.key \
  -n cert-manager
  1. To verify the secret was created, run the following command:
kubectl get secret custom-ca-secret -n cert-manager
NAME               TYPE                DATA   AGE
custom-ca-secret   kubernetes.io/tls   2      5s
  1. To patch the eclipse-issuer ClusterIssuer to point to the new CA secret, run the following command:
kubectl patch clusterissuer eclipse-issuer \
  --type='json' \
  -p='[{"op":"replace","path":"/spec/ca/secretName","value":"custom-ca-secret"}]'

Note: This changes cert-manager to issue all new certificates using the custom CA.

  1. After patching the ClusterIssuer, existing certificates must be re-issued using the new CA. Use one of the following approaches:

cmctl is the official cert-manager CLI and provides the most reliable way to trigger certificate renewal. The script below checks if cmctl is installed and downloads it automatically if not.

#!/bin/bash

# Install cmctl if not present
if ! command -v cmctl &>/dev/null; then
  echo "cmctl not found, downloading..."
  curl -L https://github.com/cert-manager/cmctl/releases/latest/download/cmctl_linux_amd64 \
    -o /usr/local/bin/cmctl
  chmod +x /usr/local/bin/cmctl
  echo "cmctl installed successfully"
fi

# Renew all certificates using eclipse-issuer
kubectl get certificates --all-namespaces -o json | \
jq -r '.items[] | select(.spec.issuerRef.name=="eclipse-issuer") | "\(.metadata.namespace) \(.metadata.name)"' | \
while read -r ns cert_name; do
  echo "Renewing certificate: $cert_name in namespace: $ns"
  cmctl renew "$cert_name" -n "$ns"
done

Approach 2: Trigger renewal via kubectl (status patch)

Use this approach if cmctl cannot be installed. Requires kubectl 1.24+.

#!/bin/bash

kubectl get certificates --all-namespaces -o json | \
jq -r '.items[] | select(.spec.issuerRef.name=="eclipse-issuer") | "\(.metadata.namespace) \(.metadata.name)"' | \
while read -r ns cert_name; do
  echo "Triggering renewal for certificate: $cert_name in namespace: $ns"
  kubectl patch certificate "$cert_name" -n "$ns" \
    --subresource=status \
    --type=merge \
    -p '{
      "status": {
        "conditions": [{
          "type": "Issuing",
          "status": "True",
          "reason": "ManuallyTriggered",
          "message": "Certificate renewal manually triggered",
          "lastTransitionTime": "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"
        }]
      }
    }'
done

Note: Due to cert-manager’s reconcile loop, some certificates may not renew on the first attempt. Re-run the script if any certificates remain unrenewed.


Last modified : April 06, 2026