Working with security certificates

Lenovo XClarity Orchestrator uses SSL certificates to establish secure, trusted communications between XClarity Orchestrator and its managed resource managers (such as Lenovo XClarity Administrator or Schneider Electric EcoStruxure IT Expert) as well as communications with XClarity Orchestrator by users or with different services. By default, XClarity Orchestrator and Lenovo XClarity Administrator use XClarity Orchestrator-generated certificates that are self-signed and issued by an internal certificate authority.

Before you begin

This section is intended for administrators that have a basic understanding of the SSL standard and SSL certificates, including what they are and how to manage them. For general information about public key certificates, see X.509 webpage in Wikipedia and Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (RFC5280) webpage.

About this task

The default server certificate, which is uniquely generated in every instance of XClarity Orchestrator, provides sufficient security for many environments. You can choose to let XClarity Orchestrator manage certificates for you, or you can take a more active role by customizing and replacing the server certificates. XClarity Orchestrator provides options for customizing certificates for your environment. For example, you can choose to:
  • Generate a new pair of keys by regenerating the internal certificate authority and/or the end server certificate that uses values that are specific to your organization.
  • Generate a certificate signing request (CSR) that can be sent to your choice of certificate authority to sign a custom certificate that can then be uploaded to XClarity Orchestrator to be used as end-server certificate for all its hosted services.
  • Download the server certificate to your local system so that you can import that certificate into your web browser's list of trusted certificates.

XClarity Orchestrator provides several services that accept incoming SSL/TLS connections. When a client, such as a web browser, connects to one of these services, XClarity Orchestrator provides its server certificate to be identified by the client attempting the connection. The client should maintain a list of certificates that it trusts. If XClarity Orchestrator server certificate is not included in the client’s list, the client disconnects from XClarity Orchestrator to avoid exchanging any security sensitive information with an untrusted source.

XClarity Orchestrator acts as a client when communicating with resource managers and external services. When this occurs, the resource manager or external service provides its server certificate to be verified by XClarity Orchestrator. XClarity Orchestrator maintains a list of certificates that it trusts. If the trusted certificate that is provided by the resource manager or external service is not listed, XClarity Orchestrator disconnects from the managed device or external service to avoid exchanging any security sensitive information with an untrusted source.

The following category of certificates is used by XClarity Orchestrator services and are supposed to be trusted by any client connecting to it.
  • Server Certificate. During the initial boot, a unique key and self-signed certificate are generated. These are used as the default Root Certificate Authority, which can be managed on the Certificate Authority page in the XClarity Orchestrator security settings. It is not necessary to regenerate this root certificate unless the key has been compromised or if your organization has a policy that all certificates must be replaced periodically (see Regenerating the internally-signed XClarity Orchestrator server certificate).

    Also during the initial setup, a separate key is generated and a sever certificate is created and signed by the internal certificate authority. This certificate used as the default XClarity Orchestrator server certificate. It automatically regenerated each time XClarity Orchestrator detects that its networking addresses (IP or DNS addresses) have changed to ensure that the certificate contains the correct addresses for the server. It can be customized and generated on demand (see Regenerating the internally-signed XClarity Orchestrator server certificate).

    You can choose to use an externally-signed server certificate instead of the default self-signed server certificate by generating a certificate signing request (CSR), having the CSR signed by an private or commercial certificate Root Certificate Authority, and then importing the full certificate chain into XClarity Orchestrator (see Installing a trusted, externally-signed XClarity Orchestrator server certificate

    If you choose to use the default self-signed server certificate, it is recommended that you import the server certificate in your web browser as a trusted root authority to avoid certificate error messages in your browser (see Importing the server certificate into a web browser

The following category (trust stores) of certificates are used by XClarity Orchestrator clients.
  • Trusted Certificates

    This trust store manages certificates that are used to establish a secure connection to local resources when XClarity Orchestrator acts as a client. Examples of local resources are managed Resource Managers, local software when forwarding event etc.

  • External-Services Certificates. This trust store manages certificates that are used to establish a secure connection with external services when XClarity Orchestrator acts as a client. Examples of external services are online Lenovo Support services that are used to retrieve warranty information or create service tickets, external software (such as Splunk) to which events can be forwarded. It contains preconfigured, trusted certificates from Root Certificate Authorities from certain commonly trusted and world-known certificate-authority providers, such as Digicert and Globalsign).

    When you configure XClarity Orchestrator to use a feature that requires a connection to another external service, refer to the documentation to determine if you need to manually add a certificate to this trust store.

    Note that certificates in this trust store are not trusted when establishing connections for other services (such as LDAP) unless you also add them to the main Trusted Certificates trust store. Removing certificates from this trust store prevents successful operation of these services.