Frequently Asked Questions

My client certificate has expired. How do I update it?

You would first need to obtain a new valid, signed client certificate. Follow the instructions from the HSM vendor to update it on the HSM, if needed. For example, Utimaco ESKM requires that you enter the new certificate contents into the KMIP-enabled local user.

On the data-fabric side, first disable the KMIP feature using the mrhsm set command with the -active parameter set to false, then use the mrhsm set command to replace the client certificate. Then, re-enable the KMIP feature using the mrhsm enable command. You will need your SO PIN to do this task. See About the SO PIN.

I forgot my SO PIN. Can I still perform KMIP operations? Can I still make changes to the KMIP configuration?

Keep your SO PIN in a safe place. The SO PIN is not stored in the data-fabric platform or the HSM. Although you can continue normal operations such as starting the MFS and CLDB without the SO PIN, you would not be able to make any changes to your configuration without it.

If you lose your SO PIN but you want to change some KMIP configuration settings, you would have to delete your KMIP token and the mrhsm.conf configuration file, that is, everything in the /opt/mapr/conf/tokens directory, and then configure the KMIP settings from scratch, using either the mrhsm Commands or the configure.sh script. Your CLDB, DARE, Core KEK and Common Master keys are saved in the external HSM, so you would not lose any keys.

I accidentally deleted my /opt/mapr/conf/tokens directory and I cannot start the CLDB and MFS. How do I recover from this?

The CLDB and DARE keys are stored in the encrypted /opt/mapr/conf/tokens/mrhsm.conf file. If you enable HSM functionality, the CLDB and MFS will not be able to start if they cannot find this file. You would need to perform your HSM configuration again from scratch, using either the mrhsm Commands or the configure.sh script. Your CLDB, DARE, Core KEK and Common Root keys are saved in the external HSM, so you would not lose any keys.

I deleted my /opt/mapr/conf/tokens directory, and I did not save a copy of my private client key. How do I recover from this?

Once configured, the client private key is stored in encrypted format in the mrhsm.conf file and cannot be extracted. You are responsible for keeping a copy of your private client key for disaster recovery purposes. If you deleted your /opt/mapr/conf/tokens directory, then, as stated in the previous answer, you would need to perform your HSM configuration again from scratch, and to do this, you would need your client private key.

If you did not save a copy of the client private key, then you would have to follow the instructions in the integration guides (Utimaco ESKM Integration Guide, Gemalto SafeNet KeySecure Key Manager Integration Guide, or Vormetric Data Security Manager (DSM) Integration Guide) to generate the client private key and CSR, and then obtain a new signed client certificate, which may have to be configured into the HSM depending on the vendor.

Can I mix and match HSMs from different vendors?

Not within the same data-fabric cluster. Data Fabric supports multiple HSM vendors, but you can only select one vendor per data-fabric cluster. HSM vendors normally implement their own clustering solutions, so key propagation to other HSMs in the cluster only works for HSMs from the same vendor. Most HSM vendors recommend a cluster of at least 2 appliances for high reliability and availability purposes. For example, if you choose the Utimaco ESKM, then you would normally configure at least 2 Utimaco ESKM appliances.

Can I use different HSM vendors on different clusters, even if there is volume mirroring and table replication between the clusters?

Yes. The HSMs only protect the critical keys within a single data-fabric cluster, so it is possible to use different HSM vendors for different clusters if there is a good reason to do so. However, this may not be cost-effective as maintaining multiple HSMs from different vendors may result in higher operating costs. HSMs are designed to accommodate multiple keys from different clients.

The data-fabric KMIP solution is engineered to generate cluster-specific key names, so there will be no namespace conflict between keys from different clusters.

If I initially go for one HSM vendor and store my keys there, can I later migrate to a different HSM vendor?

This is a general migration issue that does not pertain to data-fabric. Normally, HSMs will be used to store master keys from different applications, of which data-fabric is one. Migrating to a different HSM vendor will require migrating all the keys from the old HSM vendor to the new one, and involves exporting the KMIP keys (using the KMIP Get operation) from the old HSM vendor, and then importing the keys (using the KMIP Register or Import operation) to the new HSM.

Customers will need to write an application to do this themselves, or engage a professional service provider to do this. After the keys are migrated, follow the steps in the integration guides (Utimaco ESKM Integration Guide, Gemalto SafeNet KeySecure Key Manager Integration Guide, or Vormetric Data Security Manager (DSM) Integration Guide) to configure the new HSM, and use either the mrhsm Commands or the configure.sh script to set up the data-fabric CLDB node to work with the new HSM. Then, copy the contents of the /opt/mapr/conf/tokens directory to the other CLDB nodes in the cluster. Ensure that all the files in the /opt/mapr/conf/tokens directory are owned by the mapr user and the mapr group.

I do not want to use the HSM to store my master keys anymore. However, I already encrypted my disks using DARE, and I do not want to regenerate my data-fabric tickets. Can I revert to the old file-based solution?

Assuming you did an upgrade from the file-based solution to use the HSM, and you have saved a copy of your /opt/mapr/conf/cldb.key and /opt/mapr/conf/dare.master.key, the steps to revert are as follows:

Backup the contents of the /opt/mapr/conf/tokens directory, in case you want to go back to the HSM solution.
Remove the /opt/mapr/conf/tokens directory.
Restore the /opt/mapr/conf/cldb.key and the /opt/mapr/conf/dare.master.key that you have backed up before you moved to the HSM solution.

I do not want to use the HSM to store my master keys anymore, but I do not have backups of /opt/mapr/conf/cldb.key and /opt/mapr/conf/dare.master.key. Can I still revert to the old file-based solution?

This is not a supported scenario, but you can still do this. Contact HPE Support.

I have successfully upgraded from the old file-based solution to use the HSM. Do I still need to backup my /opt/mapr/conf/cldb.key and /opt/mapr/conf/dare.master.key?

If you have successfully upgraded to use the HSM, then the HSM should contain backups of the CLDB and DARE master keys for disaster recovery purposes. Provided you do not intend to revert to the older (insecure) file-based solution in the future, you can safely delete the /opt/mapr/conf/cldb.key and the /opt/mapr/conf/dare.master.key.

However, if, for some reason, you feel you may revert from the more secure HSM solution to the less secure file-based solution, you should keep backups of these keys.

I am trying to upgrade to use the HSM, but I need time to configure it. Can the data-fabric platform continue to function while I am testing my configuration?

The HSM functionality will not take effect until you enable it using either the mrhsm Commands or the configure.sh script. HSM will be enabled only if all settings are correct and all configured HSMs are accessible using the Discover Versions KMIP operation. If the CLDB or MFS detects that HSM functionality has not been enabled and the /opt/mapr/conf/cldb.key and the /opt/mapr/conf/dare.master.key exist, it will use those files.