Regular setup: Using SKLM with a certificate chain

Learn to use the regular setup method to configure the key client node with the IBM® Security Key Lifecycle Manager (SKLM) key server when the server is running with a certificate chain from a certificate authority (CA) rather than with a self-signed server certificate.

Attention: The simplified setup method, which can be used only when the Remote Key Management (RKM) server is SKLM, is much easier to use and more powerful than the regular setup method with SKLM. In the simplified setup method, the mmkeyserv command automatically performs many of the steps that must be done manually in the regular setup method.

The regular setup method with SKLM requires IBM Storage Scale Advanced Edition, IBM Storage Scale Data Management Edition, or IBM Storage Scale Developer Edition or IBM Storage Scale Erasure Code Edition V4.1 or later and a supported version of SKLM. For information about supported SKLM versions, see Preparation for encryption.

This topic describes the regular method for setting up encryption with SKLM as the RKM server and with a certificate that is signed by a certificate authority CA on the KMIP port of the SKLM server. If your deployment scenario uses a self-signed server certificate, see one of the following topics:

Note: If you are using SKLM v2.7 or later, see the topic Configuring encryption with SKLM 2.7 or later.

Requirements:

The following requirements must be met on every IBM Storage Scale node that participates in encryption:

The node must have direct network access to the system where the key server is installed.
The security-sensitive files that are created during the configuration process must have the following characteristics:
- They must be regular files that are owned by the root user.
- The group ownership must be changed to root group.
- They must be readable and writable only by the user (mode '0600'). The following examples apply to the regular setup with SKLM and with Thales Vormetric Data Security Manager (DSM) setup:
```
-rw-------. 1 root root 2446 Mar 20 12:15 /var/mmfs/etc/RKM.conf
drw-------. 2 root root 4096 Mar 20 13:47 /var/mmfs/etc/RKMcerts
-rw-------. 1 root root 3988 Mar 20 13:47 /var/mmfs/etc/RKMcerts/keystore_name.p12
```
These security-sensitive files include the following files:
- The RKM.conf file. For more information about this file, see The RKM.conf file and the RKM stanza.
- The files in the client keystore directory, which include the keystore file, the public and private key files for the client, and possibly other files. For more information about these files, see The client keystore directory and its files.
CAUTION:
- Take appropriate precautions to ensure that the security-sensitive files are not lost or corrupted. IBM Storage Scale does not manage or replicate the files.
- Ensure that the passphrase for the client certificate file is not leaked through other means, such as the shell history.
Client keystore files must be record-locked when the GPFS daemon starts. If the keystore files are stored on an NFS mount, the encryption initialization process can hang. The cause is a bug that affects the way NFS handles record locking. If you encounter this problem, upgrade your version of NFS or store your keystore file on a local file system. If an upgrade is not possible and no local file system is available, use a RAM drive to store the keystore files.

See the following subtopics for instructions:

Part 1: Installing Security Key Lifecycle Manager
Part 2: Configuring SKLM
Part 3: Configuring the remote key management (RKM) back end
Part 4: Enabling encryption on other nodes

Part 1: Installing Security Key Lifecycle Manager

Follow the instructions in this subtopic to install and configure the IBM Security Key Lifecycle Manager (SKLM).

Install IBM Security Key Lifecycle Manager. For the supported versions, see Preparation for encryption. For the installation, choose a system that the IBM Storage Scale node that you want to configure has direct network access to. For more information, see the Installing and configuring chapter of the SKLM documentation.
From the main page of the SKLM web GUI, click Configuration > Key Serving Parameters and select the checkbox for Keep pending client device communication certificates.
Configure SKLM to have the same FIPS 140-2 (FIPS) setting as the IBM Storage Scale cluster.
Follow these steps:
1. Determine the FIPS setting of the cluster by issuing the following command:
```
mmlsconfig FIPS1402mode
```
  The command returns yes if the cluster complies with FIPS or no if not.
