Renewing expired client certificates

Follow these instructions to create and renew expired client certificates for the simplified setup, the regular setup, or the setup for Thales Vormetric Data Security Manager (DSM).

See the following subtopics:

Simplified setup: Updating a key client certificate (5.1.0 or later)
Simplified setup: Updating a key client certificate (5.0.5)
Simplified setup: Updating a key client certificate (earlier than 5.0.5)
Regular setup or DSM setup: Creating and installing a new key client
Regular setup: Trusting a new client certificate
DSM: Trusting a new client certificate

Note: For more information about the simplified setup method, see the following topics:

For more information about the regular setup method or the setup for DSM, see the following topics:

Simplified setup: Updating a key client certificate (5.1.0 or later)

Follow these instructions if you are using the simplified setup method and the key client is running IBM Spectrum Scale 5.1.0 or later.

To update an expired or unexpired key client certificate, follow these steps.

Issue the mmkeyserv client show command and verify the type of the current client certificate. If the type is system-generated, then the certificate is a self-signed certificate that was generated by the system. If the type is user-provided, the certificate is a CA-signed certificate. In the following example, the final line indicates that the certificate is user-provided:
```
# mmkeyserv client show
    c34f2n03Client1
        Label:                            c6f2bc3n9client
        Key Server:                       keyserver01.gpfs.net
        Tenants:                          devG1
        Certificate Expiration:           2020-09-04 22:40:41 (-0400)
        Certificate Type:                 user-provided
```

If the certificate type is system-generated, go to Step 2.
If the certificate type is user-provided, go to Step 3.

This step describes the actions to take if the type of the certificate to be replaced is system-generated:

If you want to replace the current system-generated self-signed certificate with another system-generated self-signed certificate, issue the mmkeyserv client update command with an expire time for the new certificate. You must specify a password file that contains the key server password, an expire time, and a password file that contains a new password for the client keystore. In the following example the expire time is 90 days:

# mmkeyserv client update c6f2bc3n9client --server-pwd /root/c6f2bc3n9.pw --days 90 --keystore-pwd /root/client.pw
    mmkeyserv: [I] Client currently does not have access to the key. Continue the registration process ...
    mmkeyserv: Successfully accepted client certificate
    mmkeyserv: Propagating the cluster configuration data to all affected nodes. This is an asynchronous process.
    mmkeyserv: Deleting the following KMIP certificate with label: 2454534160085868372_vut_1578295912
    Fri Sep 18 12:01:33 EST 2020: mmcommon pushSdr_async: mmsdrfs propagation started
    # Fri Sep 18 12:01:36 EST 2020: mmcommon pushSdr_async:
        mmsdrfs propagation completed; mmdsh rc=0

If you want to replace the current system-generated self-signed certificate with a CA-signed certificate, issue the mmkeyserv client update command and specify the CA-signed certificate information. In the following example, the client CA-signed certificate file is /tmp/client.cert, the client private key file is /tmp/client.key, and the CA certificate chain file is /tmp/CA-chain:

# mmkeyserv client update c6f2bc3n9client --cert /tmp/client.cert --priv /tmp/client.key --ca-chain /tmp/CA-chain --server-pwd /root/c6f2bc3n9.pw --keystore-pwd /root/client.pw 
mmkeyserv: [I] Client currently does not have access to the key. Continue the registration process ... 
mmkeyserv: Successfully accepted client certificate 
mmkeyserv: Propagating the cluster configuration data to all affected nodes. This is an asynchronous process.
mmkeyserv: Deleting the following KMIP certificate with label: 2454534160085868372_vut_1600467545 
Fri Sep 18 12:19:35 EST 2020: mmcommon pushSdr_async: mmsdrfs propagation started 
(12:19:38) c9f1u19p1:~ # Fri Sep 18 12:19:38 EST 2020: mmcommon pushSdr_async: 
    mmsdrfs propagation completed; mmdsh rc=0

