Bootstrap Certificate Manager
This article includes updates for Certificate Manager 8.10.
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 Smart ID Certificate Manager.
The purpose of the bootstrap procedure is to build the foundation for a PKI environment, including certificate authorities (CAs) and 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) in Certificate Manager, as well as other utility programs described below.
In addition to using software tokens for TLS 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.
Use the two bootstrap officers soft tokens in the boot kit until you have created two officers, and after that use the smart cards that you have then personalized. For the bootstrap officers, two step signing is disabled.
Create Officer and System CA
To create an Officer and System CA key
Generate a new CA key for the Officer and System CA, according to Create CA key in Certificate Manager.
. In Key name, enter
Officer and system CA key.
In Device, select an RSA type.
Create Officer and System CA
Use the key
Officer and system CA key
created in the previous step, to create an Officer and System CA, according to Create CA in Certificate Manager.In Authority name, enter
Officer and system CA
.Do the following selections in the Authority Request dialog box:
Issuing CA - select Self-signed
Usage - Certificate signing
Format - self-signed ca-cert
Country - current country
Common name - Officer and system CA
Organization - current organization
No distribution rule is required but can be added later if necessary.
Create bootstrap officers
Create certificate procedure for officer certificates
To create a certificate procedure:
Create a certificate procedure to be used when issuing smart cards based on the
Officer and System CA key
. See Create certificate procedure in Certificate Manager.Do the following selections in the Certificate Procedure Request dialog box:
Procedure name - Officer certificates
Key usage - do not select any key usage
Issuing CA - Officer and System CA
CA chain - none
Certificate format - rfc5280
Set the Validity and Signature algorithm parameters as required.
Create token procedure for officer smart cards
To create a token procedure for smart cards:
Create a token procedure to be used when issuing smart cards based on the certificate procedure you created in the previous step. See Create token procedure in Certificate Manager
Do the following selections in the Token Procedure Request dialog box:
Procedure name - Officer cards
Storage profile - Smart Card
Card serial number - Yes
Serial number range - Mandatory
PIN procedure - Show PINs in client
Issuer certificates - do not store any
Certificate procedure - Officer certificates
Personalize two officer smart cards
To personalize two smart cards:
Produce two pre-personalized smart cards in your Key Generation System (KGS). See Produce smart cards in Certificate Manager.
Register the two smart cards with information concerning two subjects who should become officers 1 and 2 of your system. See Issue smart card certificate in Certificate Manager.
In the Smart Card tab of the Registration Authority application window, do the following steps for each of the two cards:
Select action Add for each displayed key.
Select the procedure you created in the previous step.
Make a note of the PIN codes assigned for the cards.
Create two officers
To create two officers:
Create two officers based on the smart cards from the previous step. See Create officer profile in Certificate Manager and Create officer in Certificate Manager.
Any certificate on the smart card may be selected in the Officer Request dialog box.
Create certificate procedure for TLS, KAR and PIN encryption
To create a certificate procedure for TLS, KAR and PIN encryption:
Create a certificate procedure according to Create certificate procedure in Certificate Manager.
Use the following parameters:
Key usage - do not select any key usage
Issuing CA - Officer and System CA
Certificate format - server certificate
Set the Validity and Signature algorithm parameters as required.
Set up tokens for secure system communication
You can create hardware tokens or software tokens for TLS and PIN encryption.
Create hardware tokens for TLS and PIN encryption
These tasks are related to administrative system hardware tokens only, when a hardware security module (HSM) is used. Hardware tokens are an alternative to software tokens.
Create a token procedure with storage profile PKCS#10
To create a token procedure with storage profile PKCS#10:
Create a token procedure, according to Create token procedure in Certificate Manager.
Use the following parameters:
Storage profile - PKCS#10
Issuer certificates - do not store any
Certificate procedures - the certificate procedure created for TLS, KAR and PIN encryption.
Prepare hardware security module for TLS token
To prepare the hardware security module (HSM) for TLS tokens:
Run hwsetup to generate a key pair with sign property, according to Generate DSA/EC/RSA key pair.
Example:
hwsetup -libname crypto -slot 0 -pin abcd -id tls -genrsa 2048 -sign
Run hwsetup to create a PKCS #10 request based on the generated key pair, according to Generate PKCS #10 certificate request. Include the key usage extension.
Example, (on one line):
hwsetup -libname crypto -slot 0 -pin abcd -id tls -keyusage -genreq "cn=localhost,o=Nexus"
Use RA to issue a certificate to a file, tls.crt, based on the PKCS #10 request.
Run hwsetup to store the certificate in HSM, according to Install certificate.
Prepare hardware security module for PIN encryption token
To prepare the hardware security module (HSM) for PIN encryption tokens:
Run hwsetup to generate an RSA key pair, according to Generate DSA/EC/RSA key pair. The private key needs the sign property to sign the PKCS #10 request.
Example:
hwsetup -libname crypto -slot 0 -pin abcd -id pin -genrsa 2048
Run hwsetup to create a PKCS #10 request based on the generated key pair, according to Generate PKCS #10 certificate request. Include key usage extension with
dataEncipherment
.Example:
hwsetup -libname crypto -slot 0 -pin abcd -id pin -keyusage dataEncipherment -genreq "cn=PIN encryption,o=Nexus"
Use RA to issue a certificate to a file, pin.crt, based on the PKCS #10 request.
Run hwsetup to store the certificate in the HSM, according to Install certificate.
Prepare hardware security module for KAR token
This step is only performed if the key archiving and recovery (KAR) option has been licensed and enabled during installation.
The purpose of this step is to create a key encryption key (KEK). The KEK is used by the KARFactory in order to encrypt and decrypt archived keys. The KEK can be either a symmetric AES or DES3 key or an asymmetric RSA key pair.
AES or DES3 key
Run hwsetup to generate a symmetric AES or DES3 key, see Generate AES or 3DES key.
Example:hwsetup -libname crypto -slot 0 -pin abcd -id kekaes256 -label kekaes256 -genkey AES-256
RSA keypair
Run hwsetup to generate an asymmetric RSA key pair, see Generate DSA/EC/RSA key pair. The private key needs the sign property to sign the PKCS #10 request.
Example:hwsetup -libname crypto -slot 0 -pin abcd -id kekrsa -label kekrsa -genrsa 2048
Run hwsetup to create a PKCS #10 request based on the generated key pair (see Generate PKCS #10 certificate request). Include key usage extension with
keyEncipherment
anddataEncipherment
.
Example:hwsetup -libname crypto -slot 0 -pin abcd -id kekrsa -keyusage "keyEncipherment,dataEncipherment" -genreq "cn=KEK,o=Nexus"
Use RA to issue a certificate to a file, kek.crt, based on the PKCS #10 request.
Run hwsetup to store the certificate in HSM, according to Install certificate.
Create software tokens for TLS and PIN encryption
These tasks are related to administrative system software tokens only. Software tokens are an alternative to hardware tokens.
Create token procedure for TLS and PIN encryption
To create a token procedure for TLS and PIN encryption:
Create a token procedure, according to Create token procedure in Certificate Manager.
Use the following parameters:
Storage profile - PKCS#12
Pin procedure - Show PINs in client
Issuer certificates - do not store any
Certificate procedures - the certificate procedure created for TLS, KAR and PIN encryption.
Issue software token for TLS
To issue a software token for TLS:
Issue a software token based on the token procedure for TLS and PIN encryption, according to Issue software token in Certificate Manager.
Name the file tls.p12.
Make a note of the assigned PIN code.
Save the file to a removable media for use in later tasks.
Issue software token for PIN encryption
To issue a software token for PIN encryption:
Issue a software token based on the token procedure for TLS and PIN encryption, according to Issue software token in Certificate Manager.
Name the file pin.p12.
Save the PIN encryption certificate to the file pin.crt.
Make a note of the assigned PIN code.
Save the files to a removable media for use in later tasks.
Prepare data for CIS
Change key for signing logs in Certificate Issuing System (CIS)
Do these preparations for the Certificate Issuing System (CIS):
In AWB, go to Key Registry > In Use > Officer and System CA key, and note the value of Identifier.
Open <configuration_root>/config/cis.conf for editing.
Find the parameter
logsignkey
and set it to the value of Identifier found in the AWB (see step 1).Place the certificate file in CIS trust store: <configuration_root>/config/cistrust/system_ca.cer.
Remove the Boot CA file from CIS trust store: <configuration_root>/config/cistrust/bootca.cer.
Stop the system
Stop the Nexus Certificate Issuing System (CIS) service (if external CIS service is installed).
Stop the Nexus Certificate Factory (CF) service.
Stop the clients.
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
For software token: Change the TLS token
If you have issued a TLS software token, it must be installed and configured in CF (or in all computers running CF and CIS in case of a distributed configuration).
To install and configure the TLS software token:
Make a backup copy of the current file tls.p12 in the CF.
Copy the token from the removable media to replace the old file <configuration_root>/certs/tls.p12.
Set parameter
SSL.file
andcis.ssl.file
in cm.conf andSSL.file
in cis.conf to the file path of the TLS soft token file.Set parameter
SSL.pin
andcis.ssl.pin
in cm.conf andSSL.pin
in cis.conf to avoid manual intervention during start of CM servers (also called Optional PIN).After you have tested that the new TLS server certificate works properly, delete the file tls.p12 from the removable media.
For hardware token: Change the TLS token
If you have prepared a TLS hardware token, it must be installed and configured in CF (or in all computers running CF and CIS in case of a distributed configuration).
To configure the TLS hardware token:
Set parameter
SSL.cert
andcis.ssl.cert
in cm.conf andSSL.cert
in cis.conf to a case sensitive string value taken from the Distinguished Name in the TLS server certificate. (Open the file containing the certificate created in "Prepare hardware security module for TLS token" above.)Set parameter
SSL.tokenlabel
andcis.ssl.tokenlabel
in cm.conf andSSL.tokenlabel
in cis.conf to a case sensitive string value taken from the device token label where the certificate/key resides. This task is optional, but it is recommended.Set parameter
pkcs11.<n>
, (where<n>
is a sequence number for each library starting with 1) in cm.conf and cis.conf to specify the PKCS #11 libraries that should be available for use in TLS authentication and that should be searched for the specified certificate.Set parameter
SSL.pin
andcis.ssl.pin
in cm.conf andSSL.pin
in cis.conf to avoid manual intervention during start of CM servers (also called Optional PIN).Set parameter
SSL.nopin
=true in cm.conf and cis.conf to avoid showing unnecessary dialogs when the HSM has a PIN pad or if it does not require a PIN code.
For software token: Change the PIN encryption token
If you have issued PIN encryption software tokens, they must be installed and configured in the CF.
To install and configure the PIN encryption software tokens:
Make a backup copy of the current pin.p12 file in the CF.
Copy the tokens from the removable media to replace the old file <configuration_root>/certs/pin.p12.
Set parameter
pin.file
in cm.conf to the file path of the PIN soft token file.Set parameter
pin.pin
in cm.conf to avoid manual intervention during start of CM servers (also called Optional PIN).
For hardware token: Change the PIN encryption token
If you have prepared a PIN encryption hardware token, it must be configured in CF.
To configure the PIN encryption hardware token:
Set parameter
pin.cert
in cm.conf to a case sensitive string value taken from the Distinguished Name in the PIN encryption certificate. (Open the file containing the certificate created in "Prepare hardware security module for PIN encryption token" above.)Set parameter
pin.tokenlabel
in cm.conf to a case sensitive string value taken from the device token label where the certificate/key resides. This task is optional, but it is recommended.Set parameter
pkcs11.<n>
, (where<n>
is a sequence number for each library starting with 1) in cm.conf to specify the PKCS #11 libraries that should be available for use in PIN encryption and that should be searched for the specified certificate.Set parameter
pin.pin
in cm.conf to avoid manual intervention during start of CM servers (also called Optional PIN).Set parameter
pin.nopin
=true to avoid showing unnecessary dialogs when the HSM has a PIN pad or if it does not require a PIN code.
Optional: Change the KAR token
This step should only be performed if KAR is enabled. The KEK token prepared in "Prepare hardware security module for KAR token" above must be configured in the CF.
In kar.conf, add the crypto library to the list of crypto libraries (in the parameter
kar.common.cryptolib.<N>.name
).In kar.conf, add the new KEK to the list of tokens instead of the temporary KEK, that is, change the value of
kar.common.token.0.tokenlabel
andkar.common.token.0.pin
.In kar.conf, set the new KEK as the key to use for key archiving, that is, change the value of
kar.archive.kek.0.tokenlabel
andkar.archive.kek.0.keylabel
.
Start the system
Start the Nexus CIS service (if external CIS service is installed.
Start the Nexus CF service.
Remove Nexus boot components
Revoke the Boot CA
When everything works as expected, you can revoke the Boot CA. The bootstrap officers are prevented from logging in to Certificate Manager when revoking the Boot CA.
To revoke the Boot CA:
Test all connections to verify that everything works as expected, for example:
Sign in to AWB with one of the new bootstrap officers.
Do an update and sign it, to test that both bootstrap officers function as expected.
Use the Revoke Authority command in the Tools menu to revoke the Boot CA with revocation reason Cessation of Operation.
Remove the Boot CA key
From the AWB, remove the Boot CA key, (which can be found in the “Retired keys” subgroup in the Key Registry), as described in Modify CA key in Certificate Manager.
Additional information
Copyright 2024 Technology Nexus Secured Business Solutions AB. All rights reserved.
Contact Nexus | https://www.nexusgroup.com | Disclaimer | Terms & Conditions