Using a custom TLS certificate for HTTPS connections to the platform

The Cloud Pak for Data installation includes a self-signed TLS certificate that can be used to enable HTTPS connections. By default, this certificate is untrusted by all HTTPS clients. However, you can replace the default certificate with your own TLS certificate.

IBM® Cloud Pak for Data exposes one HTTPS port as the primary access point for the web client and for API requests. On Red Hat® OpenShift®, the port is exposed as an OpenShift route.

Before you begin

Required permissions

To complete this task, you must have one of the following roles:

Red Hat OpenShift cluster administrator
Red Hat OpenShift project administrator on the project where Cloud Pak for Data is installed

To complete this task, you must have your own certificate and private key file that meet the following requirements:

Both files are in PEM format.
The certificate is named cert.crt.
The certificate can be a bundle that contains your server, intermediates, and root certificates concatenated (in the proper order) into one file. The necessary certificates must be enabled as trusted certificates on the clients that connect to the cluster.
The private key is named cert.key.

Procedure

To replace the default TLS certificate with your custom TLS certificate:

Place the cert.crt and cert.key files in the same directory on your local file system.
Change to the directory where the files are located.
Connect to your OpenShift cluster:
```
oc login OpenShift_URL:port
```
Set the context to the project where Cloud Pak for Data is deployed:
```
oc project Project_name
```
Create a secret to store your certificate files:
```
oc create secret generic external-tls-secret --from-file=cert.crt=./cert.crt --from-file=cert.key=./cert.key --dry-run -o yaml | oc apply -f -
```
Important: Do not change the name of the secret. You must use the name external-tls-secret.
Wait for the command to return a message that the secret was created:
```
secret/external-tls-secret created
```
Then, wait another minute to ensure that kubelet has sufficient time to detect where the secret will be used and to mount the secret to the ibm-nginx pods.

Reload ibm-nginx:

for i in `oc get pods | grep ibm-nginx |  cut -f1 -d\ `; do oc exec ${i} -- /scripts/reload.sh; done

The output should be similar to the following output:

reloading nginx conf
Setting up ssl certificate files...
 Custom ssl certificate files were found. Processing them... 
lrwxrwxrwx. 1 1000321000 root 50 DATE-AND-TIME /nginx_data/defaults.d/external-server.conf -> /nginx_data/defaults.d/external-server.active.conf
nginx: the configuration file /usr/local/openresty/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/openresty/nginx/conf/nginx.conf test is successful
TIMESTAMP [notice] 76#76: signal process started
reloading nginx conf
Setting up ssl certificate files...
Custom ssl certificate files were found. Processing them...
lrwxrwxrwx. 1 1000321000 root 50 DATE-AND-TIME /nginx_data/defaults.d/external-server.conf -> /nginx_data/defaults.d/external-server.active.conf
nginx: the configuration file /usr/local/openresty/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/openresty/nginx/conf/nginx.conf test is successful
TIMESTAMP [notice] 76#76: signal process started
reloading nginx conf
Setting up ssl certificate files...
Custom ssl certificate files were found. Processing them...
lrwxrwxrwx. 1 1000321000 root 50 DATE-AND-TIME /nginx_data/defaults.d/external-server.conf -> /nginx_data/defaults.d/external-server.active.conf
nginx: the configuration file /usr/local/openresty/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/openresty/nginx/conf/nginx.conf test is successful
TIMESTAMP [notice] 76#76: signal process started

Verify that the certificate files were found.