Providing a custom certificate for Analytics offload

Prepare a private or self-signed certificate for offloading data and then add it to the IBM® API Connect Analytics deployment on OpenShift.

Procedure

Log in to a server where you can run oc commands against the OpenShift environment where your analytics subsystem is installed.
Encode the certificate file contents in base64.
You can use either JKS files or text-based files such as PEM files:
- If you use a JKS file for the certificate, you must encode it.
- If you use a text-based file such as PEM, then you can either encode it, or paste its contents directly.
There are various tools for base64 encoding. If the cat and base64 commands are available you can run the following command to encode the file contents:
```
cat keystore.jks | base64
```
Copy the output so that you can paste it into the secret in the next step.

Create a secret to contain the certificate.

Create a file called analytics_certs.yaml to contain the secret.

The secret's name that you specify in the file does not have to match the file name. In the examples, the secret's name is offload-certificates. Do not use the underscore character ( _ ) in the secret name.

The method for adding the certificate to the secret depends on whether you encoded the file contents in the previous step:

Base64-encoded file: In the data section of the secret, type a name for the field (you can choose the name). Paste the encoded output from the previous step (enclosed in "") as the value.

apiVersion: v1
kind: Secret
metadata:
  # Change value of name to be whatever you wish secret to be called
  name: offload-certificates
# Only base64 encoded data should be placed in data section; JKS keys would go here
data:
  keystore.jks: "output_of_base64_encoded_jks"

Plain text file: In the stringData section of the secret, type a name for the key or certificate (you can choose the name), and paste the value.

apiVersion: v1
kind: Secret
metadata:
  # Change value of name to be whatever you wish secret to be called
  name: offload-certificates
stringData:
  cacert.pem: |-
    -----BEGIN CERTIFICATE-----
    MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE
    ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
    MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoT
    B0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCB
    nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPR
    fM6fBeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+AcJkVV5MW
    8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kCAwEAAaOCAQkwggEFMHAG
    A1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UE
    CxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoG
    A1UdEAQTMBGBDzIwMTgwODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvS
    spXXR9gjIBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQFMAMB
    Af8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUAA4GBAFjOKer89961
    zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y7qj/WsjTVbJmcVfewCHrPSqnI0kB
    BIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee95
    70+sB3c4
    -----END CERTIFICATE-----

You can add multiple keys/certificates, setting the field names for each as desired. For each key, a file based on the corresponding field name is created in the ingestion pod container at /etc/velox/external_certs/offload. The examples here would result in the files keystore.jks and cacert.pem.

Save the file.

Optional: Create an additional secret.
If you have sensitive data such as a certificate passphrase that must be available in text format, you can store it in another secret.

If your passphrase is not sensitive (such as the JKS default passphrase), then you can supply it directly in the Logstash configuration, and skip this step.
1. Create the file offload_env_var.yaml. The secret's name that you specify in the file does not have to match the file name. In this example, the secret's name is offload-jks-passphrase.
2. In the stringData section, set the property jks_password.txt to your passphrase (in plain text):
```
apiVersion: v1
kind: Secret
metadata:
  name: offload-jks-passphrase
stringData:
  jks_password.txt: <passphrase>
```
3. Run the following command to update the cluster:
```
oc apply -f offload_env_var.yaml -n your_namespace
```
  Where offload_env_var.yaml is the secret's file name.
Apply the secret to the cluster where the Analytics subsystem is installed.
Run the following command to update the cluster:
```
kubectl apply -f file_name_of_secret.yaml -n namespace
```
Where:
- file_name_of_secret.yaml is the secret's file name.
- namespace is your analytics namespace.
If using a top-level CR edit your APIConnectCluster CR file. Otherwise edit your analytics_cr.yaml file and add a reference to the secret and passwordSecret in the offload section; for example:
```
   offload:
      enabled: true
      output: |
        kafka {
        ...
        }
      secretName: offload-certificates
      passwordSecretName: offload-jks-password
```
If you want to reference the certificate in Offloading data to a third-party system, configure the plugin now.

Step 3 of that procedure shows how you can include the certificate information in the plugin.