When replacing the default ingress certificate in IBM Cloud Pak for Integration (CP4I) v2021.2, one critical requirement is that the private key associated with the new certificate must be unencrypted.
OpenShift’s Ingress Controller (which CP4I uses) requires an unencrypted private key to properly load and use the custom TLS certificate.
Encrypted private keys would require manual decryption each time the ingress controller starts, which is not supported for automation.
The custom certificate and its key are stored in a Kubernetes secret, which already provides encryption at rest, making additional encryption unnecessary.
Why Option A (Unencrypted Private Key) is Correct:To apply a new custom certificate for ingress, the process typically involves:
sh
CopyEdit
oc create secret tls custom-ingress-cert \
--cert=custom.crt \
--key=custom.key -n openshift-ingress
B. The certificate file must have only a single certificate. → ❌ Incorrect
The certificate file can contain a certificate chain, including intermediate and root certificates, to ensure proper validation by clients.
It is not limited to a single certificate.
C. The new certificate private key must be encrypted. → ❌ Incorrect
If the private key is encrypted, OpenShift cannot automatically use it without requiring a decryption passphrase, which is not supported for automated deployments.
D. The new certificate must be a self-signed certificate. → ❌ Incorrect
While self-signed certificates can be used, they are not mandatory.
Administrators typically use certificates from trusted Certificate Authorities (CAs) to avoid browser security warnings.
Explanation of Incorrect Answers:
Replacing the default ingress certificate in OpenShift
IBM Cloud Pak for Integration Security Configuration
OpenShift Ingress TLS Certificate Management
IBM Cloud Pak for Integration (CP4I) v2021.2 Administration References:
Submit