The mmkeyserv client update command deregisters the key client with the current certificate from any tenants that it is registered to and deletes the key client. The command then creates a new key client with the same name as the old one, creates a new self-signed client certificate or uses the new CA-signed client certificate, and stores the new client certificate into the client keystore. Finally, the command registers the new key client with any tenants that the old key client was registered to.

Go to Step 4.

This step describes the actions to take if the type of the certificate to be replaced is a user-provided CA-signed certificate:

If you want to replace the current user-provided CA-signed certificate with a system-generated self-signed certificate, you must issue the mmkeyserv client update command with the --force option. The following example is exactly like the command that is used to replace the system-generated self-signed certificate in Step 2, except that here you must specify the --force option because you are replacing a CA-signed certificate:

# mmkeyserv client update c6f2bc3n9client --server-pwd /root/c6f2bc3n9.pw --days 90 --keystore-pwd /root/client.pw --force
    mmkeyserv: [I] Client currently does not have access to the key. Continue the registration process ...
    mmkeyserv: Successfully accepted client certificate
    mmkeyserv: Propagating the cluster configuration data to all affected nodes. This is an asynchronous process.
    mmkeyserv: Deleting the following KMIP certificate with label: 2454534160085868372_vut_1578295912
    Fri Sep 18 12:01:33 EST 2020: mmcommon pushSdr_async: mmsdrfs propagation started
    # Fri Sep 18 12:01:36 EST 2020: mmcommon pushSdr_async:
        mmsdrfs propagation completed; mmdsh rc=0

If you do not specify the --force option, the command displays an error message, as in the following example:

#mmkeyserv client update c6f2bc3n9client --server-pwd /root/c6f2bc3n9.pw --days 90 --keystore-pwd /root/client.pw
    mmkeyserv: Client c6f2bc3n9client was initially created using a user-provided certificate.
      Provide a new client certificate with the --cert option or use the --force
      option to generate a new self-signed certificate for the client.

    mmkeyserv: Command failed. Examine previous error messages to determine cause.

If you want to replace the current user-provided CA-signed certificate with another CA-signed certificate, issue the mmkeyserv client update command and specify the CA-signed certificate information. You do not have to specify the --force option because you are replacing the CA-signed certificate with another CA-signed certificate. In the following example, the client CA-signed certificate file is /tmp/client.cert, the client private key file is /tmp/client.key, and the CA certificate chain file is /tmp/CA-chain:

# mmkeyserv client update c6f2bc3n9client --cert /tmp/client.cert --priv /tmp/client.key --ca-chain /tmp/CA-chain --server-pwd /root/c6f2bc3n9.pw --keystore-pwd /root/client.pw 
mmkeyserv: [I] Client currently does not have access to the key. Continue the registration process ... 
mmkeyserv: Successfully accepted client certificate 
mmkeyserv: Propagating the cluster configuration data to all affected nodes. This is an asynchronous process.
mmkeyserv: Deleting the following KMIP certificate with label: 2454534160085868372_vut_1600467545 
Fri Sep 18 12:19:35 EST 2020: mmcommon pushSdr_async: mmsdrfs propagation started 
(12:19:38) c9f1u19p1:~ # Fri Sep 18 12:19:38 EST 2020: mmcommon pushSdr_async: 
    mmsdrfs propagation completed; mmdsh rc=0

The mmkeyserv client update command does the same actions that are described in the last paragraph of Step 2.

Issue the mmkeyserv client show command and verify the new client certificate expiration date.

For more information, see mmkeyserv command.

The new client certificate is accepted by the SKLM key server. The new key client is registered with any tenants that the old key client was registered to.

Simplified setup: Updating a key client certificate (5.0.5)

Start of change Follow these instructions if you are using the simplified setup method and the key client is running IBM Spectrum Scale 5.0.5. End of change

To update an expired or unexpired key client certificate, follow these steps:

Issue the mmkeyserv client show command and verify the information that is displayed about the key client whose certificate is expired. In the following example only one key client exists in the cluster:

