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 pods that use the secret
`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. tls.key is the Db2® certificate private key. tls.crt is the Db2 certificate. mydbserver.arm is the Db2 certificate. This file is a copy of the tls.crt certificate file that was renamed to the name that FTM expects for the Db2 certificate.	IBM® App Connect Java™ Platform, Enterprise Edition Java Platform, Standard Edition The IBM Db2U instances
`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. If you are using a self-signed certificate, ca.crt is the same file as the tls.crt.	IBM MQ IBM App Connect Java Platform, Enterprise Edition Java Platform, Standard Edition All FTM components
`ftm-ingress-cert-secret`	tls.key is the Ingress TLS key. tls.crt is the Ingress TLS certificate. ca.crt is the Ingress CA public certificate. The file must contain the full CA certificate chain, including the intermediate and root certificates.	IBM MQ IBM App Connect Java Platform, Enterprise Edition Java Platform, Standard Edition Applies to all FTM components except FTM Base
`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.	IBM App Connect Java Platform, Enterprise Edition Java Platform, Standard Edition
`ftm-ssl-signing-cert-secret`	`tls.key` is the business message signing configuration TLS key. `tls.crt` is the business message signing configuration TLS certificate. `ca.crt` is the business message signing configuration CA public certificate. The file must contain the full CA certificate chain, including the intermediate and root certificates.	FTM TCH RTP connectors
`ftm-routes-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.	This is an optional certificate that can be configured on the FTM routes. If not specified, the FTM routes will use the default Red Hat OpenShift certificate.

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 offerings. 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/.

The FTM operator can generate TLS certificates for the FTM application. If the FTM operator deploys the MQ queue manager, the same TLS certificates can be used by the MQ queue manager. The cert-manager operator for Red Hat OpenShift must be installed for the FTM operator to generate the FTM application certificate.

The FTM certificate must include the following DNS entries in its Subject Alternative Names (SANs) list. You need to replace the FTM instance name with your environment-specific name and the namespace with that of the namespace that FTM is deployed to. These entries are automatically added if the FTM operator is used to generate the certificate.

"*.<ftm-instance>-gateway-engine-internal.<namespace>.svc.cluster.local"

"*.<ftm-instance>-gateway-server-inbound-internal.<namespace>.svc.cluster.local"

"*.<ftm-instance>-gateway-server-inbound-check-internal.<namespace>.svc.cluster.local"

"*.<ftm-instance>-gateway-server-outbound-internal.<namespace>.svc.cluster.local"

"*.<ftm-instance>-business-rules-server-internal.<namespace>.svc.cluster.local"

"*.<ftm-instance>-business-rules-server-headless-internal.<namespace>.svc.cluster.local"

"*.<ftm-instance>-transaction-server-internal.<namespace>.svc.cluster.local"

"*.<ftm-instance>-business-rules-manager-internal.<namespace>.svc.cluster.local"

```
"*.<namespace>.svc.cluster.local"
```

If an external database or IBM MQ is used, add the hostnames of those services to the SAN list in the FTM certificate, too.

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 offering 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 offering 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 offering 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 offering is deployed.
2. Replace the <DNS-Domain> with the list of domains for which the application certificates are generated. You need to include the domain names from the Create FTM certificates section in this list of domains. To add each of these domains, replace <ftm-instance> with your environment-specific name and <namespace> with the namespace that FTM is deployed into.
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. Make sure that you predeploy IBM Db2 before you deploy FTM. Using the IBM Db2U operator, you can deploy IBM Db2 either externally to the Red Hat OpenShift Container Platform cluster or within the cluster.

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.

Note: FTM supports only one IBM Db2 certificate. If you are using two different IBM Db2 instances for the FTM database and the Duplicate Detect database, make sure that both the instances are configured with the same TLS certificate.

To get the certificates for the IBM Db2U instances, do the following steps:

