Skip to main content

Cryptographic management

Cryptographic management is composed of communication modes and protocols that control the way that secure communication is handled between Lenovo XClarity Administrator and the managed devices (such as chassis, servers, and Flex switches).

Cryptography algorithms​

XClarity Administrator supports TLS 1.2 and stronger cryptographic algorithms for secure network connections.

For increased security, only high-strength ciphers are supported. The client operating systems and web browsers must support one of the following cipher suites.

  • SSH-ED25519

  • SSH-ED25519-CERT-V01@OPENSSH.COM

  • ECDSA-SHA2-NISTP256

  • ECDSA-SHA2-NISTP256-CERT-V01@OPENSSH.COM

  • ECDSA-SHA2-NISTP384

  • ECDSA-SHA2-NISTP384-CERT-V01@OPENSSH.COM

  • ECDSA-SHA2-NISTP521

  • ECDSA-SHA2-NISTP521-CERT-V01@OPENSSH.COM

  • RSA-SHA2-512

  • RSA-SHA2-256

  • RSA-SHA2-384

Cryptographic modes for the management server​

This setting determines the mode to use for secure communications from the management server.
  • Compatibility. This mode is the default. It is compatible with older firmware versions, browsers, and other network clients that do not implement strict security standards that are required for compliance with NIST SP 800-131A.

  • NIST SP 800-131A. This mode is designed to comply with the NIST SP 800-131A standard. XClarity Administrator is designed to always use strong cryptography internally and, where available, to use strong cryptography network connections. However, in this mode, network connections using cryptography that is not approved by NIST SP 800-131A is not permitted, including rejection of Transport Layer Security (TLS) certificates that are signed with SHA-1 or weaker hash.

    If you select this mode:

    • For all ports other than port 8443, all TLS CBC ciphers and all ciphers that do not support Perfect Forward Secrecy are disabled.

    • Event notifications might not be successfully pushed to some mobile-device subscriptions (see Forwarding events to mobile devices). External services, such as Android and iOS, present certificates that are signed with SHA-1, which is an algorithm that does not conform to the stricter requirements of NIST SP 800-131A mode. As a result, any connections to these services might fail with a certificate exception or a handshake failure.

    For more information about NIST SP 800-131A compliance, see Implementing NIST SP 800-131A compliance.

For more information about setting the security modes on the management server, see Configuring cryptography settings on the management server.

Security modes for the managed servers​

This setting determines the mode to use for secure communications from the managed servers.

  • Compatibility Security. Select this mode when services and clients require cryptography that is not CNSA/FIPS compliant. This mode supports a wide range of cryptography algorithms and allows all services to be enabled.

  • NIST SP 800-131A. Select this mode to ensure compliance with the NIST SP 800-131A standard. This includes restricting RSA keys to 2048 bits or greater, restricting hashes used for digital signatures to SHA-256 or longer, and ensuring only NIST-approved symmetric encryptions algorithms are used. This mode requires setting SSL/TLS mode to TLS 1.2 Server Client.

    This mode is not supported for servers with XCC2.

  • Standard Security. (Servers with XCC2 only) This is the default security mode for servers with XCC2. Select this mode to ensure compliance with the FIPS 140-3 standard. For XCC to operate in FIPS 140-3 validated mode, only services that support FIPS 140-3 level cryptography can be enabled. Services that do not support FIPS 140-2/140-3 level cryptography are disabled by default but can be enabled if required. If any service that uses non FIPS 140-3 level cryptography is enabled, the XCC cannot operate in FIPS 140-3 validated mode. This mode requires FIPs-level certificates.

  • Enterprise Strict Security. (servers with XCC2 only) This is the most secure mode. Select this mode to ensure compliance with the CNSA standard. Only services that support CNSA level cryptography are allowed. Nonsecure services are disabled by default and cannot be enabled. This mode requires CNSA-level certificates.

    XClarity Administrator uses RSA-3072/SHA-384 certificate signatures for servers in Enterprise Strict Security mode.

    Important

    • The XCC2 Feature On Demand key must be installed on each selected servers with XCC2 to use this mode.

    • In this mode, if XClarity Administrator uses self-signed certificate, XClarity Administrator must use RSA3072/SHA384 based root certificate and server certificate. If XClarity Administrator uses an external signed certificate, XClarity Administrator must generate an RSA3072/SHA384 based CSR and contact the external CA to sign a new server certificate based on RSA3072/SHA384.

    • When XClarity Administrator uses an RSA3072/SHA384 based certificate, XClarity Administrator might disconnect devices other than Flex System chassis (CMMS) and servers, ThinkSystem servers, ThinkServer servers, System x M4 and M5 servers, Lenovo ThinkSystem DB series switches, Lenovo RackSwitch, Flex System switches, Mellanox switches, ThinkSystem DE/DM storage devices, IBM tape library storage, and ThinkSystem SR635/SR655 servers flashed with firmware earlier than 22C. To continue managing the disconnected devices, set up another XClarity Administrator instance with an RSA2048/SHA384 based certificate.

Consider the following implications of changing the cryptographic mode.

  • Changing from Compatibility Security mode or Standard Security mode to Enterprise Strict Security mode is not supported.

  • If you upgrade from Compatibility Security mode to Standard Security mode, you are warned if imported certificates or SSH public keys are not compliant, but you are still able to upgrade to Standard Security mode.

  • If you downgrade from Enterprise Strict Security mode to Compatibility Security mode or Standard Security mode:

    • The server is automatically restarted for the security mode to take effect.

    • If the strict mode FoD key is missing or expired on the XCC2, and if XCC2 uses a self-signed TLS certificate, XCC2 regenerates the self-signed TLS certificate based on the Standard Strict compliant algorithm. XClarity Administrator shows a connection failure due to a certificate error. To resolve the untrusted certificate error, see Resolving an untrusted server certificate. If XCC2 uses a custom TLS certificate, XCC2 allows the downgrade, and warns you that you need to import a server certificate that is based on Standard Security mode cryptography

  • NIST SP 800-131A mode is not supported for servers with XCC2.
  • You cannot use managed authentication to manage a ThinkSystem or ThinkAgile server when the XCC’s security mode set to TLS v1.3.
  • For a ThinkSystem or ThinkAgile server that is managed using managed authentication, changing the XCC’s security mode to TLS v1.3 using either XClarity Administrator or XCC will cause the server to go offline.
You can change the security settings for the following devices.
  • Lenovo ThinkSystem servers with Intel or AMD processors (except SR635 / SR655)
  • Lenovo ThinkSystem V2 servers
  • Lenovo ThinkSystem V3 servers with Intel or AMD processors
  • Lenovo ThinkEdge SE350 / SE450 servers
  • Lenovo System x servers

For more information about setting the security modes on the managed server, see Configuring the security settings for a managed server.