2. On the SKLM server system, open the SKLMConfig.properties file.
  Note: The default location of the SKLMConfig.properties file depends on the operating system:
  - On AIX®, Linux®, and similar operating systems the directory is at the following location:
    
    For GKLM 4.1.1 or later versions:
    /opt/IBM/WebSphere/Liberty/products/sklm/config/SKLMConfig.properties
    
    For GKLM 4.1.0.1 and old supported SKLM versions:
    /opt/IBM/WebSphere/AppServer/products/sklm/config/SKLMConfig.properties
  - On Microsoft Windows, the directory is at the following location:
    
    For GKLM 4.1.1 or later versions:
    Drive:\Program Files (x86)\IBM\WebSphere\Liberty\products\sklm\config\SKLMConfig.properties
    
    For GKLM 4.1.0.1 and old supported SKLM versions:
    Drive:\Program Files (x86)\IBM\WebSphere\AppServer\products\sklm\config\SKLMConfig.properties
3. In the SKLMConfig.properties file, find the line that begins fips=. To configure the FIPS setting for SKLM, enter fips=on to comply with FIPS or fips=off not to comply. If the line is not present in the file, add it.
Configure the SKLM server to have the same NIST SP800-131a (NIST) setting as the IBM Storage Scale cluster. Follow these steps:
1. Determine the NIST setting of the cluster by issuing the following command on the command line:
```
mmlsconfig nistCompliance
```
  The command returns SP800-131A if the cluster complies with NIST or off if not.
2. On the SKLM server system, open the SKLMConfig.properties file. For the location of this file, see the note in Step 3.
3. Add the following line to configure SKLM to comply with NIST or remove it to configure SKLM not to comply with NIST:
```
TransportListener.ssl.protocols=TLSv1.2
```
Configure IBM WebSphere® Application Server so that it has the same NIST setting as the IBM Storage Scale cluster.
See the topic Transitioning WebSphere Application Server to the SP800-131 security standard in the volume WebSphere Application Server Network Deployment in the WebSphere Application Server online documentation.
- WebSphere Application Server can be configured to run SP800-131 in a transition mode or a strict mode. The strict mode is recommended.
- When NIST is enabled, make sure that WebSphere Application Server certificate size is at least 2048 bytes and is signed with SHA256withRSA as described in the preceding link.
If the cipher suites were set at any time, SKLM 2.6.0.0 has a known issue that causes server certificates always to be signed with SHA1withRSA. To work around the problem, follow these steps:
1. While the SKLM server is running, in the SKLMConfig.properties file, modify the requireSHA2Signatures property as follows:
```
requireSHA2Signatures=true
```
2. Do not restart the server.
3. Generate a new server certificate signing request (CSR) to a third-party certificate authority (CA) and send it to the CA.
4. When you receive the certificate from the third-party CA, import it into SKLM and set it to be the certificate in use. For more information, see the next subtopic.
5. If you restart the server, you must repeat this workaround before you can create a server certificate that is signed other than with SHA1withRSA.

Part 2: Configuring SKLM

To configure SKLM, you must create a certificate signing request (CSR), send it to the CA, obtain the certificate chain from the CA, and import the endpoint certificate into the SKLM server. You must also create a device group for the cluster and create keys for the device group.

Note: For more information about the steps in this subtopic, see Scenario: Request for a third-party certificate in IBM Security Guardium® Key Lifecycle Manager documentation.

Create a CSR with the SKLM command line interface:
1. On the SKLM server system, open a command-line window.
2. Change to the WAS_HOME/bin directory. The location of this directory depends on the operating system:
  - On AIX, Linux, and similar operating systems, the directory is at the following location:
    - For GKLM 4.1.1 and later versions:
      /opt/IBM/WebSphere/Liberty/bin
    - For GKLM 4.1.0.1 and old supported SKLM versions:
      /opt/IBM/WebSphere/AppServer/bin
  - On Microsoft Windows, the directory is at the following location:
    - For GKLM 4.1.1 and later versions:
      drive:\Program Files (x86)\IBM\WebSphere\Liberty\bin
    - For GKLM 4.1.0.1 and old supported SKLM versions:
      drive:\Program Files (x86)\IBM\WebSphere\AppServer\bin
3. Start the command line interface to SKLM:
  - On AIX, Linux, and similar operating systems, issue the following command:
```
./wsadmin.sh -username SKLMAdmin -password mypwd -lang jython
```
  - On Microsoft Windows, issue the following command:
```
wsadmin -username SKLMAdmin -password mypwd -lang jython
```
4. In the SKLM command line interface, issue the following command on one line:
```
print AdminTask.tklmCertGenRequest('[-alias labelCsr -cn server 
 -validity daysValid -keyStoreName defaultKeyStore -fileName fileName -usage SSLSERVER]')
```
  where:
  
  -alias labelCsr
  
  Specifies the certificate label of the CSR.
  
  -cn server
  
  Specifies the common name of the server in the certificate.
  
  -validity daysValid
  
  Specifies the validity period of the certificate in days.
  
  -keyStoreName defaultKeyStore
  
  Specifies the keystore name within SKLM where the CSR is stored. Typically, you would specify defaultKeyStore as the name here.
  
  -fileName fileName
  
  Specifies the fully qualified path of the directory where the CSR is stored on the SKLM server system, for example /root/sklmServer.csr.
  
  -usage SSLSERVER
  
  Specifies how the generated certificate is used in SKLM.
  
  The following example shows the SKLM response:
```
CTGKM0001I Command succeeded
fileName
```
Send the CSR file from Step 1 to the certificate authority.
When you receive the generated certificate file, or endpoint certificate file, from the certificate authority, copy it to a directory on the node that you are configuring for encryption. For example, you might copy it to the directory and file /opt/IBM/WebSphere/Liberty/products/sklm/data/sklmServer.cert.
Important:
1. You must also obtain and copy the root certificate file and any intermediate certificate files into the same temporary directory. The root certificate and the intermediate certificates might be included with the generated endpoint certificate file. Or you might have to obtain the root certificate file and any intermediate certificate files separately. Whatever the method, you must have a root certificate file, any intermediate certificate files, and the endpoint certificate file. You need these certificate files in Part 3.
2. If you have not already done so, save the files of the certificate chain to a secure location. Include the root certificate file, any intermediate certificate files, and the endpoint certificate file. Now, when a client certificate expires, you will not need to download the certificate chain from the server again. You can add your local copy of the files in the server certificate chain to the new client keystore. For more information, see Renewing expired client certificates.
Import the endpoint certificate into the SKLM server with the SKLM graphical user interface:
1. On the Welcome page, in the Action Items section, in the Key Groups and Certificates area, click You have pending certificates.
2. In the Pending Certificates table, click the certificate that you want to import and click Import.
3. In the File name and location field, type the path and file name of the certificate file and click Import.
In SKLM, create a device group for the IBM Storage Scale cluster:
1. In the SKLM graphical user interface, click Advanced Configuration > Device Group.
2. In the Device Group table, click Create.
3. In the Create Device Group window, follow these steps:
  1. Select the GPFS device family.
  2. Enter an appropriate name, such as GPFS_Tenant0001. The name is case-sensitive.
  3. Make a note of the name. You need it in Part 3 when you create an RKM stanza.
  4. Complete any other fields and click Create.
4. After SKLM creates the device group, it prompts you to add devices and keys. Do not add any devices or keys. Instead, click Close. Keys are created in the next step.
Create master encryption keys for the device group.
1. In the SKLM graphical user interface, in the Key and Device Management table, select the device group that you created in Step 5. In these instructions, the device group is named GPFS_Tenant0001.
2. Click Go to > Manage keys and services.
3. In the management page for GPFS_Tenant0001, click Add > Key.
4. Enter the following information:
  - The number of keys to be created.
  - The three-letter prefix for key names. The key names are internal SKLM names and are not used for GPFS encryption.
5. Make a note of the UUID of the key, such as KEY-326a1906-be46-4983-a63e-29f005fb3a15. You need it in Part 3.
6. In the drop-down list at the bottom of the page, select Hold new certificate requests pending my approval.

Part 3: Configuring the remote key management (RKM) back end

To configure a remote key management (RKM) back end, you must create and initialize a client keystore and you must create an RKM stanza in the RKM.conf file on the IBM Storage Scale node:

On the IBM Storage Scale node that you are configuring for encryption, create the following subdirectory to contain the client keystore:
```
/var/mmfs/etc/RKMcerts 
```
Issue the following command to create the client credentials. The command is all on one line:
```
mmgskkm gen --prefix /var/mmfs/etc/RKMcerts/SKLM --cname clientName 
 --pwd-file passwordFile --fips fipsVal --nist nistVal --days validDays --keylen keyBits
```
where:
--prefix /var/mmfs/etc/RKMcerts/SKLM

