Create certificates

Use a different set of certificates, even if self-signed, for every deployment. Generally, self-signed certificates are allowed in development or nonproduction deployments. The certificates need to be added to FTM secrets.

The following table provides various certificates and a list of Red Hat® OpenShift® Container Platform secrets that are used by the FTM pods. The list helps you understand the secrets and files you need to update when you are using your own CA-signed certificates.

Table 1. FTM certificates and secrets
Red Hat OpenShift Container Platform secret	Files in the secret
`ftm-mq-ssl-cert-secret`	ca.crt is the CA public certificate. The file must contain the full CA certificate chain, including the intermediate and root certificates.
`ftm-db2-ssl-cert-secret`	ca.crt is the CA public certificate. The file must contain the full CA certificate chain, including the intermediate and root certificates.
`ftm-ssl-cert-secret`	tls.key is the TLS key. tls.crt is the TLS certificate. ca.crt is the CA public certificate. The file must contain the full CA certificate chain, including the intermediate and root certificates.
`ftm-additional-certs-secret`	You can add more certificates to the FTM truststore. For example, you can import the certificate for the IBM® licensing server.

The FTM application components use keystore or truststore files in PKCS12 or JKS format to store the certificates. The FTM components import the generated certificates into the keystore or truststore file for their use. In the Red Hat OpenShift Container Platform secret ftm-application-secret, configure the KSTORE_PASSWORD and TSTORE_PASSWORD variables for the keystore and truststore password. The password can be up to 12 characters.

Create FTM certificates

You can use a certificate manager to create and manage the TLS certificates for the FTM solutions. For more information about a specific certificate manager, see the documentation for that certificate manager. Examples of certificate managers are shown in the following list.

Cloud native certificate management. For more information, see https://cert-manager.io/.
External Secrets Operator. For more information, see https://external-secrets.io/latest/.

Example of using cloud native certificate management to create the FTM certificates

Cloud native certificate management is responsible for creating and managing the certificates that are used by the applications. It can be configured to create the certificates by using different issuers. For more information about using other types of issuers, see the cloud native certificate management documentation at https://cert-manager.io/docs/configuration/issuers/.

To create the self-signed certificates with cloud native certificate management, do the following steps.

Import the following YAML configuration to create the self-signed CA issuers.
```
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ftm-self-tls
  namespace: <FTM-namespace>
spec:
  selfSigned: {}
```
1. Replace <FTM-namespace> with the actual namespace where your FTM solution is deployed.
2. Click Create. The self-signed certificate issuer is created.
Import the following YAML configuration to create a CA certificate that references the self-signed issuer and specifies the isCA field.
```
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ftm-ca-tls
  namespace: <FTM-namespace>
spec:
  secretName: ftm-ibm-cert-manager-ca-certs
  isCA: true
  commonName: "mycacert"
  issuerRef:
    name: ftm-self-tls # This name needs to match the name of the issuer that was created previously
    kind: Issuer
  dnsNames:
  - <DNS-Domain>
```
1. Replace the <FTM-namespace> with the actual namespace where your FTM solution is deployed.
2. Replace the <DNS-Domain> with the domain for which the CA certificates are generated. For example, example.com.
3. Click Create. The CA certificate that references the self-signed issuer is created.
Import the following YAML configuration to create the certificate issuer for the application certificates.
```
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ftm-deployment-tls
  namespace: <FTM-namespace>
spec:
  ca:
    secretName: ftm-ibm-cert-manager-ca-certs
```
1. Replace the <FTM-namespace> with the actual namespace where your FTM solution is deployed.
2. Click Create. The certificate issuer for the application certificates is created.
Verify whether the status of both issuers is Ready by using the following command in the Red Hat OpenShift Container Platform command-line interface.
```
oc get issuers
```
```
NAME                 READY
ftm-deployment-tls   True
ftm-self-tls         True
```
Import the following YAML configuration to create the certificate for FTM by using the issuer.
```
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ftm-deployment-tls
  namespace: <FTM-namespace>
spec:
  secretName: ftm-ssl-cert-secret
  issuerRef:
    name: ftm-deployment-tls # This name needs to match the name of the issuer that was created previously
    kind: Issuer
  commonName: "ftmserver"
  dnsNames:
  - <DNS-Domain>
```
1. Replace the <FTM-namespace> with the actual namespace where your FTM solution is deployed.
2. Replace the <DNS-Domain> with the domain for which the application certificates are generated. For example, example.com.
3. The value of the commonName attribute needs to match the value of the spec.config.security.tls.label parameter in the operator CR YAML file. This attribute is important because it is part of the Subject field of the certificate. The common name for the CA public certificate (ca.crt) needs to be different from the common name for the application certificate tls.crt.
4. Click Create to create the certificate for FTM by using the issuer.
After the YAML file configuration import is successful, the Red Hat OpenShift Container Platform creates a secret that is named ftm-ssl-cert-secret. This secret includes the tls.key and tls.crt files that are used by FTM. It also includes ca.crt, which is the CA root certificate.
Use the Red Hat OpenShift Container Platform command-line interface to run the following command to make sure that the certificate includes the ca.crt, tls.crt, and tls.key files.
```
oc get secret ftm-ssl-cert-secret -o yaml
```

