System Certificates

You can manage the system certificate to secure connections between systems or applications across networks using management GUI or command line interface (CLI).

About this task

Before you create system certificates, determine how certificates are signed based on your current security requirements. The system supports the following ways to sign system certificates:
Self-signed certificate
In 8.5.3.0, self-signed certificates are no longer created by default. After an update to 8.5.3.0 or later, the current self-signed certificate is usable until it expires. Before the self-signed certificate expires, you must update the system certificate to either an internally signed certificate or an externally signed certificate.
Internally signed certificate
The system has a root certificate authority (CA) that can be used to create internally signed system certificates. In 8.5.3.0 or later, system setup creates a certificate that is signed by the root CA to secure connections between the management GUI and the browser. The root certificate can be exported from the system and added to truststores on other systems, browsers, or devices to establish trust. Internally signed certificates can be renewed automatically before they expire. Automatic renewal simplifies the certificate renewal process and prevents security warnings from expired certificates. Automatic renewal is only supported by using an internally signed certificate.
Externally signed certificate
Externally signed certificates are issued and signed by a trusted third-party provider of certificates, called an external certificate authority (CA). This CA can be a public CA or your own organization's CA. Most web browsers trust well-known public CAs and include the root certificate for these CAs in the device or application. Externally signed certificates cannot be renewed automatically because they must be issued by the external CA. Externally signed certificates must be manually updated before they expire by creating a new certificate signing request (CSR) on the system and supplying it to the CA. The CA signs the request and issues a certificate that must be installed on the system. The system raises a warning in the event log 30 days before the certificate expires.
Consider the following additional information about certificates:
Root certificate

From version 8.5.3.0, IBM Storage Virtualize has a root certificate authority that can be used to generate system certificates. The root CA is generated during the first boot on 8.5.3.0 and is shared between all nodes in the clustered system. The root CA cannot be modified by the user.

The root certificate can be exported from the system and added to truststores for web browsers, Thales CipherTrust Manager key servers, and other devices and applications that support chain of trust checking. If chain of trust checking is supported, then the signed system certificate can be renewed and does not need to be exported.

The root certificate can be identified by its subject and issuer distinguished name:
  • O represents International Business Machines Corporation.
  • OU represents IBM Storage Virtualize Root CA.
  • CN represents serial number, for example, 1234567. The common name (CN) field is the enclosure serial number of the configuration node that generated the certificate.

The root certificate is valid for 20 years and uses a 4096-bit RSA key pair.

After the first system upgrade to 8.5.3.0 (or later), the system continues to use its current certificate (either self-signed or externally signed) until a new certificate is generated.

System certificate
The system certificate is signed by the system's root CA, a trusted third-party CA, or is self-signed. This certificate is presented to other devices such as web browsers, key servers, or partner systems in IP partnerships, to authenticate the system and create a secure connection.
The system certificate supports the following key types:
  • RSA 4096
  • RSA 2048
  • ECDSA 521
  • ECDSA 384
SSL protocol level 4 restricts the use of RSA key exchange cipher suites. Therefore, you cannot enable SSL protocol level 4 when using a certificate with an RSA key. Likewise, you cannot generate a certificate with an RSA key if SSL protocol level 4 is set.
Note:

  • Multifactor Authentication with IBM® Security Verify uses the system certificate to sign JSON web tokens (JWTs). The system certificate must be exported and added as a signer certificate in the IBM Security Verify interface. If the system certificate expires or is renewed, access to the management GUI will be unavailable until the new system certificate is installed in IBM Security Verify. A user must use the CLI to log in to the system to export the new system certificate and install it in IBM Security Verify.

  • IBM Security Guardium® Key Lifecycle Manager key servers do not currently support chain of trust checking with IBM Storage Virtualize. The system certificate must be installed on the IBM Security Guardium Key Lifecycle Manager key servers in order to establish a connection. If the system certificate is expired or renewed, then the new system certificate must be installed on the key servers in order for IBM Storage Virtualize to establish a connection with the key servers. Access to encrypted storage is not disrupted while the connection to the key servers is unavailable, unless all nodes in the clustered system are powered off and on at the same time.

During system setup, an initial certificate is created to use for secure connections between web browsers. This certificate is signed by the system's root CA. A new certificate should be generated which includes the relevant DNS or IP entries for the system in the Subject Alternate Name field. The System Certificates page in the management GUI suggests the DNS names if a DNS server is added to the system. If a DNS server is not added, then the management GUI suggests the IP addresses.