Skip to main content

Working with security certificates

Lenovo XClarity Administrator uses SSL certificates to establish secure, trusted communications between XClarity Administrator and its managed devices (such as chassis and service processors in the System x servers) as well as communications with XClarity Administrator by users or with different services. By default, XClarity Administrator, CMMs, and baseboard management controllers use XClarity Administrator-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 self-signed server certificate, which is uniquely generated in every instance of XClarity Administrator, provides sufficient security for many environments. You can choose to let XClarity Administrator manage certificates for you, or you can take a more active role and customize or replace the server certificates. XClarity Administrator 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 Administrator 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 Administrator provides several services that accept incoming SSL/TLS connections. When a client, such as a managed device or a web browser, connects to one of these services, XClarity Administrator 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 Administrator’s server certificate is not included in the client’s list, the client disconnects from XClarity Administrator to avoid exchanging any security sensitive information with an untrusted source.

XClarity Administrator acts as a client when communicating with managed devices and external services. When XClarity Administrator connects to a device or external service, the device or external service provides its server certificate to be identified by XClarity Administrator. XClarity Administrator maintains a list of certificates that it trusts. If the trusted certificate that is provided by the managed device or external service is not listed, XClarity Administrator 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 Administrator 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 Administrator 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 or restoring the Lenovo XClarity Administrator self-signed server certificate).

    Also during the initial setup, a separate key is generated and a sever certificate is created and signed a certificate is created that is signed by the internal certificate authority. This certificate used as the default XClarity Administrator server certificate. It automatically regenerated each time XClarity Administrator 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 or restoring the Lenovo XClarity Administrator self-signed 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 Administrator (see Deploying customized server certificates to Lenovo XClarity Administrator).

    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 Certificate Authority certificate into a web browser).

  • OS Deploy Certificate. A separate certificate is used by the operating-system deployment service to ensure that the operating-system installer can connect securely to deployment service during the operating-system installation process. If the key has been compromised, you can regenerate it by restarting the management server.

The following category (trust stores) of certificates are used by XClarity Administrator clients.

  • Trusted Certificates.

    This trust store manages certificates that are used to establish a secure connection to local resources when XClarity Administrator acts as a client. Examples of local resources are managed devices, local software when forwarding event and an external LDAP server.

  • External-Services Certificates. This trust store manages certificates that are used to establish a secure connection with external services when XClarity Administrator 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, and Apple and Google push-notification servers if Lenovo XClarity Mobile push notifications are enabled for an iOS or Android device. 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 Administrator 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.

XClarity Administrator supports RSA-3072/SHA-384, RSA-2048/SHA-256, and ECDSA p256/SHA-256 certificate signatures. Other algorithms such as SHA-1 stronger or SHA hashes might be supported depending on your configuration. Consider the selected cryptographic mode in XClarity Administrator (see Configuring cryptography settings on the management server), the selected security settings for managed servers (Configuring the security settings for a managed server), and the capabilities of other software and devices in your environment. ECDSA certificates that are based on some elliptic curves (including p256), but not all elliptic curves, are supported on the Trusted Certificates page and in the signing chain of the XClarity Administrator certificate but are not currently supported for use by the XClarity Administrator server certificate.
Note
XClarity Administrator uses RSA- 3072/SHA-384 certificate signatures for servers with XCC2 in Strict mode.
  • Installing a customized, externally signed server certificate
    You can choose to use a server certificate that was signed by a private or commercial certificate authority (CA).
  • Regenerating or restoring the Lenovo XClarity Administrator self-signed server certificate
    You can generate a new certificate authority or server certificate to replace current self-signed certificates or to reinstate a Lenovo XClarity Administrator-generated certificate if XClarity Administrator currently uses a customized externally-signed server certificate. The new self-signed server certificate is then used by the authentication, HTTPS, and CIM servers on the XClarity Administrator. It is also automatically provisioned to all managed devices.
  • Resolving an untrusted server certificate
    The server certificate that is used to establish a secure connection to a managed device can become untrusted. If the problem is due to a down-level version of the device CA root certificate or device self-signed certificate in the Lenovo XClarity Administrator trust store, XClarity Administrator can resolve the untrusted server certificate.
  • Downloading the server certificate
    You can download a copy of the current server certificate, in PEM or DER format, to your local system. You can then import the certificate into your web browser or another applications (such as Lenovo XClarity Mobile or Lenovo XClarity Integrator).
  • Importing the Certificate Authority certificate into a web browser
    To avoid security warning messages from your web browser when you access Lenovo XClarity Administrator, you can download a copy of the current Certificate Authority (CA) certificate, in PEM or DER format, to your local system, and then import that certificate into your web browser's list of trusted certificates.
  • Adding and replacing a certificate revocation list
    A certificate revocation list is a list of certificates that have been revoked and are no longer trusted. A certificate might be revoked if it was incorrectly issued from by the CA or if its key is compromised, lost, or stolen.