# mmkeyserv client show
c34f2n03Client1
        Label:                   c6f2bc3n9client
        Key Server:              keyserver01.gpfs.net
        Tenants:                 devG1
        Certificate Expiration:  2020-10-01 14:20:46 (-0400)

Issue the mmkeyserv client update command to create a new client certificate to replace the existing one. The command deregisters the key client with the existing certificate from any tenants that it is registered to and deletes the key client. The command then creates a new key client with the same name as the old one, creates a new client certificate, and stores the new client certificate into the client keystore. Finally, the command registers the new key client with any tenants that the old key client was registered to.
In the following example, the command provides the following a password file that contains the key server password. It also specifies an expire time of 90 days for the new client certificate and provides a password file that contains a new password for the client keystore:

In the following example,
```
# mmkeyserv client update c6f2bc3n9client --server-pwd /u/admin/README/sklm/c6f2bc3n9.pw
        --days 90 --keystore-pwd /u/admin/README/sklm/client.pw
    mmkeyserv: [I] Client currently does not have access to the key. Continue the registration
        process ...
    mmkeyserv: Successfully accepted client certificate
    mmkeyserv: Propagating the cluster configuration data to all affected nodes. This is an
        asynchronous process.
    mmkeyserv: Deleting the following KMIP certificate with label:
        2454534160085868372_vut_1578295912
    Mon Jan 6 12:06:33 EST 2020: mmcommon pushSdr_async: mmsdrfs propagation started
    (12:06:35) c9f1u19p1:~ # Mon Jan 6 12:06:36 EST 2020: mmcommon pushSdr_async:
        mmsdrfs propagation completed; mmdsh rc=0
 
```
Issue the mmkeyserv client show command and verify the new client certificate expiration date.

For more information, see mmkeyserv command.

The new client certificate is accepted by the SKLM key server. The new key client is registered with any tenants that the old key client was registered to.

Simplified setup: Updating a key client certificate (earlier than 5.0.5)

Follow these instructions if you are using the simplified setup method and the key client is running a version of IBM Spectrum Scale that is earlier than 5.0.5.

To update an expired or unexpired key client certificate, you must create and register a new key client and deregister the old key client. These instructions assume that you want to create a key client c1Client1, deregister the old client c1Client0, and register the new key client with tenant devG1 on key server keyserver01.

Issue the following command to create the key client. Enter a password and a pass phrase when prompted:

# mmkeyserv client create c1Client1 --server keyserver01
Enter password for the key server keyserver01:
Create a pass phrase for keystore:
Confirm your pass phrase:

Issue the following command to display information about the current clients.

The command output shows that the existing client c1Client0, which has the expired certificate, is registered with tenant devG1 on key server keyserver01. The new client c1Client1 is not registered with a tenant:

# mmkeyserv client show
c1Client0
        Label:                   c1Client0
        Key Server:              keyserver01
        Tenants:                 devG1
        Certificate expiration:  2023-04-22 15:41:21 (-0400)

c1Client1
        Label:                   c1Client1
        Key Server:              keyserver01
        Tenants:                 (none)
        Certificate expiration:  2023-04-22 15:41:21 (-0400)

Optional: Issue the following command and make a note of the RKM ID that is associated with the old key client.
It is a good idea to reuse the RKM ID of the old key client when you register the new key client. If you do so, then you do not have to update any of your encryption policy rules that specify the RKM ID:
```
# mmkeyserv tenant show
devG1
        Key Server:          keyserver01.gpfs.net
        Registered Client:   c1Client0
        RKM ID:              keyserver01_devG1
```
See Step 5.
Issue the following command to deregister the current key client from the tenant. Notice that this command also deletes the expired certificate:
```
# mmkeyserv client deregister c1Client0 --tenant devG1 
Enter password for the key server:
Enter password for the key server of client c1Client0: 
mmkeyserv: Deleting the following KMIP certificate with label: 
15826749741870337947_devG1_1498047851
```
Note: If you deregister a key client whose certificate is not yet expired, you cannot fetch keys until you register a new key client:
Issue the following command to register the new key client with tenant devG1 in key server keyserver01.
In the --rkm-id parameter, specify a valid RKM ID for the new connection.
Note: Here you can specify the RKM ID of the old key client to avoid having to update encryption policy rules that reference that RKM ID. See Step 3.
```
# mmkeyserv client register c1Client1 --tenant devG1 --rkm-id keyserver01_devG1
Enter password for the key server:
mmkeyserv: [I] Client currently does not have access to the key.  
Continue the registration process ...
mmkeyserv: Successfully accepted client certificate
```
For more information, see mmkeyserv command.