Run the following commands to create a directory to store the IBM Db2 certificates and then switch to that directory.
```
mkdir -p /var/tmp/db-certs
```
```
cd /var/tmp/db-certs
```
To get the certificate from the predeployed IBM Db2U instance where TLS is enabled, do the following steps. The certificate is in the /mnt/blumeta0/db2/ssl_keystore/ca.crt file.
1. Copy the TLS certificate ca.crt file to the /var/tmp/db-certs directory.
2. Rename the file to mydbserver.arm.
To use a pre-created TLS certificate when you are creating new IBM Db2U instances, do the following steps:
1. Copy all the certificate files (certificate, private key, and CA public certificate) to the directory /var/tmp/db-certs. You can use an authorized CA in your environment to generate the certificate.
2. Create a copy of the certificate file tls.crt and name the copy mydbserver.arm. FTM refers to the IBM Db2 certificate with this specific file name.
3. Make sure that the following files are in the /var/tmp/db-certs directory.
  - ca.crt (CA public certificate)
  - tls.crt (Certificate)
  - tls.key (Private key)
  - mydbserver.arm (Copy of tls.crt)

Add the IBM Db2 certificate to the FTM Db2 secret. 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 offering is deployed.
```
oc create secret generic ftm-db2-ssl-cert-secret --from-file=/var/tmp/db-certs
```

Now that the ftm-db2-ssl-cert-secret secret is created, you can create the instances of Db2U. FTM uses this secret for all the database instances.

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
spec.config.duplicateDatabase.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.; If you are deploying FTM Check and Duplicate Detect, you must also configure the parameter for the Duplicate Detect database.
spec.config.database.certificate.valueFrom.secretKeyRef.name
spec.config.duplicateDatabase.certificate.valueFrom.secretKeyRef.name: Specify the name of the Red Hat OpenShift Container Platform secret that contains the TLS certificate to use for Db2.; If you are deploying FTM Check and Duplicate Detect, you must also configure the parameter for the Duplicate Detect database.
spec.config.database.certificate.valueFrom.secretKeyRef.key
spec.config.duplicateDatabase.certificate.valueFrom.secretKeyRef.key: Specify the name of the key in the secret that contains the certificate file.; If you are deploying FTM Check and Duplicate Detect, you must also configure the parameter for the Duplicate Detect database.

IBM MQ configurations with TLS and LDAP authentication

IBM MQ uses the common certificate that is created in the Create FTM certificates section. You can add the additional configuration files in the Red Hat OpenShift Container Platform secrets.

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 offering. 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.
To configure IBM MQ LDAP authentication, do the following steps:
1. IBM MQ can be configured to authenticate with an external LDAP server that is running outside the Red Hat OpenShift Container Platform environment. To enable authentication with this external LDAP server, configure the following parameters in the custom resource for your FTM offering.
  
  spec.config.mq.username.valueFrom.secretKeyRef.name
  
  Set this parameter to the name of the Red Hat OpenShift secret that has the username to use to connect to IBM MQ.
  
  spec.config.mq.username.valueFrom.secretKeyRef.key
  
  Set this parameter to the name of the key to use to get the username from the Red Hat OpenShift secret with the username for IBM MQ.
  
  spec.config.mq.password.valueFrom.secretKeyRef.name
  
  Set this parameter to the name of the Red Hat OpenShift secret that has the password to use to connect to IBM MQ.
  
  spec.config.mq.password.valueFrom.secretKeyRef.key
  
  Set this parameter to the name of the key to use to get the password from the Red Hat OpenShift secret with the password for IBM MQ.
