如何延长IBM Cloud Private中cloudctl生成的Helm客户端证书有效期？

Hey there, let's figure out how to extend that short-lived Helm certificate for your IBM Cloud Private (ICP) cluster. The default 3-month validity is definitely a hassle, so here's how you can bump it up to 10 years (or even a super long duration if you really need it):

Option 1: Use cloudctl login with Expiry Parameter (Simplest if Supported) #

Some newer ICP versions let you specify the certificate validity directly when logging in via cloudctl. Just run this command instead of your usual login:

cloudctl login https://icp-console.example.co.id --cert-expiry 3650d

The 3650d flag sets the validity to 10 years. Once you run this, check your ~/.helm/cert.pem again—you should see the updated expiry date.

Option 2: Manually Generate & Replace Certificates (For Older ICP Versions) #

If your ICP version doesn't support the --cert-expiry flag, you'll need to generate a new certificate signed by your cluster's CA and swap it in. Here's the step-by-step:

Step 1: Backup Your Current Helm Configuration #

First, make a backup so you can roll back if something goes wrong:

mv ~/.helm ~/.helm_backup
mkdir ~/.helm

Step 2: Grab Your Cluster's CA Files #

Head over to your ICP master node (you'll need root access here) and copy the cluster CA certificate and key to a temporary directory:

mkdir -p /tmp/helm-certs
cp /opt/ibm-cloud-private/cluster/cfc-certs/ca/ca.pem /opt/ibm-cloud-private/cluster/cfc-certs/ca/ca-key.pem /tmp/helm-certs/

Step 3: Create a Certificate Request (CSR) #

Make an OpenSSL config file (name it helm-cert.conf) to define the certificate's properties:

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = admin

Then generate a private key and CSR:

openssl genrsa -out /tmp/helm-certs/helm-client.key 2048
openssl req -new -key /tmp/helm-certs/helm-client.key -out /tmp/helm-certs/helm-client.csr -subj "/CN=admin" -config /tmp/helm-certs/helm-cert.conf

Step 4: Sign the CSR with the Cluster CA (Set 10-Year Validity) #

Run this command to sign the certificate, setting the validity to 10 years (3650 days). If you want an extra-long duration, use 36500d (≈100 years—OpenSSL doesn't support true "permanent" certificates, so this is the closest):

openssl x509 -req -in /tmp/helm-certs/helm-client.csr -CA /tmp/helm-certs/ca.pem -CAkey /tmp/helm-certs/ca-key.pem -CAcreateserial -out /tmp/helm-certs/helm-client.crt -days 3650 -extensions v3_req -extfile /tmp/helm-certs/helm-cert.conf

Step 5: Replace the Helm Certificates #

Copy the new certificates into your ~/.helm directory:

cp /tmp/helm-certs/helm-client.key ~/.helm/key.pem
cp /tmp/helm-certs/helm-client.crt ~/.helm/cert.pem
cp /tmp/helm-certs/ca.pem ~/.helm/ca.pem

Step 6: Verify the New Expiry Date #

Check that the certificate has the updated validity:

openssl x509 -in ~/.helm/cert.pem -text -noout | grep -A 2 "Validity"

Key Notes to Keep in Mind #

• Security Heads-Up: While a "permanent" certificate is convenient, it's not ideal from a security standpoint. A 10-year validity is a reasonable balance between convenience and security.
• If other users are accessing the cluster via Helm, they'll need to either run the cloudctl login command with the expiry flag or update their local ~/.helm certificates the same way.
• After replacing certificates, test that Helm works correctly by running helm list or any other Helm command to confirm no connection issues.

内容的提问来源于stack exchange，提问作者White Mask Guy