The new client certificate is accepted by the SKLM key server. The new key client is registered with tenant devG1.

Regular setup or DSM setup: Creating and installing a new key client

Follow these instructions if you are using either the regular setup method with an SKLM key server or the regular setup with a DSM key server. To update an expired or unexpired client certificate, follow these steps:

Note: The mmgskkm command and the msklmconfig command are available in IBM Spectrum Scale 4.2.1 and later.

Create a keystore password file that is accessible only by the root user, such as /root/keystore.pwd, and store a password in it.
The next step depends on the type of client certificate that you want to use:
- If you want to create a key client with a system-generated self-signed certificate, go to Step 3.
- If you want to create a key client with a user-provided CA-signed certificate, go to Step 4.

This step describes the actions to take if you are creating key client with a system-generated self-signed certificate.
1. Issue the mmgskkm gen command to create the new client credentials:
```
mmgskkm gen --prefix <prefix> --cname <cname> --fips <fips> 
--nist <nist> --days <validdays> --keylen <keylen>
```
  where:
  --prefix <prefix>
  
  Is the path and file name prefix of the new certificate files and keystore file.
  
  --cname <cname>
  
  Is the name of the new IBM Spectrum Scale key client. The name can be up to 54 characters in length and can contain alphanumeric characters, hyphen (-), and period (.). In DSM, names are not case-sensitive, so it is a good practice not to include uppercase letters.
  
  --fips <fips>
  Is the current value of the FIPS1402mode configuration variable in IBM Spectrum Scale. Valid values are yes and no. Issue the following command to see the current value:
  mmlsconfig FIPS1402mode
  --nist <nist>
  Is the current value of the nistCompliance configuration variable in IBM Spectrum Scale. Valid values are SP800-131A and off. To see the current value, issue the following command:
  mmlsconfig nistCompliance
  --days <validdays>
  
  Is the number of days that you want the client certificate to be valid.
  
  --keylen <keylen>
  
  Is the length in bits that you want for the RSA key that is generated.
2. Issue the mmgskkm store command to create a PKCS#12 keystore and to store the system-generated client certificate and private key into it.
```
mmgskkm store --cert <certFile> --priv <privFile> --label <label> --pwd-file <pwd-file> --out <keystore>
```
  where:
  
  --cert <certFile>
  
  Is the client certificate file that you created in Step 3(a). The name of the file has the format <prefix>.cert, where <prefix> is the path and file name prefix that you specified in Step 3(a).
  
  --priv <privFile>
  
  Is the private key file that you generated in Step 3(a). The name of the file has the format <prefix>.priv, where <prefix> is the path and file name prefix that you specified in Step 3(a).
  
  --label <label>
  
  Is the label under which the new client certificate is stored in the keystore.
  
  --pwd-file <pwd-file>
  
  Is the path and file name of the keystore password file that you created in Step 1.
  
  --out <keystore>
  
  Is the path and file name of the new PKCS#12 keystore.
  Note: It is a good practice to generate the keystore files into the directory /var/mmfs/etc/RKMcerts.