2. Run the following commands to create a directory for storing the IBM MQ LDAP configuration files and then switch to the directory.
```
mkdir -p /var/tmp/mq-ldap
```
```
cd /var/tmp/mq-ldap
```
3. Create a file called ldap_config.mqsc to hold the LDAP configuration data. Use the following text as a template for the file.
```
ALTER QMGR CHLAUTH(ENABLED)

SET CHLAUTH(QMLDAP.SVRCONN) TYPE(BLOCKUSER) ACTION(REPLACE) USERLIST('nobody')

SET CHLAUTH('FTM.*') TYPE(BLOCKUSER) ACTION(REPLACE) USERLIST('nobody')

DEFINE AUTHINFO(FTMQMGR.IDPW.LDAP) AUTHTYPE(IDPWLDAP) CONNAME(‘myldap.server.com(389)’) 
SHORTUSR(‘uid’) ADOPTCTX(YES) AUTHORMD(SEARCHGRP) BASEDNG(‘ou=mqusers,dc=example,dc=com’) 
BASEDNU(‘dc=example,dc=com’) CHCKCLNT(OPTIONAL) CHCKLOCL(NONE) CLASSGRP(‘groupOfUniqueNames’) 
CLASSUSR(‘inetOrgPerson’) FINDGRP(‘uniqueMember’) GRPFIELD(‘cn’) LDAPPWD(‘password’) 
LDAPUSER(‘cn=read-only-admin,dc=example,dc=com’) NESTGRP(YES) SECCOMM(NO) USRFIELD(‘uid’)

ALTER QMGR CONNAUTH(FTMQMGR.IDPW.LDAP)

REFRESH SECURITY

SET AUTHREC PROFILE(‘**’) OBJTYPE(QMGR)GROUP(‘ou=mqusers,dc=example,dc=com’) AUTHADD(ALL)

SET AUTHREC PROFILE(‘**’) OBJTYPE(queue) GROUP(‘ou=mqusers,dc=example,dc=com’) AUTHADD(ALL)

SET AUTHREC PROFILE(‘@class’) OBJTYPE(queue) GROUP(‘ou=mqusers,dc=example,dc=com’) AUTHADD(CRT)

SET AUTHREC PROFILE(‘**’) OBJTYPE(topic) GROUP(‘ou=mqusers,dc=example,dc=com’) AUTHADD(ALL)

SET AUTHREC PROFILE(‘@class’) OBJTYPE(topic) GROUP(‘ou=mqusers,dc=example,dc=com’) AUTHADD(CRT)
```
4. Update the MQSC commands in the provided template with the appropriate commands that corresponds to the LDAP server that you are connecting to. For more information about each MQSC command, see the IBM MQ documentation.
5. Run the following commands to create the configmap in the namespace where your FTM offering is deployed. You can choose any name for the configmap. This example uses ftm-demo as the namespace and ftm-mq-ldap-config as the configmap name.
```
oc project ftm-demo
```
```
oc create configmap ftm-mq-ldap-config --from-file=/var/tmp/mq-ldap
```
6. Update the queue manager instance with the specified LDAP details by using the following MQSC configuration:
```
mqsc:
  - configMap:
      items:
        - ldap_config.mqsc
      name: ftm-mq-ldap-config
```
7. After you complete the steps for IBM MQ LDAP authentication, the IBM MQ pods reconcile automatically with the updated TLS and LDAP configurations.

Add the IBM License Service certificate to the FTM truststore

The IBM License Service runs in a pod in another namespace and provides a service that can be used to access it. The FTM Operations and Administration Console (OAC) container accesses the license service securely by using TLS. For the TLS communication to occur successfully, the certificate of the license server needs to be added to the truststore that is used by the FTM components.

Extract the certificates from the licensing service to use for metering. These certificates are automatically renewed if they expire. Run the following commands by using the Red Hat OpenShift Container Platform command-line interface to get the certificates.

All additional certificates that you want to add for your FTM offering must be in the same directory. Either change to the existing directory or create a directory where you want your additional certificates to be stored. The following example command creates a directory for the FTM certificates.
```
mkdir /var/tmp/addtnl-certs
```
If the ftm-additional-certs-secret secret exists in the FTM namespace, get the existing certificates from the secret so they are not lost when the secret is deleted. Extract them to the directory from step 1.
```
oc project namespace
```
```
oc extract secret/ftm-additional-certs-secret --to=/var/tmp/addtnl-certs
```
Log in to the Red Hat OpenShift cluster and select the ibm-licensing namespace.
```
oc project ibm-licensing
```

Extract the certificates from the licensing service by running the following commands. The public and CA certificates are in crt.pem.

oc extract configmap/ibm-licensing-upload-config --to=/var/tmp/addtnl-certs --keys=crt.pem

mv /var/tmp/addtnl-certs/crt.pem /var/tmp/addtnl-certs/licensing-cert.crt

Create the ftm-additional-certs-secret secret in your FTM namespace. If the secret exists, delete it first. The following example commands select the FTM namespace, delete the existing secret, and then create a new secret with the same name.
```
oc project namespace
```
```
oc delete secret ftm-additional-certs-secret
```
```
oc create secret generic ftm-additional-certs-secret --from-file=/var/tmp/addtnl-certs
```

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.