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-issuerClusterIssuer exists. - You have permission to create secrets in the cert-manager namespace.
Perform the following steps:
Custom CA certificates are available.
a. Users already have existing CA certificates.
To retrieve custom CA certificate and key from
custom-ca-secretsecret, 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.
Copy the CA certificate to the jumpbox.
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
- 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
- To patch the
eclipse-issuerClusterIssuer 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.
- After patching the ClusterIssuer, existing certificates must be re-issued using the new CA. Use one of the following approaches:
Approach 1: Trigger renewal via cmctl (Recommended)
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.
Feedback
Was this page helpful?