3. Go to Step 5.
This step describes the actions to take if you are creating a key client with a user-provided CA-signed certificate.
1. Obtain the CA-signed certificate files from a CA.
2. Issue the mmgskkm store command to create a PKCS#12 keystore and to store the user-provided CA-signed client certificate and private key into it.
```
mmgskkm store —cert <certFile> —priv <privFile> { —chain <CACertChainFile> | —prefix <CACertPrefix> } —label <label> —pwd-file <pwdFile> —out <keystore>
```
  where:
  
  --cert <certFile>
  
  Is the CA signed client certificate file in base64 encoded PEM format.
  
  --priv <privFile>
  
  Is the client’s private key file in base64 encoded PEM format, unencrypted.
  
  { —chain <CACertChainFile> | —prefix <CACertPrefix> }
  
  Is the client credentials. Choose one of the following parameters:
  
  —chain <CACertChainFile>
  
  Is the CA certificate chain file that contains all the CA certificates, beginning with the root CA certificate and ending with the last intermediate CA certificate that signed the client certificate.
  
  —prefix <CACertPrefix>
  
  Is the full path prefix of the CA certificate files, named <CACertPrefix><index>.cert, where <index> is 0 for the root CA certificate and the last index is the last intermediate CA certificate that signed the client certificate.
  
  --label <label>
  
  Is the label under which the new client certificate is stored in the keystore.
  
  --pwd-file <pwd-file>
  
  Is the path and file name of the keystore password file that you created in Step 1.
  
  --out <keystore>
  
  Is the path and file name of the new PKCS#12 keystore.
  For more information, see one of the following topics:
  - Regular setup: Using SKLM with a certificate chain
  - Configuring encryption with the Thales Vormetric DSM key server
The next step depend on the type of certificate that the SKLM server is using:
- If the SKLM server certificate is running with a self-signed certificate, go to Step 6.
- If the SKLM server is running with a CA-signed certificate chain, go to Step 7.
This step describes the actions to take if the SKLM server is running with a self-signed certificate.
1. Issue the mmsklmconfig command to retrieve the server certificate and add it to the client keystore:
```
mmsklmconfig restcert --host <rkmHost> --port <rkmPort> --prefix <serverPrefix> --keystore <keystore> 
--keypass <pwd-file> --fips <fips> --nist <nist>
```
  The command includes the following parameters:
  --host <rkmHost>
  
  Is the IP address or host name of the RKM server.
  
  --port <rkmPort>
  Is the port of the RKM server:
  
  For SKLM, the port is the KMIP port, which has a default value of 5696.
  
  For DSM, the port is the web GUI port, which has a default value of 8445.
  --prefix <serverPrefix>
  
  Is the path and file name prefix for the server certificate.
  
  --keystore <keystore>
  
  Is the path and file name of the PKCS#12 keystore that you created in Step 3(a).
  
  --keypass <pwd-file>
  
  Is the path and file name of the keystore password file that you created in Step 1.
  
  --fips <fips>
  Is the current value of the FIPS1402mode configuration variable in IBM Spectrum Scale. Valid values are yes and no. Issue the following command to see the current value:
  mmlsconfig FIPS1402mode
  --nist <nist>
  Is the current value of the nistCompliance configuration variable in IBM Spectrum Scale. Valid values are SP800-131A and off. To see the current value, issue the following command:
  mmlsconfig nistCompliance
2. Optional: Issue the following command to display the certificate file that you downloaded in Step 6(a). Verify that the information matches the information that is displayed for the current server certificate in the RKM GUI:
```
mmgskkm print --cert <serverPrefix>0.cert
```
  where serverPrefix is the path and file name prefix of the server certificate that you specified in Step 6(a).
3. Update the RKM stanza for the new client credentials in the /var/mmfs/etc/RKM.conf file. Make sure that the following values are correct:
  - The keyStore term specifies the path and file name of the client keystore that you created in Step 3(b).
  - The passphrase term specifies the keystore password from Step 1.
  - The clientCertLabel term specifies the label of the new client certificate from Step 3(b).