Specifies the path and file name prefix of the client credential files that are generated.

--cname clientName

Specifies the name of the client in the certificate.

--pwd-file passwordFile

Specifies the path of a text file that contains the password for the client keystore. The password must be 1 - 20 characters in length.

--fips fipsVal
Specifies the current FIPS 140-2 compliance mode of the IBM Storage Scale cluster. Valid values are on and off. To find the current mode, issue the following command:
```
mmlsconfig fips1402mode
```
--nist nistVal
Specifies the current NIST SP 800-131A compliance mode of IBM Storage Scale cluster. Valid values are on and off. To find the current mode, issue the following command:
```
mmlsconfig nistCompliance
```
--days validDays

Specifies the number of days that the client certificate is valid.

--keylen keyBits

Specifies the number of bits for the client private RSA key.
The command creates three files that contain the private key, the public key, and the certificate for the client.
Issue the following command to create the client keystore and store the private key and the client certificate in it. The command is all on one line:
```
mmgskkm store --cert /var/mmfs/etc/RKMcerts/SKLM.cert
 --priv /var/mmfs/etc/RKMcerts/SKLM.priv --label clientCertLabel 
 --pwd-file passwordFile --out /var/mmfs/etc/RKMcerts/SKLM.p12 --fips fipsVal --nist nistVal
```
where:
--cert /var/mmfs/etc/RKMcerts/SKLM.cert

Specifies the path of the client certificate file. The path was specified in the --prefix parameter Step 2. The file suffix is .cert.

--priv /var/mmfs/etc/RKMcerts/SKLM.priv

Specifies the path of the client private key file. The path was specified in the --prefix parameter in the Step 2. The file suffix is .priv.

--label clientCertLabel

Specifies the label of the client certificate in the keystore.

--pwd-file passwordFile

Specifies the path of a text file that contains the password for the client keystore. The password must be 1 - 20 characters in length.

--out /var/mmfs/etc/RKMcerts/SKLM.p12

Specifies the path of the client keystore.

--fips fipsVal
Specifies the current FIPS 140-2 compliance mode of the IBM Storage Scale cluster. Valid values are on and off. To find the current mode, issue the following command:
```
mmlsconfig fips1402mode
```
--nist nistVal
Specifies the current NIST SP 800-131A compliance mode of the IBM Storage Scale cluster. Valid values are on and off. To find the current mode, issue the following command:
```
mmlsconfig nistCompliance
```
Copy the certificate files of the server certificate chain from the temporary directory to the directory that contains the client keystore. You gathered these files in Step 3 of Part 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
```
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. 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.
Important: If you have not already done so, save the files of the certificate chain to a secure location. Include the root certificate file, any intermediate certificate files, and the endpoint certificate file. Now, when a client certificate expires, you will not need to download the certificate chain from the server again. You can add your local copy of the files in the server certificate chain to the new client keystore. For more information, see Renewing expired client certificates.
Issue the following command to verify the certificate chain. The command is all on one line:
```
openssl verify -CAfile /var/mmfs/etc/RKMcerts/sklmChain0.cert
 -untrusted /var/mmfs/etc/RKMcerts/sklmChain1.cert /var/mmfs/etc/RKMcerts/sklmChain2.cert
```
where:

-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. If no intermediate certificates are in the chain, omit this parameter.

/var/mmfs/etc/RKMcerts/sklmChain2.cert

Specifies the path of the endpoint certificate.

If there are only two certificates, omit the -untrusted parameter and issue the command as in the following example:
```
openssl verify -CAfile /var/mmfs/etc/RKMcerts/sklmChain0.cert
 /var/mmfs/etc/RKMcerts/sklmChain1.cert
```
Issue the following command to store the certificate chain into the client keystore. The command is all on one line:
```
mmgskkm trust --prefix /var/mmfs/etc/RKMcerts/sklmChain
 --pwd-file passwordFile --out /var/mmfs/etc/RKMcerts/SKLM.p12
 --label labelChain --fips fipsVal --nist nistVal
