Configuring TLS encryption with a custom certificate on Red Hat OpenShift Container Platform

Follow this procedure if you wish the proxy to use a custom certificate signed by an external Certificate Authority. The proxy requires a public certificate and private key pair to be supplied through a Kubernetes secret called {{ .Release.Name }}-proxy-tls-secret. If you want to use a custom certificate, for example, one signed by your own public key infrastructure Certificate Authority (CA), create your own proxy secret containing the public certificate and private key pair. To enable a successful Transport Layer Security (TLS) handshake, import the CA signer certificate into the keystore of any client application as a trusted source.


  1. Set the global.tls.certificate.useExistingSecret global property in the NOI operator custom resource (CR) used to create the deployment.
        global.tls.certificate.useExistingSecret: true
  2. Create the private key and public certificate pair the proxy will present to clients during TLS connection handshake. The following example creates a self signed certificate for demonstration purposes. In production environments, replace this example with a certificate signed by an external CA.
    openssl req -newkey rsa:2048 -keyout key.pem -x509 -days 365 -out certificate.pem -nodes -subj '/'

    In the example the Common Name (CN) is set to Refer to this value as ${PROXY_COMMON_NAME}.

  3. Create the proxy TLS secret by running the following command with the OpenShift® Cluster CLI:
    oc create secret tls release_name-proxy-tls-secret --cert=certificate.pem --key=key.pem [--namespace namespace]
    • <release_name> is the name of your deployment, as specified by the value used for name (Operator Lifecycle Manager UI Form view), or name in the metadata section of the or files (YAML view).
    • certificate.pem is the signed certificate returned by the CA.
    • key.pem is the private key corresponding to the signed certificate.
  4. From the event source client, ensure that a connection can be made to the proxy. You must know the proxy address and port numbers. How you find this information depends on how the OpenShift cluster network has been configured and additionally whether a ClusterIP or NodePort service type is used.

    Refer to these values as ${PROXY_ADDRESS}, ${AGGP_PROXY_PORT}, and ${AGGB_PROXY_PORT}.

    Use the ping command to test network address resolution:
    ping ${PROXY_ADDRESS}
  5. From the event source client, import the CA public certificate, which is used in step 2. Complete the following steps:
    1. If necessary, create the keystore using one of the following commands:
      •	$NCHOME/bin/nc_gskcmd -keydb -create -db "$NCHOME/etc/security/keys/omni.kdb" -pw password -stash -expire 366
      For more information about creating a keystore, see the Netcool/OMNIbus documentation, link.
    2. Import a privacy enhanced mail (PEM) encoded signer certificate by running one of the following commands:
      •	$NCHOME/bin/nc_gskcmd -cert -add -file mycert.pem -db $NCHOME/etc/security/keys/omni.kdb -stashed
      For more information about adding certificates from CAs, see the Netcool/OMNIbus documentation, link.
  6. Note: To successfully complete the TLS handshake and establish a secure TLS connection, the ObjectServer address, which is specified in the omni.dat file, must exactly match the certificate subject Common Name (CN) value. Certificates that are manually created must have a subject CN value in the following format:
    From the event source client, edit the client's omni.dat file. Add the proxy Common Name value from step 2 as the server address and the proxy port number in the omni.dat file, as displayed in the following example:
            Primary: ${PROXY_COMMON_NAME} ssl ${AGGP_PROXY_PORT}
            Primary: ${PROXY_COMMON_NAME} ssl ${AGGB_PROXY_PORT}
    For more information, see Identifying the proxy listening port.
  7. Run the following command to generate the interfaces file:
  8. You can now make a secure TLS connection to both the primary and backup ObjectServers running in the Netcool Operations Insight® on Red Hat OpenShift deployment, by using the server names defined in step 6, for example: OCP_AGG_P_TLS and OCP_AGG_B_TLS.