4. Go to Step 8.
This step describes the actions to take if the SKLM server is running with a CA-signed certificate chain.
1. Gather the files of the server certificate chain into location that is accessible to the key client:
  1. If you previously saved the certificate files of the server certificate chain into a secure location, ensure that the server certificate chain files are accessible by the key client node. For more information, see Regular setup: Using SKLM with a certificate chain.
    If you did not previously save the files of the server certificate chain, follow these steps:
    
    Manually copy the files of the server certificate chain from the SKLM server to a location that is accessible from the key client.
    
    Make backup copies of the server certificate files, in case they are lost or damaged.
  2. Rename each certificate file with the same prefix, followed by a numeral that indicates the order of the certificate in the chain, followed by the file extension .cert. Start the numbering with 0 for the root certificate. For example, if the chain consists of three certificate files and the prefix is sklmChain, rename the files as follows:
```
sklmChain0.cert
sklmChain1.cert
sklmChain2.cert
```
2. Optional: Issue the openssl command to display the certificate chain that you downloaded in Step 7(a). Verify that the information matches the information that is displayed for the current server certificate in the RKM GUI. In the following example the chain has three certificate files:
```
openssl verify -CAfile /var/mmfs/etc/RKMcerts/sklmChain0.cert
-untrusted /var/mmfs/etc/RKMcerts/sklmChain1.cert 
/var/mmfs/etc/RKMcerts/sklmChain2.cert
```
  The command has the following parameters:
  
  -CAfile /var/mmfs/etc/RKMcerts/sklmChain0.cert
  
  Specifies the path of the root certificate file.
  
  -untrusted /var/mmfs/etc/RKMcerts/sklmChain1.cert
  
  Specifies the path of the intermediate certificate file.
  
  /var/mmfs/etc/RKMcerts/sklmChain2.cert
  
  Specifies the path of the endpoint certificate file.
  Note: If the certificate chain contains more than three certificate files, combine the intermediate files into one certificate file, set the numeral in the name of the combined certificate file to 1, and set the numeral in the name of the endpoint certificate file to 2. For example, suppose that the certificate chain contains four certificate files: sklmChain0.cert, sklmChain1.cert, sklmChain2.cert, and sklmChain3.cert. Before you issue the openssl command, do the following steps:
  1. Make backup copies of these certificate files, in case they are lost or damaged.
  2. Modify the certificate files in the following way:
    
    The sklmChain0.cert file needs no changes.
    
    Combine sklmChain1.cert and sklmChain2.cert into one file and name it sklmChain1.cert.
    
    Rename sklmChain3.cert to sklmChain2.cert.
  Issue the openssl command in the same way as in the previous example:
  openssl verify -CAfile /var/mmfs/etc/RKMcerts/sklmChain0.cert -untrusted /var/mmfs/etc/RKMcerts/sklmChain1.cert /var/mmfs/etc/RKMcerts/sklmChain2.cert
  If the chain contains only two certificate files, omit the -untrusted option and issue the openssl command in the following way:
```
openssl verify -CAfile /var/mmfs/etc/RKMcerts/sklmChain0.cert
/var/mmfs/etc/RKMcerts/sklmChain1.cert
```
  Important: Combining the intermediate files into one certificate file is required only for the openssl command. It is not required for the mmgskkm command.
3. Issue the following command to add the retrieved certificate chain to the client keystore:
```
mmgskkm trust --prefix <serverPrefix> --out <keystore> --pwd-file <pwd-file> 
--label <serverLabel> 
```
  where:
  
  --prefix <serverPrefix>
  
  Is the path and file name prefix for the RKM certificate chain that you specified in Step 4 (b).
  
  --out<keystore>
  
  Is the path and file name of the client keystore that you created in Step 4(b).
  
  --pwd-file<pwd-file>
  
  Is the path and file name of the keystore password file that you created in Step 1.
  
  --label<serverLabel>
  
  Is the label under which you want to store the RKM certificate chain in the client keystore.
