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.
Procedure
- Set the
global.tls.certificate.useExistingSecret
global property in the
NOI operator custom resource (CR) used to create the deployment.
spec:
helmValuesNOI:
global.tls.certificate.useExistingSecret: true
-
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 '/CN=netcool.example.com'
In the example the Common Name (CN) is set to netcool.example.com
. Refer to this
value as ${PROXY_COMMON_NAME}.
- 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]
Where:
- <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
noi.ibm.com_noihybrids_cr.yaml or noi.ibm.com_nois_cr.yaml
files (YAML view).
- certificate.pem is the signed certificate returned by the CA.
- key.pem is the private key corresponding to the signed certificate.
- 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}
- From the event source client, import the CA public certificate, which is used in step
2. Complete the following steps:
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:
proxy-release_name.fqdn
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: [OCP_AGG_P_TLS]
{
Primary: ${PROXY_COMMON_NAME} ssl ${AGGP_PROXY_PORT}
}
[OCP_AGG_B_TLS]
{
Primary: ${PROXY_COMMON_NAME} ssl ${AGGB_PROXY_PORT}
}
For more information, see
Identifying the proxy listening port.
- Run the following command to generate the interfaces file:
- 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.