Allow Re-Key To Complete Before Deleting A Container; Re-Key Operations And Firmware Upgrades; Do Not Change Lun Configuration While Re-Keying; Recommendation For Host I/O Traffic During Online Rekeying And First Time Encryption - Brocade Communications Systems Brocade 8/12c Administrator's Manual

Allow re-key to complete before deleting a container

Do not delete a crypto container while re-key is in session or if re-key is not completed. If you want
to delete a container, use the command cryptocfg
sessions. If any re-key session is not 100% completed, do not delete the container. If you do delete
the container before re-key is complete, and subsequently add the LUN back as cleartext, all data
on the LUN is destroyed.

Re-key operations and firmware upgrades

All nodes in an encryption group must be at the same firmware level before starting a re-key or
first-time encryption operation. Make sure that existing re-key or first-time encryption operations
complete before upgrading any of the encryption products in the encryption group, and that the
upgrade completes before starting a rekey or first-time encryption operation.

Do not change LUN configuration while re-keying

Never change the configuration of any LUN that belongs to a Crypto Target Container/LUN
configuration while the re-keying process for that LUN is active. If you change the LUN's settings
during manual or auto, re-keying or first time encryption, the system reports a warning message
stating that the encryption engine is busy and a forced commit is required for the changes to take
effect. A forced commit command halts all active re-keying progresses running in all Crypto Target
Containers and corrupts any LUN engaged in a re-keying operation. There is no recovery for this
type of failure.
Recommendation for Host I/O traffic during online rekeying and first
time encryption
You may see failed I/Os if writes are done to a LUN that is undergoing first time encryption or
rekeying. It is recommended that host I/O operations are quiesced and not started again until
re-key operations or first time encryption operations for the LUN are complete.

KAC certificate registration expiry

It is important to keep track as to when your signed KAC certificates will expire. Failure to work with
valid certificates causes certain commands to not work as expected. If you are using the certificate
expiry feature and the certificate expires, the key vault server will not respond as expected. For
example, the Group Leader in an encryption group might show that the key vault is connected;
however, a member node reports that the key vault is not responding.
To verify the certificate expiration date, use the following command:
openssl x509 –in newcerts/<Switch Cert Name> -dates –noout
Output:
In the example above, the certificate validity is active until "Dec 4 18:03:14 2010 GMT." After the
KAC certificate has expired, the registration process must be redone.
Fabric OS Encryption Administrator's Guide
53-1002159-03
Not Before: Dec 4 18:03:14 2009 GMT
Not After : Dec 4 18:03:14 2010 GMT

KAC certificate registration expiry

show -rekey –all to display the status of re-key
--
5
201