IBM Db2 certificates

FTM does not bundle the IBM Db2® database and always treats it as an external database.

FTM supports TLS encrypted communication with the IBM Db2 database. You can configure IBM Db2 to run over TLS by following the IBM Db2 documentation.

Add the IBM Db2 certificate to the FTM Db2 secret. FTM uses the ftm-db2-ssl-cert-secret secret for all the database instances. Depending on how TLS was configured for IBM Db2, one or more files need to be added to the secret. To add these certificates to the secret, do the following steps. The example commands use ftm-demo as the namespace.

Run the following commands to change to the FTM namespace and delete the existing secret if it exists.
```
oc project ftm-demo
```
```
oc delete secret ftm-db2-ssl-cert-secret
```
Run the following command to create a new Red Hat OpenShift Container Platform secret in the namespace where the FTM solution is deployed.
```
oc create secret generic ftm-db2-ssl-cert-secret --from-file=/var/tmp/db-certs
```

This secret is needed to configure the TLS connection between FTM and IBM Db2. To configure the TLS connection to IBM Db2, set the following parameters in the custom resource for FTM.

spec.config.database.enableTLS: Specify whether to use a TLS connection to the database. When the value is true, a TLS connection to the database is used. When it is false, a TLS connection is not used.
spec.config.database.certificate.valueFrom.secretKeyRef.name: Specify the name of the Red Hat OpenShift Container Platform secret that contains the TLS certificate to use for Db2.
spec.config.database.certificate.valueFrom.secretKeyRef.key: Specify the name of the key in the secret that contains the certificate file.

IBM MQ configuration with TLS authentication

Configure whether FTM connects to IBM MQ by using TLS.

If you want to enable TLS for IBM MQ, set spec.config.mq.enableTLS to true in the custom resource for your FTM solution. Set spec.config.mq.certificate to the name of your Red Hat OpenShift secret that has the IBM MQ TLS certificate.
If you want to disable TLS for IBM MQ, set spec.config.mq.enableTLS to false.

Ensure that WebSphere Application Server is using your certificate as the default

Verify that WebSphere® Application Server is using your own self-signed or a paid certificate. If you have your own self-signed certificate, verify that it is set up as the default certificate in WebSphere Application Server. Do not use the default certificate that was created by WebSphere Application Server.

User-supplied certificates for external applications

Apart from the application-specific certificates, you need to configure additional certificates in the FTM application truststore for integrating with external applications. For client certificate authentication, it is also necessary to include the client certificate in the Liberty truststore.

Renewing self-signed certificate

When the TLS certificates that are configured during deployment are about to expire or are compromised, they need to be renewed. This process involves creating the new certificates, adding them to keystore or truststore, and creating all the required Red Hat OpenShift Container Platform secrets.