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
- 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.
- 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, key servers (Generic KMIP servers such as Thales CipherTrust Manager), 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.
- 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 Internal communication (only Internally signed), based on the use case value 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
- System certificate scope values
-
The ID and scope values of system certificate are mentioned as follows:
- 0: default
- This type of certificate is primarily used as web browser certificate. You can also use this certificate for key server and other use cases.
- 1: keyserver
- This type of certificate is used as key server certificate. This certificate is presented to the key servers.
- 3: internal_communication
- This type of certificate is used for internal communication purpose, such as certificate for FlashSystem grid and partnership with remote system (policy-based replication or policy-based high availability).