Search <book_title>...

InfoScale™ 9.0 Storage Foundation Cluster File System High Availability Configuration and Upgrade Guide - Linux

Last Published: 2025-08-11

Product(s): InfoScale & Storage Foundation (9.0)

Platform: Linux

Generating the key and certificates manually for the CP server

CP server uses the HTTPS protocol to establish secure communication with client nodes. HTTPS is a secure means of communication, which happens over a secure communication channel that is established using the SSL/TLS protocol.

HTTPS uses x509 standard certificates and the constructs from a Public Key Infrastructure (PKI) to establish secure communication between the CP server and client. Similar to a PKI, the CP server, and its clients have their own set of certificates signed by a Certification Authority (CA). The server and its clients trust the certificate.

Every CP server acts as a certification authority for itself and for all its client nodes. The CP server has its own CA key and CA certificate and a server certificate generated, which is generated from a server private key. The server certificate is issued to the Universally Unique Identifier (UUID) of the CP server. All the IP addresses or domain names that the CP server listens on are mentioned in the Subject Alternative Name section of the CP server's server certificate

The OpenSSL library must be installed on the CP server to create the keys or certificates.. If OpenSSL is not installed, then you cannot create keys or certificates. The vxcps.conf file points to the configuration file that determines which keys or certificates are used by the CP server when SSL is initialized. The configuration value is stored in the ssl_conf_file and the default value is /etc/vxcps_ssl.properties.

To manually generate keys and certificates for the CP server:

Create directories for the security files on the CP server.
# mkdir -p /var/VRTScps/security/keys /var/VRTScps/security/certs
Generate an OpenSSL config file, which includes the VIPs.
The CP server listens to requests from client nodes on these VIPs. The server certificate includes VIPs, FQDNs, and host name of the CP server. Clients can reach the CP server by using any of these values. However, Arctera recommends that client nodes use the IP address to communicate to the CP server.
The sample configuration uses the following values:
- Config file name: https_ssl_cert.conf
- VIP: 192.168.1.201
- FQDN: cpsone.company.com
- Host name: cpsone
Note the IP address, VIP, and FQDN values used in the [alt_names] section of the configuration file are sample values. Replace the sample values with your configuration values. Do not change the rest of the values in the configuration file.
```
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = US
localityName = Locality Name (eg, city)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 40

[v3_req] 
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = cpsone.company.com
DNS.2 = cpsone
DNS.3 = 192.168.1.201 
```
Generate a 4096-bit CA key that is used to create the CA certificate.
The key must be stored at /var/VRTScps/security/keys/ca.key. Ensure that only root users can access the CA key, as the key can be misused to create fake certificates and compromise security.
# /opt/VRTSperl/non-perl-libs/bin/openssl genrsa -out /var/VRTScps/security/keys/ca.key 4096
Generate a self-signed CA certificate.
# /opt/VRTSperl/non-perl-libs/bin/openssl req -new -x509 -days days -sha256 -key /var/VRTScps/security/keys/ca.key -subj \
'/C=countryname/L=localityname/OU=COMPANY/CN=CACERT' -out \
/var/VRTScps/security/certs/ca.crt
Where, days is the days you want the certificate to remain valid, countryname is the name of the country, localityname is the city, CACERT is the certificate name.
Generate a 2048-bit private key for CP server.
The key must be stored at /var/VRTScps/security/keys/server_private key.
# /opt/VRTSperl/non-perl-libs/bin/openssl genrsa -out \
/var/VRTScps/security/keys/server_private.key 2048
Generate a Certificate Signing Request (CSR) for the server certificate.
The Certified Name (CN) in the certificate is the UUID of the CP server.
# /opt/VRTSperl/non-perl-libs/bin/openssl req -new -sha256 -key /var/VRTScps/security/keys/server_private.key \
-config https_ssl_cert.conf -subj \
'/C=CountryName/L=LocalityName/OU=COMPANY/CN=UUID' \
-out /var/VRTScps/security/certs/server.csr
Where, countryname is the name of the country, localityname is the city, UUID is the certificate name.
Generate the server certificate by using the key certificate of the CA.
# /opt/VRTSperl/non-perl-libs/bin/openssl x509 -req -days days -sha256 -in /var/VRTScps/security/certs/server.csr \
-CA /var/VRTScps/security/certs/ca.crt -CAkey \
/var/VRTScps/security/keys/ca.key \
-set_serial 01 -extensions v3_req -extfile https_ssl_cert.conf \
-out /var/VRTScps/security/certs/server.crt
Where, days is the days you want the certificate to remain valid, https_ssl_cert.conf is the configuration file name.
You successfully created the key and certificate required for the CP server.
Ensure that no other user except the root user can read the keys and certificates.
Complete the CP server configuration.

More Information

Completing the CP server configuration