4. Update the RKM stanza for the new client credentials in the /var/mmfs/etc/RKM.conf file. Make sure that the following values are correct:
  - The keyStore term specifies the path and file name of the client keystore that you created in Step 4(b).
  - The passphrase term specifies the keystore password from Step 1.
  - The clientCertLabel term specifies the label of the new client certificate from Step 4(b).
Copy the updated /var/mmfs/etc/RKM.conf file and the new client keystore file to all the nodes of the cluster.
Reload the new client keystore by one of the following methods:
- On any administration node in the cluster, run the mmchpolicy command to refresh the current policy rules. You do not need to repeat this action on other nodes in the cluster.
- On each node of the cluster, unmount and mount the file system.
- In IBM Spectrum Scale 4.2.1 and later, issue the following command:
```
/usr/lpp/mmfs/bin/tsloadikm run
```
  Repeat this action on all the nodes of the cluster.
Issue the following command to purge all master encryption keys from the cache of the GPFS daemon:
```
tsctl encKeyCachePurge all
```
This action ensures that subsequent reads and writes to files use the new client credentials.

The new client certificate is installed.

Regular setup: Trusting a new client certificate

Follow these instructions if you are using the regular setup method with an SKLM key server. If you have not created and installed new client credentials, follow the instructions in the preceding subsection Regular setup or DSM setup: Creating and installing a new key client.

Follow these instructions if you are using SKLM and the Regular setup method and you have created and installed new client credentials.

Add the new client certificate to the SKLM list of pending certificates:
1. On the node that you are configuring for encryption, try to create an encrypted file by doing some action that triggers an encryption policy rule.
2. The attempt fails because SKLM does not yet trust the new client certificate. However, the attempt causes SKLM to add the new client certificate to the list of pending certificates in the SKLM key server.

Verify the RKM ID in the error message from Step 2:

Find the RKM ID that is specified in the error message.

In the following example, the RKM ID is keyserver01:

# touch /gpfs0/test
touch: cannot touch `/gpfs0/test’: Permission denied
# tail -n 2 /var/adm/ras/mmfs.log.latest

2020-07-16_01:28:08.792-0400: [E] Unable to create encrypted file file(inode 18560,
 fileset 0, file system fs).
2020-07-16_01:28:08.792-0400: [E] Key 'KEY-ad4f3a9-019465da-edc8-49d4-b183-80ae89635cbc:
 sklm3RKM' could not be fetched. Invalid request.

Find the RKM ID of the RKM stanza that specifies the new client keystore.
The RKM stanza is in the /var/mmfs/etc/RKM.conf file.
Verify that the RKM ID from the error message matches the RKM ID of the stanza.

Verify the pending client certificate in SKLM:
1. On the main page of the SKLM graphical user interface, click Pending client device communication certificates..
2. In the list of certificates, select the new client certificate and click View.
3. Verify that the certificate matches the new client certificate.
4. If the certificates match, click Accept and Trust.
Enter a name for the new certificate and click Accept and Trust again.
Verify that the server accepts the new client certificate:
1. On the node that you are configuring for encryption, try to create an encrypted file as you did in step 2(a).
2. This time the command succeeds and the encrypted file is created.

SKLM trusts the new client certificate.

DSM: Trusting a new client certificate

Follow these instructions if you are using the regular setup method with DSM. If you have not created a new client certificate, follow the instructions in the preceding subsection Regular setup or DSM setup: Creating and installing a new key client.

Follow these instructions if you are using the regular setup with DSM as the key server and you have created a new client certificate and imported its information into the current IBM Spectrum Scale policy rules.

In the DSM web GUI, import the new client certificate into the DSM server.
Provide the path and file name of the certificate file that you created in Step 2 and referenced in Step 3 of the subtopic Regular setup or DSM setup: Creating and installing a new key client. The path and file name have the format <prefix>.cert, where <prefix> is the path and file name prefix that you specified in Step 2.
On the node that you are configuring for encryption, try to create an encrypted file by doing some action that triggers an encryption policy rule. These instructions assume that the file is successfully created.

DSM trusts the new client certificate.