Configuring a custom certificate and hostname for the platform UI

WebSphere Automation uses the Cloud Pak foundational services platform UI as an underlying service for its user interface. If you use custom certificate for the platform UI, set the platform UI route with a custom hostname in the WebSphereAutomation instance custom resource when you create an instance of WebSphere Automation.

Before you begin

Determine your new hostname or domain
For hostname changes, obtain the new hostname you would like you use. If you modify the domain from 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 Container Platform cluster. The platform UI route is a pass-through route and the Red Hat OpenShift router requires the SNI header for routes of this type. Ensure any network device that is involved in handling the new domain is using the SNI header. This requirement is specific to Red Hat OpenShift. For more information, see Dynamic-Routes-Guide External link icon and How can a user update OpenShift 4 console route External link icon.
Certificate changes
For certificate changes, obtain the necessary certificate files in the proper format. The following files are necessary for the secret that contains the certificates.
  • ca.crt: You must have your full certificate chain if the CA certificate you bring is not self-signed. The full certificate chain includes all the CA certificates that signed each intermediate CA certificate that signed your CA certificate and your root CA. The files must be PEM-encoded files.
  • cert.crt: A Server Certificate (Leaf Certificate). The files must be PEM-encoded files.
  • cert.key: The private key corresponding to the signed certificate. The files must be PEM-encoded files.

Each of the certificates and the key must be in an unencrypted Privacy-Enhanced Mail (PEM) format. The PEM encoding uses header and footer lines like these for each certificate and private key.

-----BEGIN CERTIFICATE-----
(encoded set of characters)
-----END CERTIFICATE-----

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

Creating the wsa-external-tls-secret secret

When using a custom certificate, you must create a secret that is named wsa-external-tls-secret. Use the ca.crt, cert.crt, and cert.key files when you supply files to the secret command. Set the WSA_INSTANCE_NAMESPACE environment variable to the namespace of the WebSphere Automation instance.

export WSA_INSTANCE_NAMESPACE=websphere-automation
oc create secret generic wsa-external-tls-secret --from-file=cert.crt=cert.crt --from-file=cert.key=cert.key --from-file=ca.crt=ca.crt --dry-run=client -o yaml | oc apply -n $WSA_INSTANCE_NAMESPACE -f -

When you use custom certificates, you must manage the lifecycle of the certificates in the secret. When WebSphere Automation detects changes to any of the certificates in wsa-external-tls-secret, the platform UI is automatically restarted to reflect changes in the modified certificates.

Configuring the routeHost parameter by using the Red Hat OpenShift console

  1. Go to the Installed Operators page. In the Red Hat OpenShift console, click Operators > Installed Operators from the navigation menu.
  2. If you haven't already done so, create a namespace in which to create the WebSphere Automation instance. Open the Project menu and click Create Project. Specify a name, for example, websphere-automation. If the installation mode for the operator was A specific namespace on the cluster, select that same namespace from the Projects list.
    Note: For security considerations applicable at the namespace level, see Using the ResourceQuota resource.
  3. Click the WebSphere Automation operator.
  4. Click the WebSphereAutomation tab.
  5. The instance creation panel opens, and offers two methods for configuring the resource: the Form view and the YAML view. The Form view is selected by default. Switch to the YAML view and copy and paste the following YAML:
    apiVersion: automation.websphere.ibm.com/v1
kind: WebSphereAutomation
metadata:
  name: wsa
spec:
  license:
    accept: true
  platformUI:
    customRoute:
      routeHost: example.com

    Ensure that you replace the value for the routeHost parameter with the hostname of the platform UI for your installation.

Configuring the routeHost parameter by using the command-line interface

Ensure that the WSA_INSTANCE_NAMESPACE environment variable is set to your instance namespace.

export WSA_INSTANCE_NAMESPACE=websphere-automation

Use the following oc command to update the platform UI hostname:

cat <<EOF | oc apply -f -
apiVersion: automation.websphere.ibm.com/v1
kind: WebSphereAutomation
metadata:
  name: wsa
  namespace: $WSA_INSTANCE_NAMESPACE
spec:
  license:
    accept: true
  platformUI:
    customRoute:
      routeHost: example.com
EOF

Replace the value for the routeHost parameter with the appropriate value for your installation. Note that this command sets the value of the spec.license.accept parameter to true, indicating that you accept the license agreement for WebSphere Automation.

What to do next

Depending on your installation configuration, consider changing Cloud Pak administration console certificates.