OpenSearch custom certificate - During the installation of the Control Room in a cluster setup, you can upload custom certificates with a trusted Certificate Authority (CA) instead of using the default certificate provided by the product for enhanced security.

• The elasticsearch-cert.pem is for administrative purposes, we recommend that you use the firstnode hostname.

  The elasticsearch-node-cert.pem is used to secure inter-node communication. It must include the host names of the second or third node, ensuring encrypted and trusted communication between cluster members.

  Note:

  • If you have an intermediate certificate, you can rename it to root-ca-cert.pem to use it as the root certificate. The system will then recognize this intermediate certificate as the root after performing a certificate chain validation up to it.
  • The .zip file must contain the certificate, key, and root CA certificate files.
• Ensure that the following certificates (applicable for Windows and Linux) are signed by root/intermediate CA certificate:
  • elasticsearch-cert.pem
  • elasticsearch-node-cert.pem
    Note:

    • Two unique CA signed certificates must be generated:
      • One for node admin.
      • One for node intercommunication
    • Both certificates must have unique common name (CN) value. However, ensure that you do not use the same CN for multiple certificates.
      The CN is used to uniquely identify the certificate owner. Using the same CN for different certificates can make it difficult to distinguish between certificates during validation and troubleshooting, and might result in certificate verification failures or incorrect certificate selection by client applications. For example, consider the following certificates:

      • OpenSearch node certificate: opensearch-node1.example.com
      • OpenSearch admin certificate: opensearch-admin.example.com

      In this example, each certificate has a different CN and can be uniquely identified.
    • Transport layer TLS certificates need to be configured as both the client (TLS Web Client Authentication) and server (TLS Web Server Authentication) in the certificate’s Extended Key Usage section because the nodes using the TLS certificates assume the responsibility of serving and receiving the communication requests internally. The certificates should have extended key usage with both server and client authentication. For example while generating the certificates it must include extendedKeyUsage = serverAuth, clientAuth using a config file.

• Ensure certificates are not encrypted (no password protection)
• Include only the five required certificate files
• Folder structure should not contain any sub folders inside the .zip file.

  For example:

We recommend using the fully qualified domain name (FQDN) or hostname of the OpenSearch server as the CN. This helps ensure that the host name used by Automation 360 to connect to OpenSearch matches the identity presented in the certificate during SSL/TLS validation.

For example, if Automation 360 connects to OpenSearch using opensearch.example.com, ensure that you use CN=opensearch.example.com as the certificate CN. Using the server hostname as the CN simplifies certificate management and helps prevent hostname mismatch errors during secure connections.