Before adding a member node to an encryption group, ensure that the node has been properly initialized and that all encryption engines are in an enabled state.
During the initialization phase a set of key pairs and certificates are generated on every node. These certificates are used for mutual identification and authentication with other group members and with
Adding a member node to an encryption group
the key vault. Every device must have a certificate in order to participate in a deployment of encryption services. Some devices must have each other’s certificates in order to communicate.
After adding the member node to the encryption group, the following operations can still be performed on the member node if necessary. Initially, these commands should not be necessary if the initialization procedure was followed:
• cryptocfg --initEE
• cryptocfg --regEE
• cryptocfg --enableEE CAUTION
After adding the member node to the encryption group, you should not use the cryptocfg --zeroizeEE command on that node. Doing so removes critical information from the node and makes it necessary to re-initialize the node and export the new KAC certificate to the group leader and the key vault.
To add a member node to an encryption group, follow these steps:
1. Log in to the switch on which the certificate was generated as Admin or FabricAdmin.
2. Execute the cryptocfg --reclaimWWN -cleanup command.
3. Log in as Admin or SecurityAdmin.
4. Export the certificate from the local switch to an SCP-capable external host or to a mounted USB device. Enter the cryptocfg --export command with the appropriate parameters.
When exporting a certificate to a location other than your home directory, you must specify a fully qualified path that includes the target directory and file name. When exporting to USB storage, certificates are stored by default in a predetermined directory, and you only need to provide a file name for the certificate. The file name must be given a .pem (privacy enhanced mail) extension. Use a character string that identifies the certificate’s originator, such as the switch name or IP address.
The following example exports a CP certificate from an encryption group member to an external SCP-capable host and stores it as enc_switch1_cp_cert.pem.
SecurityAdmin:switch> cryptocfg --export -scp CPcert \ 192.168.38.245 mylogin /tmp/certs/enc_switch1_cp_cert.pem Password:
Operation succeeded.
The following example exports a CP certificate from the local node to USB storage.
SecurityAdmin:switch> cryptocfg --export -usb CPcert enc_switch1_cp_cert.pem Operation succeeded.
5. Use the cryptocfg --import command to import the CP certificates to the group leader node.
You must import the CP certificate of each node you wish to add to the encryption group.
The following example imports a CP certificate named "enc_switch1_cp_cert.pem" that was previously exported to the external host 192.168.38.245. Certificates are imported to a predetermined directory on the group leader.
SecurityAdmin:switch> cryptocfg --import -scp enc_switch1_cp_cert.pem \ 192.168.38.245 mylogin /tmp/certs/enc_switch1_cp_cert.pem
Password:
Operation succeeded.
The following example imports a CP certificate named "enc_switch1_cp_cert.pem" that was previously exported to USB storage.
SecurityAdmin:switch> cryptocfg --import -usb enc_switch1_cp_cert.pem \
Configuring Encryption Using the CLI
enc_switch1_cp_cert.pem Operation succeeded.
NOTE
If the maximum number of certificates is exceeded you are prompted to delete any unused certificates using the cryptocfg --delete -file command and then try again.
6. Enter the cryptocfg --show -file -all command on the group leader to verify that you have imported all necessary certificates.
The following example shows the member node CP certificate that was imported earlier to the group leader.
SecurityAdmin:switch> cryptocfg --show -file -all File name: enc_switch1_cp_cert.pem, size: 1338 bytes
7. On the group leader, register each node you are planning to include in the encryption group. Enter the cryptocfg --reg -membernode command with appropriate parameters to register the member node.
Specify the member node’s WWN, Certificate filename, and IP address when executing this command.
SecurityAdmin:switch> cryptocfg --reg -membernode \ 10:00:00:05:1e:39:14:00 enc_switch1_cert.pem 10.32.244.60 Operation succeeded.
NOTE
The order in which member node registration is performed defines group leader succession. At any given time there is only one active group leader in an encryption group. The group leader
succession list specifies the order in which group leadership is assumed if the current group leader is not available.
Successful execution of this command distributes all necessary node authentication data to the other members of the group.
8. Display encryption group member information.
This example shows the encryption group "brocade" with two member nodes, one group leader and one regular member. No key vault or HA cluster is configured, and the values for master key IDs are zero.
SecurityAdmin:switch> cryptocfg --show -groupmember -all NODE LIST
Total Number of defined nodes:2
Group Leader Node Name: 10:00:00:05:1e:41:9a:7e Encryption Group state: CLUSTER_STATE_CONVERGED
Node Name: 10:00:00:05:1e:41:9a:7e (current node) State: DEF_NODE_STATE_DISCOVERED
Role: GroupLeader IP Address: 10.32.244.71 Certificate: GL_cpcert.pem Current Master Key State: Not configured
Current Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Alternate Master Key State:Not configured
Alternate Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 EE Slot: 0
SP state: Operational; Need Valid KEK
Current Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Alternate Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 No HA cluster membership
Node Name: 10:00:00:05:1e:39:14:00 State: DEF_NODE_STATE_DISCOVERED
Configuring Encryption Using the CLI
Role: MemberNode IP Address: 10.32.244.60 Certificate: enc1_cpcert.pem Current Master Key State: Not configured
Current Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Alternate Master Key State:Not configured
Alternate Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 EE Slot: 0
SP state: Unknown State
Current Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Alternate Master KeyID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 No HA cluster membership
High availability clusters
A high availability (HA) cluster consists of exactly two encryption engines configured to host the same CryptoTargets and to provide Active/Standby failover and failback capabilities in a single fabric. Failover is automatic (not configurable). Failback occurs automatically by default, but is configurable with a manual failback option. All encryption engines in an encryption group share the same DEK for a disk or tape LUN.
NOTE
The CLI does not allow creation of an HA cluster if the node is not in the encryption group.
HA cluster configuration rules
The following rules apply when configuring an HA cluster:
• The encryption engines that are part of an HA cluster must belong to the same encryption group and be part of the same fabric.
• An HA cluster cannot span fabrics and it cannot provide failover/failback capability within a fabric transparent to host MPIO software.
• HA cluster configuration and related operations must be performed on the group leader.
• HA clusters of FS8-18 blades should not include blades in the same DCX Backbone chassis.
NOTE
HA cluster creation is blocked when encryption engines belonging to FS8-18 blades in the same DCX Backbone Chassis are specified.
• Cluster links must be configured before creating an HA cluster. Refer to the section Configuring cluster links on page 124 for instructions.
• Configuration changes must be committed before they take effect. Any operation related to an HA cluster that is performed without a commit operation will not survive across switch reboots, power cycles, CP failover, or HA reboots.
ATTENTION
All nodes in an Encryption Group (EG) must be running the same Fabric OS version. Make sure all of the nodes in the EG have the same Fabric OS before you commit the changes.
High availability clusters
• It is recommended that the HA cluster configuration be completed before you configure storage devices for encryption.
• It is mandatory that the two encryption engines in the HA cluster belong to two different nodes for true redundancy. This is always the case for Brocade Encryption Switches, but is not true if two FS8-18 blades in the same DCX Backbone Chassis are configured in the same HA cluster. HA cluster creation is blocked when encryption engines belonging to FS8-18 blades in the same DCX Backbone Chassis are specified.