Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT, Инструкция по установке

Страница: 27 / 132

Using Hardware Security Modules with Subsystems
17
Before using external tokens, plan how the external token is going to be used with the subsystem:
• All system keys for a subsystem must be generated on the same token.
• The subsystem keys must be installed in an empty HSM slot. If the HSM slot has previously been
used to store other keys, then use the HSM vendor's utilities to delete the contents of the slot. The
Certificate System has to be able to create certificates and keys on the slot with default nicknames.
If not properly cleaned up, the names of these objects may collide with previous instances.
• A single HSM can be used to store certificates and keys for mulitple subsystem instances, which
may be installed on multiple hosts. When an HSM is used, any certificate nickname for a subsystem
must be unique for every subsystem instance managed on the HSM.
2.5.1.3. Hardware Cryptographic Accelerators
The Certificate System can use hardware cryptographic accelerators with external tokens. Many of the
accelerators provide the following security features:
• Fast SSL connections. Speed is important to accommodate a high number of simultaneous
enrollment or service requests.
• Hardware protection of private keys. These devices behave like smart cards by not allowing private
keys to be copied or removed from the hardware token. This is important as a precaution against
key theft from an active attack of an online Certificate Manager.
2.5.2. Using Hardware Security Modules with Subsystems
The Certificate System supports the nCipher netHSM hardware security module (HSM) by default.
Certificate System-supported HSMs are automatically added to the
secmod.db
database with
modutil
during the pre-configuration stage of the installation, if the PKCS #11 library modules are in
the default installation paths.
During configuration, the
Key Store
panel displays the supported modules, along with the NSS
internal software PKCS #11 module. All supported modules that are detected show a status of
Found
and is individually marked as either
Logged in
or
Not logged in
. If a token is found but not
logged in, it is possible to log in using the
Login
under
Operations
. If the administrator can log into
a token successfully, the password is stored in a configuration file. At the next start or restart of the
Certificate System instance, the passwords in the password store are used to attempt a login for each
corresponding token.
Administrators are allowed to select any of the tokens that are logged in as the default token, which is
used to generate system keys.
2.5.2.1. Adding or Managing the HSM Entry for a Subsystem
When an HSM is selected as the default token, the following parameters are set in instance's
CS.cfg
file to configure the HSM:
#RHCS supported modules
preop.configModules.module0.commonName=NSS Internal PKCS #11 Module
preop.configModules.module0.imagePath=../img/mozilla.png
preop.configModules.module0.userFriendlyName=NSS Internal PKCS #11 Module
preop.configModules.module1.commonName=nfast
preop.configModules.module1.imagePath=../img/ncipher.png