Updating custom hostname and TLS secret by using a configmap

You can change the custom hostname and certificates for the cp-console route by running a script.

Note: These instructions are for changing only the cp-console route hostname and certificates.

Before you begin

Keep your new hostname and certificates ready.

Create the custom hostname. If you modify the default Red Hat® OpenShift® Container Platform domain, ensure that the new hostname can resolve to the Red Hat OpenShift router from inside and outside the Red Hat OpenShift cluster.
If you are updating the TLS secret, provide new certificates in an unencrypted PEM format. Place the certificates in the ${installer_scripts}/cp3pt0-deployment folder. For more information, see Apply the updates to your cluster by running a script.
Note: Whenever the certificates change or expire, you must provide new certificates and run the script again to create a secret by using the new certificates.
- ca.crt: Contains the intermediate CA signer certificates and the CA root signer certificate. The file must start with the intermediate CA certificates in order that leads to the root CA.
- tls.crt: Contains only the route server certificate.
  
  Note: The route server certificate passes the TLS verification for the route hostname.
- tls.key: Contains the private key of the route server certificate.
  
  See the following example of PEM encoding that uses header and footer lines for each certificate and private key.
```
-----BEGIN CERTIFICATE-----
(encoded set of characters)
-----END CERTIFICATE-----

-----BEGIN PRIVATE KEY-----
(encoded set of characters)
-----END PRIVATE KEY-----
```

Procedure

Complete the following steps to change the custom hostname and certificates of the cp-console route.

Create a cs-onprem-tenant-config.yaml file with the following configmap definition. In the data section, provide your custom hostname. If you are providing new certificates to update the TLS secret, do not change the name of the custom_host_certificate_secret secret in the configmap.

 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: cs-onprem-tenant-config
   namespace: <your-foundational-services-namespace>
 labels:
   cs_onprem_tenant_config: "true"
 data:
   ##comment out or remove this setting if not changing the hostname
   custom_hostname: <hostname>
   ##comment out or remove this setting if not changing the certificates
   custom_host_certificate_secret: custom-tls-secret

Create the cs-onprem-tenant-config configmap.

oc apply -f cs-onprem-tenant-config.yaml -n <your-foundational-services-namespace>

Apply the updates to your cluster by running a script, which is available with the CASE bundle. The CASE bundle is used for installing foundational services in a disconnected environment. For more information about installing the ibm-pak plug-in and downloading the bundle, see Installing your IBM Cloud Pak by mirroring Cloud Pak images to a private container registry (with ibm-pak plug-in).
1. Download the cp3pt0-deployment folder, from the installer_scripts folder in the CASE bundle. For information on downloading the scripts, see Downloading scripts for additional configuration from specific version CASE bundle.
2. Go to your downloaded installer_scripts directory.
```
 cd ${installer_scripts}/cp3pt0-deployment
```
3. If you are providing new certificates for TLS secret, place the certificates in the cp3pt0-deployment directory. When you run the script, it creates the TLS secret by using the certificate files that you provide.
4. If your cluster topology has a separate namespace for all operators, identify that namespace and set it as the default namespace. You must also update the script. For more information about operatorNamespace, see Parameters in the CommonService CR.
  1. Locate the operatorNamespace in the common-service CR.
```
 oc describe commonservice common-service -n <your-foundational-services-namespace> | grep operatorNamespace
```
  2. Set the operatorNamespace value as the default namespace.
```
 oc project <operatorNamespace-value>
```
  3. Set the following environmental variables:
    - $csNamespace - the control namespace where ibm-iam-operator is deployed.
    - $map_to_common_service_namespace - the data namespace where operands are created.
5. Run the script. If your cluster topology has a separate namespace for all operators, run the script from that namespace.
```
 ./cs-onprem-tenant-config.sh
```
  If you see the following error, it means that you did not provide the new certificate files for TLS secret in the cp3pt0-deployment directory. To resolve the issue, place the certificate files and run the script again.
```
 tls.key is not present in current directory, pls keep tls.key, tls.crt and ca.crt files in current directory
```

The script completes the following tasks:

Identifies your topology type: simple topology or separation of data (SOD) topology.
Uses namespaces from the common_service_maps configmap that is in the kube-public namespace. The common_service_maps` configmap has all the namespaces in a tenant.
Creates a TLS secret if you provided new certificate files.
If your cluster topology has a separate namespace for all operators, the script runs the iam-custom-hostname job in that namespace.
Updates the custom hostname in all applicable identity management (IM) components.
Restarts the pods with the following labels:
- app=platform-auth-service
- app=platform-identity-provider
- name=ibm-zen-operator
- component=usermgmt

Result

After you run the script, the cp-console route is updated with the new hostname. You can also see the new certificates, if applicable, in your browser when you access the cp-console URL.

Restore SAML

After you change the certificate, the Security Assertion Markup Language (SAML) connection breaks. You must update the SAML metadata with the new certificate information to restore the connection. For more information, see Identity and access management migration.

Reverting the updates

If you need to revert to the previous hostname and certificate, repeat the steps in Procedure by using the previous hostname.