```
where:
--prefix /var/mmfs/etc/RKMcerts/sklmChain
Specifies the path and the file name prefix of the files in the certificate chain. The mmgsskm command trusts all the files that have the specified prefix and a .cert suffix. For example, if the chain consists of three certificates and the prefix is /var/mmfs/etc/RKMcerts/sklmChain, then the command trusts the following certificates:
- /var/mmfs/etc/RKMcerts/sklmChain0.cert
- /var/mmfs/etc/RKMcerts/sklmChain1.cert
- /var/mmfs/etc/RKMcerts/sklmChain2.cert
--pwd-file passwordFile

Specifies the path of a text file that contains the password of the client keystore.

--out /var/mmfs/etc/RKMcerts/SKLM.p12

Specifies the path of the client keystore.

--label labelChain

Specifies the prefix of the label for the server certificate chain in the client keystore.

--fips fipsVal
Specifies the current FIPS 140-2 compliance mode of the IBM Storage Scale cluster. Valid values are on and off. To find the current mode, issue the following command:
```
mmlsconfig fips1402mode
```
--nist nistVal
Specifies the current NIST SP 800-131A compliance mode of the IBM Storage Scale cluster. Valid values are on and off. To find the current mode, issue the following command:
```
mmlsconfig nistCompliance
```
Important: The new keystore must be record-locked when the GPFS daemon starts. If the keystore files are stored on an NFS mount, the encryption initialization process can hang. The cause is a bug that affects the way NFS handles record locking. If you encounter this problem, upgrade your version of NFS or store your keystore file on a local file system. If an upgrade is not possible and no local file system is available, use a RAM drive to store the keystore files.
Create an RKM.conf file and add a stanza to it that contains the information that is necessary to connect to the SKLM key server. The RKM.conf file must contain a stanza for each connection between a key client, an SKLM device group, and a key server.
1. In a text editor, create a new text file with the following path and name:
```
/var/mmfs/etc/RKM.conf
```
2. Add a stanza with the following format:
```
stanzaName {
   type = ISKLM
   kmipServerUri = tls://raclette.zurich.ibm.com:5696
   keyStore = /var/mmfs/etc/RKMcerts/SKLM.p12
   passphrase = a_password
   clientCertLabel = a_label
   tenantName = GPFS_Tenant0001
}
```
  where the rows of the stanza have the following meaning:
  stanzaName
  A name (RKM ID) for the stanza. Make a note of the name: you need it in the next step.
  It is a good practice to use a format like the following one to ensure that the RKM ID is unique:
  keyServerName_tenantName
  where tenantName is the name that you provide in the last line of stanza. For example, the RKM ID for the key server and key client in these instructions is: raclette_GPFS_Tenant0001.
  type
  
  Always ISKLM.
  
  kmipServerUri
  The DNS name or IP address of the SKLM server and the KMIP SSL port. You can find this information on the main page of the SKLM graphic user interface. The default port is 5696.
  You can have multiple instances of this line, where each instance represents a different backup key server. The following example has the primary key server and two backup key servers:
  stanzaName { type = ISKLM kmipServerUri = tls://raclette.zurich.ibm.com:5696 kmipServerUri = tls://raclette.fondue.ibm.com:5696 kmipServerUri = tls://raclette.fondue2.ibm.com:5696 keyStore = /var/mmfs/etc/RKMcerts/SKLM.p12 passphrase = a_password clientCertLabel = a_label tenantName = GPFS_Tenant0001 }
  If the GPFS daemon cannot get an encryption key from the primary key server, it tries the backup key servers in order.
  keyStore
  
  The path and name of the client keystore.
  
  passphrase
  
  The password of the client keystore and client certificate.
  
  clientCertLabel
  
  The label of the client certificate in the client keystore.
  
  tenantName
  
  The name of the SKLM device group. See Part 1: Installing Security Key Lifecycle Manager.
Set up an encryption policy on the node that you are configuring for encryption.
1. Create a file management policy that instructs GPFS to do the encryption tasks that you want.
  The following policy is an example. It instructs IBM Storage Scale to encrypt all files in the file system with a file encryption key (FEK) and to wrap the FEK with a master encryption key (MEK):
```
RULE ’p1’ SET POOL ’system’ /* one placement rule is required at all times */
RULE ’Encrypt all files in file system with rule E1’
SET ENCRYPTION ’E1’
WHERE NAME LIKE ’%’
RULE ’simpleEncRule’ ENCRYPTION ’E1’ IS
ALGO ’DEFAULTNISTSP800131A’
KEYS(’KEY-326a1906-be46-4983-a63e-29f005fb3a15:SKLM_srv’)
```
  In the last line of the policy, the character string within single quotation marks (') is the key name. A key name is a compound of two parts in the following format:
```
KeyID:RkmID
```
  where:
  
  KeyID
  
  Specifies the UUID of the key that you created in the SKLM graphic user interface in Part 2.
  
  RkmID
  
  Specifies the name of the RKM backend stanza that you created in the /var/mmfs/etc/RKM.conf file.
2. Issue the mmchpolicy command to install the rule.
  
  CAUTION:
  Installing a new policy with the mmchpolicy command removes all the statements in the previous policy. To add statements to an existing policy without deleting the previous contents, collect all policy statements for the file system into one file. Add the new statements to the file and install the contents of the file with the mmchpolicy command.
Import the client certificate into the SKLM server:
1. On the IBM Storage Scale node that you are configuring for encryption, send a KMIP request to SKLM.
  To send a KMIP request, try to create an encrypted file on the node. The attempt fails, but it causes SKLM to put the client certificate in a list of pending certificates in the SKLM key server. The attempt fails because SKLM does not yet trust the client certificate. See the following example:
```
# touch /gpfs0/test
touch: cannot touch `/gpfs0/test’: Permission denied
# tail -n 2 /var/adm/ras/mmfs.log.latest
Thu Mar 20 14:00:55.029 2014: [E] Unable to open encrypted file: inode 46088,
Fileset fs1, File System gpfs0.
Thu Mar 20 14:00:55.030 2014: [E] Error: key
’KEY-326a1906-be46-4983-a63e-29f005fb3a15:SKLM_srv’ could not be fetched (RKM
reported error -1004).
```
2. In the graphical user interface of SKLM, on the main page, click Pending client device communication certificates.
3. Find the client certificate in the list and click View.
4. Carefully check that the certificate that you are importing matches the one created in the previous step, then click Accept and Trust.
5. On the resulting screen, provide a name for the certificate and click Accept and Trust again.
6. On the node that you are configuring for encryption, try to create an encrypted file as you did in Step (a).
  This time the command succeeds. Issue an mmlsattr command to list the encryption attributes of the new file:
