Red Hat SummitQuesto contenuto non è disponibile nella lingua selezionata.
Chapter 8. Using hardware security modules with subsystems
A subsystem instance generates and stores its key information in a key store, called a security module or a token. A subsystem instance can be configured for the keys to be generated and stored using the internal NSS token or on a separate cryptographic device, a hardware token.
8.1. Adding or managing the HSM entry for a subsystem
During installation, when an HSM is selected as the default token where appropriate HSM-specific parameters are set in the configuration file passed to the pkispawn command, the following parameter is added to the /var/lib/pki/ instance_name/conf/password.conf file for the HSM password:
hardware-HSM_token_name=HSM_token_password
hardware-HSM_token_name=HSM_token_password8.2. Installing a subsystem using an HSM
To install a Certificate System instance using an HSM, follow the procedure in Preparing for installing Certificate System with an HSM to prepare a pkispawn file for installation of a Certificate System instance using one of the supported HSMs.
You can find full installation examples using an HSM, such as the following, in Installing the CA subsystem:
8.3. Viewing Tokens
To view a list of the tokens currently installed for a Certificate System instance, use the modutil utility.
Change to the instance
aliasdirectory. For example:cd /var/lib/pki/pki-tomcat/alias
# cd /var/lib/pki/pki-tomcat/aliasCopy to Clipboard Copied! Toggle word wrap Toggle overflow Show the information about the installed PKCS #11 modules installed as well as information on the corresponding tokens using the
modutiltool.modutil -dbdir . -nocertdb -list
# modutil -dbdir . -nocertdb -listCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. Detecting Tokens
To see if a token can be detected by Certificate System, use the TokenInfo utility, pointing to the alias directory for the subsystem instance. This is a Certificate System tool which is available after the Certificate System packages are installed.
For example:
TokenInfo /var/lib/pki/pki-tomcat/alias
# TokenInfo /var/lib/pki/pki-tomcat/aliasThis utility returns all tokens which can be detected by the Certificate System, not only tokens which are installed in the Certificate System.
8.5. Failover and resilience
Failover means setting up multiple units, and configuring them so that if one unit fails, another one will take over and continue the service without interruption.
Resilience ensures that when the network connection to a unit is interrupted and then reconnected, the service is not interrupted within a reasonable timeframe.
Some Hardware Security Module (HSM) models offer failover or resilience of varying degrees. For detail on the exact make and models and the features that they offer, consult your HSM manual, or contact the manufacturer. The HSMs described in the following sections have been tested with Red Hat Certificate System.
8.5.1. nCipher nShield HSM
The failover and resilience tests were conducted on the older Entrust HSMS model, nShield Connect 6000, however, according to the Entrust website, failover and resilience are also supported in the newer model of nShield Connect HSMs, such as the XC. They are expected to work in a similar manner.
Failover
With nShield Connect 6000, failover has been tested in the scenario where there are two HSM modules, nShield1, and nShield2, both running and configured for failover.
If one of nShield units goes down, the other exhibits ability to continue the provision of cryptographic services to Certificate System with no known issues, without restarting of the RHCS instance.
When the above situation happens (one HSM unit goes down), the administrator is expected to schedule a downtime for all the connected Certificate System instances and fix the down hsm unit and bring it back up and restart the instances. This means that if one unit goes down, Certificate System is expected to continue functioning; however, if the down hsm is brought back up without restarting the instances, the newly brought up HSM unit is not expected to be part of the failover scheme as originally planned.
Resilience
With nShield Connect 6000, testing has shown that when the network cable is pulled off the HSM unit, and replugged in within up to 90 minutes, the service continues. There is no data for any time period longer than 90 minutes.
8.5.2. Gemalto Safenet LunaSA HSM
Failover
The Gemalto Safenet LunaSA Cloning model offers Failover. However, we have no data on this model.
8.6. Backing up keys on Hardware Security modules
It is not possible to export keys and certificates stored on an HSM to a .p12 file. If such an instance is to be backed-up, contact the manufacturer of your HSM for support.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}