GSKit commands

If you are not using SSH for remote installation and configuration of IBM® Storage Protect Snapshot on backup and cloning systems, use GSKit commands to manually import a self-signed certificate. If you decide to use a CA signed certificate, use GSKit commands to complete a manual setup.

Manually importing the self-signed certificate

The self-signed certificate is automatically created by IBM Storage Protect Snapshot. When the IBM Storage Protect Snapshot setup script is run on the production server, it automatically creates the fcmselfcert.arm file. It is stored on the production server in the default installation path. The fcmselfcert.arm file is automatically imported on the backup and cloning servers from the production server with the SSH remote deployment mechanisms of the setup script. When remote deployment is not used and you separately run the setup script on the backup or cloning server, the fcmselfcert.arm file if present is automatically imported to the local key database and then deleted. To use this automation, copy the fcmselfcert.arm file from the production server to either the backup or cloning server before you start the setup routines on the backup or cloning server.

Alternatively, you can import the self-signed certificate by using the following GSKit command. However, in most scenarios this step is not necessary as the file is automatically imported as part of the IBM Storage Protect Snapshot setup process.
gsk8capicmd_64 -cert -add -db fcmcert.kdb  -stashed -label "FCM server 
certificate" -file <path to fcmselfcert.arm>  -format ascii
This command fails if the key database already contains a certificate with the label FCM server certificate. To remove the certificate with the label FCM server certificate, you can use the following command:
gsk8capicmd_64 -cert -delete -db fcmcert.kdb  -stashed -label "FCM server 
certificate"

CA Certificate

You can use a CA signed certificate for IBM Storage Protect Snapshot. If the certificate that is assigned by a CA has no built-in GSKit support, import the CA root certificate into the key database file (fcmcert.kdb). Use the GSKit command-line utilities to update the file on the production system, the backup system, and the cloning system. The root certificate of a trusted CA certificate is in the key database. GSKit has the following trusted root certificates:
  • Entrust.net Global Secure Server Certification Authority
  • Entrust.net Global Client Certification Authority
  • Entrust.net Client Certification Authority
  • Entrust.net Certification Authority (2048)
  • Entrust.net Secure Server Certification Authority
  • VeriSign Class 3 Public Primary Certification Authority
  • VeriSign Class 2 Public Primary Certification Authority
  • VeriSign Class 1 Public Primary Certification Authority
  • VeriSign Class 4 Public Primary Certification Authority - G2
  • VeriSign Class 3 Public Primary Certification Authority - G2
  • VeriSign Class 2 Public Primary Certification Authority - G2
  • VeriSign Class 1 Public Primary Certification Authority - G2
  • VeriSign Class 4 Public Primary Certification Authority - G3
  • VeriSign Class 3 Public Primary Certification Authority - G3
  • VeriSign Class 2 Public Primary Certification Authority - G3
  • VeriSign Class 1 Public Primary Certification Authority - G3
  • Thawte Personal Premium CA
  • Thawte Personal Freemail CA
  • Thawte Personal Basic CA
  • Thawte Premium Server CA
  • Thawte Server CA
  • RSA Secure Server Certification Authority
  • Secure Server Certification Authority
The following example shows the command to request that a CA signed certificate is included:
gsk8capicmd_64 -certreq -create -db fcmcert.kdb -stashed -label "FCM server 
certificate request" -dn dist_name  -target fcmservcertreq.arm
For SP800-131 compliance, when the ENFORCE_TLS12 parameter is set to YES in the IBM Storage Protect Snapshot profile, ensure that the certificate meets the minimum requirement by adding the following two options:
  • -size 2048 (or higher)
  • -sigalg sha224 (or higher)
Note: IBM Storage Protect Snapshot creates a self-signed certificate that is signed with SHA512, and the size is 4086 bits.
The label parameter can have any value except FCM server certificate. This value is already used by the self-signed certificate in the key database.
When you use a certificate that is signed by a CA that has no built-in GSKit support, you must import the CA root certificate. This task must be completed before the certificate is received or imported. The CA root certificate must be imported into the key database (KDB) files on the production system. The CA root certificate must also be imported into the KDB files on the backup and cloning servers. Issue the following command to import the root certificate:
gsk8capicmd_64 -cert -add -db fcmcert.kdb  -stashed -label "FCM server certificate 
request" -file path to CARootCertificate.arm
Issue the following command to import a signed certificate when it is received from a CA:
gsk8capicmd_64 -cert -receive -file fcmservcertsigned.arm -db fcmcert.kdb
 -stashed 
Rename the CA signed certificate label to FCM server certificate. Usually, the key database still contains the self-signed certificate, it must be deleted before the CA signed certificate can be renamed. To remove the self-signed certificate from the key database, issue the following command:
gsk8capicmd_64 -cert -delete -db fcmcert.kdb  -stashed -label "FCM server 
	certificate"
To rename the CA signed certificate issue the following command:
gsk8capicmd_64 -cert -rename -db fcmcert.kdb -stashed -label 
"FCM server certificate request" -new_label "FCM server certificate"
The file fcmselfcert.arm is used to export the self-signed certificate. When you use a CA certificate, the .arm file is obsolete and must be deleted on the production system. The self-signed certificate is automatically removed from the key database on the backup or cloning system during the next remote update with the setup script. If remote deployment is not used, you can manually remove the self-signed certificate from the key database on the backup and cloning servers. To remove the self-signed certificate, issue the following command:
gsk8capicmd_64 -cert -delete -db fcmcert.kdb -stashed -label "FCM server 
	certificate"

Monitoring the expiry date of certificates

When a self-signed certificate is created, an expiry date can be specified. The expiration time of the certificate is specified in days. The default is 365 days. The duration is 1-7300 days (20 years). The IBM Storage Protect Snapshot setup script creates the self-signed certificate for the production, backup, and cloning servers. The expiration time of all self-signed certificates that is generated by the setup script is 20 years. If you are using CA signed certificates, the expiration date is set by the certificate authority. You must monitor certificates for expiry and remove any expired certificates. If the key database does not contain a valid certificate with the label FCM server certificate and the setup script is rerun, a new self-signed certificate is generated. The.kdb, .rdb, .arm and .sth files are rewritten.