```
# touch /gpfs0/test                                                            
# mmlsattr -n gpfs.Encryption /gpfs0/test                                      
file name: /gpfs0/test                                                         
gpfs.Encryption: "EAGC????f?????????????? ??????w?^??>???????????? ?L4??       
_-???V}f???X????,?G?<sH??0?)??M?????)?KEY-326a1906-be46-4983-a63e-29f005fb3a15?
sklmsrv?)?KEY-6aaa3451-6a0c-4f2e-9f30-d443ff2ac7db?RKMKMIP3?"                 
EncPar ’AES:256:XTS:FEK:HMACSHA512’                                            
type: wrapped FEK WrpPar ’AES:KWRAP’ CmbPar ’XORHMACSHA512’                    
KEY-326a1906-be46-4983-a63e-29f005fb3a15:sklmsrv                              
```
  From now on, the encryption policy rule causes each newly created file to be encrypted with a file encryption key (FEK) that is wrapped in a master encryption key (MEK). You created the key in a device group in the SKLM server and included its UUID as part of a key name in the security rule.
  Important: See the security note and the caution at the beginning of this topic before Part 1.

Part 4: Enabling encryption on other nodes

To replicate an encryption configuration on another node, you must copy some configuration files from the configured node to the target node:
1. Copy the /var/mmfs/etc/RKM.conf file to the same directory on the target node.
2. Copy the keystore files that the RKM file references to the same directories on the target node. The suggested location for the keystore files on the configured node is /var/mmfs/etc/RKMcerts/.
To create a different encryption configuration on another node, follow the steps that are described in the preceding subtopics. Note the following design points:
- On a single node, the following conditions are true:
  - The RKM.conf file can contain multiple stanzas. Each stanza represents a connection between a key client and an SKLM device group.
  - You can create multiple keystores.
- Across different nodes, the following conditions are true:
  - The contents of RKM.conf files can be different.
  - The contents of keystores can be different.
  - If an encryption policy succeeds on one node and fails on another in the same cluster, verify that the failing node has the correct client keystore and stanza.
    Remember: All nodes that mount a file system need to be able to access all the keys used in that file system.