Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
The shaded objects show the foundation of the Certificate Manager PKI environment, which is created in the bootstrap procedure.
This article describes how to bootstrap Nexus Certificate Manager.
The purpose of the bootstrap procedure is to build the foundation for a PKI environment, including certificate authorities (CAs) and security officers, and revoke the bootstrap CA. A bootstrapping must be performed after a new system installation, before the system can be used for production of certificates.
When performing the bootstrap procedure you will be using the two Certificate Manager clients Administrator's workbench (AWB) and Registration Authority (RA) as well as other utility programs described below.
In addition to using software tokens for SSL and PIN encryption it is possible to store the tokens in hardware security modules (HSMs). It is also possible to combine one software token with one stored in HSM. The bootstrap procedure will differ depending on the use of HSM.
Note |
---|
Use the two security officer (SO) soft tokens in the boot kit until you have created two Certificate Manager officers, and after that use the smart cards that you have then personalized. |
Create officer and system CA
Expand | ||
---|---|---|
| ||
To create an Officer and System CA key:
|
Expand | ||
---|---|---|
| ||
To create an Officer and System CA:
|
Create security officers
Expand | ||
---|---|---|
| ||
To create a certificate procedure:
|
Expand | ||
---|---|---|
| ||
To create a token procedure for smart cards:
|
Expand | ||
---|---|---|
| ||
To personalize two smart cards:
|
Expand | ||
---|---|---|
| ||
To create two Certificate Manager officers:
|
Set up tokens for secure system communication
Create hardware tokens for SSL and PIN encryption
These tasks are related to administrative system hardware tokens only, when a hardware security module (HSM) is used.
Expand | ||
---|---|---|
| ||
To create a token procedure with storage profile PKCS#10:
|
Expand | ||
---|---|---|
| ||
To prepare the hardware security module (HSM) for SSL tokens:
|
Expand | ||
---|---|---|
| ||
To prepare the hardware security module (HSM) for PIN encryption tokens:
|
Expand | ||
---|---|---|
| ||
This step is only performed if the key archiving and recovery (KAR) option has been licensed. The purpose of this step is to create a key encryption key (KEK) and to remove the temporary KEK included in the distribution. The KEK is used by the KARFactory in order to encrypt and decrypt archived keys.
|
Optional: Create software tokens for SSL and PIN encryption
These tasks are related to administrative system software tokens only. These are an alternative to hardware tokens.
Expand | ||
---|---|---|
| ||
To create a certificate procedure for SSL and PIN encryption:
|
Expand | ||
---|---|---|
| ||
To create a token procedure for SSL and PIN encryption:
|
Expand | ||
---|---|---|
| ||
To issue a software token for SSL:
|
Expand | ||
---|---|---|
| ||
To issue a software token for PIN encryption:
|
Set up signing of audit logs
Expand | |||||
---|---|---|---|---|---|
| |||||
To change the key for signing logs in the Certificate Issuing System (CIS):
|
Expand | ||
---|---|---|
| ||
To stop the system:
If you have installed and started the Nexus SNMP service, you may stop it, but it is not mandatory. |
Use tokens for secure system communication
Expand | ||
---|---|---|
| ||
If you have issued an SSL software token, it must be installed and configured in the CCM (or in the computers running Certificate Factory (CF) and CRLF in case of a distributed configuration). To install and configure the SSL software token:
|
Expand | ||
---|---|---|
| ||
If you have prepared an SSL hardware token, it must be configured in the CCM (or in the computers running CF and CRLF in case of a distributed configuration). To configure the SSL hardware token:
|
Expand | ||
---|---|---|
| ||
If you have issued PIN encryption software tokens, they must be installed and configured in the CCM (or in the computers running CF and CRLF in case of a distributed configuration). To install and configure the PIN encryption software tokens:
|
Expand | ||
---|---|---|
| ||
If you have prepared a PIN encryption hardware token, it must be configured in the CCM (or in the computers running CF and CRLF in case of a distributed configuration). To configure the PIN encryption hardware token:
|
Expand | ||
---|---|---|
| ||
If you will use RA for card personalization, cards must be prepersonalized in the Key Generation System (KGS). In that case, install the PIN encryption certificate in KGS:
|
Expand | ||
---|---|---|
| ||
To start the system:
|
Remove Nexus boot components
Expand | ||
---|---|---|
| ||
When everything works as expected, you can revoke the Boot CA. The boot officers are prevented from logging in to Certificate Manager when revoking the Boot CA. To revoke the Boot CA:
|
Expand | ||
---|---|---|
| ||
From the AWB, remove the Boot CA key, (which can be found in the “Retired keys” subgroup in the Key Registry), as described in “Removing a CA Key” in the Certificate Manager CA Administrator's Guide.
|
Related information
The following tasks are done during the bootstrapping procedure.
In Administrator's workbench (AWB):
- Create CA key
- Create CA
- Create certificate procedure
- Create token procedure
- Create officer profile
- Create Certificate Manager officer
Using hwsetup:
- Initializing Hardware Security Module
- Generate AES or 3DES key
- Generate RSA key pair
- Generate PKCS #10 certificate request
- Install certificate
In Key Generation System: