Providing the root CA certificate

All deployments of the Cloud Pak by default have a self-signed certificate that is signed by a common root CA certificate. You can use this root CA that is generated by the operator, or provide your own root CA signer certificate.

About this task

If the root_ca_secret secret does not have a value or does not exist, the operator generates the secret with a self-signed root CA signer certificate. If your policy requires certificates that are signed by a recognized certificate authority, you can provide your own root CA.

To use your own root CA certificate, obtain or prepare the CA certificate and create a secret for it before you deploy your custom resource. If you have multiple deployments and you want to use the same root CA, copy the secret and use the same certificates in each deployment in separate namespaces.

Note: The default IBM Automation foundation that is installed by the Cloud Pak also uses a self-signed certificate. You can specify a custom certificate by creating an AutomationUIConfig instance manually to override the default configuration for the Platform UI (or Zen UI). For more information, see AutomationUIConfig.

When you enter your parameter values in the custom resource .yaml file, you provide the name of this secret as the value for the root_ca_secret parameter in the shared configuration section.

Important: If you choose to use self-signed certificates, certain features of the product might not work as expected because of modern browser restrictions that are related to self-signed certificates. A browser blocks any redirect to a site that uses a certificate that is not known by the browser. To fix this issue, you need to import the external route certificate or CA into your browser.

If you want to use your own root CA certificate, use the following steps to add it to the operator.

Procedure

  1. Obtain or generate a rootca.key (private key) file and a rootca.crt (certificate) file.

    The following example shows how to generate a root CA by using OpenSSL.

    openssl req -nodes -x509 -newkey rsa:4096 -keyout rootca.key -out rootca.crt \
-days 730 -extensions v3_req -config icp4a-ca.cnf

    The command produces the private key file rootca.key and the certificate rootca.crt. The command also needs a configuration file icp4a-ca.cnf. The following lines show an example of a .cnf file.

    [ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req

[ dn ]
CN=Automation
O=IBM

[ v3_req ]
basicConstraints=critical,CA:true,pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
extendedKeyUsage = clientAuth, serverAuth
authorityKeyIdentifier=keyid,issuer
subjectKeyIdentifier=hash

    You can change the [ dn ] section with the names that you want.

  2. Create a TLS secret for the root_ca_secret parameter by using your signer certificate.

    The following example command creates a TLS secret for your root CA.

    kubectl create secret tls root-ca –-key=rootca.key –-cert=rootca.crt

    For more information, see TLS secrets.

  3. Update the parameter value for the operator to use your secret. 
    shared_configuration:
    root_ca_secret: 'root-ca'

What to do next

When your certificates expire, you must take the following actions to renew the secrets:

  1. Update or re-create the secret with the updated certificate.
  2. Restart the corresponding pods that are associated with the secret.