Red Hat Certificate System 8.0 Install Guide
Chapter 3. Installation and Configuration
The Certificate System is comprised of subsystems which can be independently installed on different servers, multiple instances installed on a single server, and other flexible configurations for availability, scalability, and failover support. The procedures for downloading, installing, and configuring instances of
Certificate System subsystems are described in this chapter.
The Certificate System servers include six subsystems:
Certificate Authority (CA)
Registration Authority (RA)
Data Recovery Manager (DRM), sometimes referred to as a Key Recovery Authority (KRA)
Online Certificate Status Protocol (OCSP) Responder
Token Key Service (TKS)
Token Processing System (TPS)
The Certificate System client is the Enterprise Security Client. For information about the Enterprise
Security Client, see the Certificate System Enterprise Security Client Guide.
3.1. Overview of Installation
The individual subsystems for Red Hat Certificate System are installed and then configured individually.
The initial installation is done using package management tools such as RPM; the subsystem setup is done through an HTML-based configuration wizard.
1. Install a Red Hat Directory Server. This can be on a different machine from the Certificate System, which is the recommended scenario for most deployments.
2. Download the Certificate System packages from the Red Hat Network channel. Each subsystem has its own packages, as well as dependencies and related packages. These are listed in
Section 2.3, “Packages Installed on Red Hat Enterprise Linux”
.
3. Install the packages, as described in
Section 3.2, “Installing the Certificate System Packages”
.
By default, the installation process immediately launches pkicreate to create the default instances as soon as the subsystem packages are installed. The default instances are
configured with the default settings listed in Section 9.5, “Default File and Directory Locations for
Certificate System” . It is also possible to prevent the pkicreate command from running so that
you can configure an instance with custom settings, which is described in Chapter 5, Creating
Additional Subsystem Instances .
4. Configure the Certificate System CA subsystem. At least one CA subsystem must be installed and fully configured before any other type of subsystem can be configured.
See
Section 3.3, “Configuring a CA”
for instructions on setting up the Certificate Manager.
5. Configure the RA, OCSP, DRM, and TKS subsystems. Once the CA is installed, the other subsystems, except for the TPS, can be installed and configured in any order.
See
Section 3.5, “Configuring a DRM, OCSP, or TKS”
and Section 3.4, “Configuring an RA”
for the process on installing and configuring the OCSP, DRM, TKS, and RA subsystems.
6. Configure the TPS subsystem. The TPS requires having an existing TKS and DRM available when it is configured, so this is the last subsystem to set up.
See
Section 3.6, “Configuring a TPS”
for the process on installing and configuring the TPS.
The order in which subsystems are configured is very important because of the basic relationships which are established between subsystems at the time they are installed. For example, every subsystem depends on a certificate authority; the TPS also depends on a TKS and (optionally) DRM.
26
Chapter 3. Installation and Configuration
Figure 3.1. Order of Subsystem Configuration
3.2. Installing the Certificate System Packages
There are two ways to obtain and install the subsystem packages. For all supported platforms, the
Certificate System packages can be downloaded as ISO images through the appropriate Red Hat
Network channel. These packages are then installed through a package utility, such as rpm.
Alternatively, if the appropriate network access is available, the subsystems and dependencies can be downloaded and installed on Red Hat Enterprise Linux systems using the yum command.
Several packages are installed with the Certificate System packages for related applications and
dependencies, not only for the subsystems. These packages are listed in Section 2.3, “Packages
Installed on Red Hat Enterprise Linux” .
Section 3.2.1, “Installing through yum”
Section 3.2.2, “Installing from an ISO Image”
NOTE
When the first subsystem is installed on a machine, the installation process automatically creates a new user (pkiuser) and group (pkiuser). All default Certificate System instances run as this user and group.
27
Red Hat Certificate System 8.0 Install Guide
3.2.1. Installing through yum
NOTE
pkicreate is launched by the installer to create the default instances, using default settings.
There is an environment variable, DONT_RUN_PKICREATE, which stops the pkicreate script from running automatically after the subsystems are installed.
Setting DONT_RUN_PKICREATE allows the default instances to be installed in user-defined installation directories, instead of the default locations in /var/lib. It can be preferable to install through the ISO image with this environment variable set to block the pkicreate script for deployments where the default instances must be installed in custom locations.
NOTE
To use an IPv6 hostname for configuration, set the hostname in the PKI_HOSTNAME environment
variable before installing the packages. This is described in Section 4.4, “Enabling IPv6 for a
Subsystem” .
To install the initial subsystems on Red Hat Enterprise Linux 5 (32-bit), run a command like the following for each subsystem: yum install pki-subsystem
NOTE
yum is used only for the first subsystem instance; any additional subsystem instances are added using pkicreate.
subsystem can be any of the Certificate System subsystems:
ca for the Certificate Manager.
ra for the Registration Authority.
kra for the Data Recovery Manager.
ocsp for the Online Certificate Status Protocol Responder.
tks for the Token Key System.
tps for the Token Processing System.
console for the Java console.
Once the packages are installed, then the installer automatically launches the pkicreate script to create the default subsystem instance automatically. A URL to access the new instance is printed to the screen which gives the subsystem instances hostname, port, and a login PIN to access the configuration wizard.
28
Chapter 3. Installation and Configuration
PKI instance creation Utility ...
PKI instance creation completed ...
Starting instance_name: [ OK ]
instance_name (pid 17990) is running ...
'instance_name' must still be CONFIGURED!
(see /var/log/instance_name-install.log)
Before proceeding with the configuration, make sure the firewall settings of this machine permit proper access to this subsystem.
Please start the configuration by accessing: https://hostname.domainname:admin-port/subsystem_type/admin/console/config/login?
pin=pin
After configuration, the server can be operated by the command:
/sbin/service instance_name start | stop | restart
To install the pkiconsole to administer the subsystems, run the following: yum install pki-console
3.2.2. Installing from an ISO Image
Red Hat Certificate System 8.0 can also be downloaded from Red Hat Network as an ISO image. This
ISO image contains an RPMS/ directory which can be used as a local yum repository.
1. Open the Red Hat Certificate System 8.0 Red Hat Network channel and download the
ISO image.
2. Place that RPMS/ directory on a web server and then configure yum to use that location as a repository.
3. Install Certificate System as described in Section 3.2.1, “Installing through yum”
, including setting any environment variables, HSMs, or IPv6 settings.
3.3. Configuring a CA
The CA is always the first subsystem to be configured; every other subsystem depends on the CA for its configuration. The CA, along with setting up the CA hierarchy for the PKI, issues certificates which every subsystem uses to function and sets up a security domain which establishes trusted relationships between subsystems.
NOTE
If a CA has an ECC signing certificate, it can issue both RSA and ECC client certificates. To
enable ECC for the CA, load an ECC module first (described in Section 4.2, “Installing a CA with
ECC Enabled” ) and then configure the CA.
29
Red Hat Certificate System 8.0 Install Guide
Subsystem configuration is done by accessing a unique web-based configuration page for the instance.
The only supported web browser for subsystem configuration is Mozilla Firefox.
1. Install the subsystem packages. For example: yum install pki-ca
Once the packages are installed, then the installer automatically launches the pkicreate script to create the default subsystem instance automatically. A URL to access the new instance is printed to the screen which gives the subsystem instances hostname, port, and a login PIN to access the configuration wizard.
http://server.example.com:9180/ca/admin/console/config/login?pin=
2. Open the configuration wizard using the URL returned from the package installation.
Alternatively, log into the setup wizard through admin link on the services page and supply the
preop.pin value from the /var/lib/pki-ca/conf/CS.cfg file when prompted.
https://server.example.com:9444/ca/services
3. Create a new security domain.
30
The default CA instance must create a new security domain. Subsequent CAs can create a new domain or join an existing security domain, but it is recommended that each CA have its own security domain.
4. Enter a name for the new instance.
Chapter 3. Installation and Configuration
5. Set up the PKI hierarchy. Commonly, the first CA is a root, or self-signed, CA, meaning that it signs its own CA signing certificate rather than submitting its certificates to a third-party CA for issuance.
Subsequent CAs can be subordinate CAs to that root. There are many other options, depending on the PKI environment.
For a CA, there are two possible configuration options:
Root CA. A root CA signs its own CA signing certificate and, therefore, can set its own certificate issuance rules.
Subordinate CA. A subordinate CA receives its CA signing certificate from a root CA. The root
CA must be referenced here; it can be another Certificate System CA, but, for the default (i.e., first) CA instance, this will probably be an external root CA. The certificate requests generated in this process must be submitted to the external CA and be approved before configuration can be completed.
See the planning question Should the Certificate Manager be a self-signed root CA or a subordinate CA?
.
6. Fill in the information for the LDAP server which will be used for the instance's internal database.
This requires connection information for the Directory Server instance, such as the hostname, port number, bind DN (username), and password. This step also creates a database in the Directory
Server and a corresponding base directory entry (base DN) to use for the subsystem's entries.
31
Red Hat Certificate System 8.0 Install Guide
32
The hostname can be the fully-qualified domain name or an IPv4 or IPv6 address, if IPv6 was configured before the packages were installed.
NOTE
One thing that can derail subsystem configuration or function is having services that are unable to connect with each other. If servers that need to communicate with each other are on different servers or networks, when the firewalls and iptables must be configured to give the required access.
If the Red Hat Directory Server instances is on a different server or network than the
Certificate System subsystem, then make sure that the Certificate System host's firewall allows access to whatever LDAP port was set in the previous configuration panel.
Installation will not complete if iptables is not configured properly. To configure iptables, see the Red Hat Enterprise Linux Deployment Guide, such as "Using iptables." It is also possible to simply turn iptables off.
7. Select the token which will store the Certificate System certificates and keys; a list of detected hardware tokens and databases is given.
IMPORTANT
Any hardware tokens used with the instance must be configured before configuring the subsystem instance. If the HSM is not properly configured, it may not be listed in the key stores panel or the instance may not function properly. HSM configuration is described in
Section 2.5.2, “Using Hardware Security Modules with Subsystems”
.
To determine whether a token is detected by the Certificate System, use the TokenInfo tool, as
described in Section 2.5.4, “Detecting Tokens”
.
Chapter 3. Installation and Configuration
The Certificate System automatically discovers Safenet's LunaSA and nCipher's netHSM hardware security modules. The discovery process assumes that the client software installations for these modules are local to the Certificate System subsystem and are in the following locations:
LunaSA: /usr/lunasa/lib/libCryptoki2.so nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so
8. Set the key size and the hashing algorithm to use. By default, the settings for the signing key are applied to the keys for every certificate for the CA. To set different key types, sizes, or hashing algorithms for each certificate, click the [Advanced] link to expand the form so each key pair is listed.
The default RSA key size is 2048 and for ECC, 256.
33
Red Hat Certificate System 8.0 Install Guide
34
NOTE
An ECC CA signing certificate can be used to sign both ECC and RSA certificates. If you do not want to use the ECC client certificate that is generated at installation, simply replace the client certificate after configuration, and keep the ECC CA signing certificate.
An ECC module must be loaded for ECC certificates to be generated. Adding ECC support is covered in
Section 4.2, “Installing a CA with ECC Enabled”
. Any ECC-enabled PKCS#11 module must be loaded before beginning to configure the CA.
The hashing algorithms that are available depend on whether RSA or ECC is selected as the key type. For RSA, the available algorithms are as follows:
SHA256withRSA (the default)
SHA1withRSA
SHA256withRSA
SHA512withRSA
MD5withRSA
MD2withRSA
For ECC:
SHA256withEC (the default)
SHA1withEC
SHA384withEC
SHA512withEC
9. Optionally, change the subject names for the certificates.
Chapter 3. Installation and Configuration
NOTE
Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that.
Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts
(even for subsystems on different servers) will cause configuration to fail.
10. The next panels generate and show certificate requests, certificates, and key pairs.
If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the external CA. When they are issued, paste the certificates into this panel to add them to the CA database, and then proceed with the installation. Click Apply to view the certificates as they are imported.
11. If the subsystem will ever be cloned, or as a protection if keys or certificates are ever lost, back up the keys and certificates when prompted. It is also possible to extract these keys later, as long as they are not stored on an HSM.
35
Red Hat Certificate System 8.0 Install Guide
NOTE
It is not possible to export keys and certificates stored on an HSM to a .p12 file. It is also not necessary to extract keys from the HSM to clone a subsystem. The keys are already stored on the HSM and accessible to any cloned instances.
12. Provide the information for the new subsystem administrator.
13. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration.
14. When the configuration is complete, restart the subsystem.
service pki-ca restart
36
Chapter 3. Installation and Configuration
IMPORTANT
The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.
3.4. Configuring an RA
Subsystem configuration is done by accessing a unique web-based configuration page for the instance.
The only supported web browser for subsystem configuration is Mozilla Firefox.
IMPORTANT
Before any RA can be set up, a Certificate System CA must be installed, configured, and running.
This subsystem depends on the CA to issue their certificates and to create a security domain. If the security domain CA is not available, then the configuration process fails.
1. Install the subsystem packages. For example: yum install pki-ra
Once the packages are installed, then the installer automatically launches the pkicreate script to create the default subsystem instance automatically. A URL to access the new instance is printed to the screen which gives the subsystem instances hostname, port, and a login PIN to access the configuration wizard.
https://server.example.com:12889//ra/admin/console/config/login?
pin=kI7E1MByNIUcPJ6RKHmH
2. Open the configuration wizard using the URL returned by the package installation.
https://server.example.com:12889//ra/admin/console/config/login?
pin=kI7E1MByNIUcPJ6RKHmH
Alternatively, log into the setup wizard through admin link on the services page and supply the
preop.pin value from the /var/lib/pki-ra/conf/CS.cfg file when prompted.
https://server.example.com:12889/services
3. Join an existing security domain by entering the CA information. This URL can be identified by running service pki-ca status on the CA's host; the security domain URL is returned with the other configuration settings. For example: https://server.example.com:9445
When the CA is successfully contacted, then supply the admin username and password for the
CA so that it can be properly accessed.
37
Red Hat Certificate System 8.0 Install Guide
The hostname for the security domain CA can be the fully-qualified domain name or an IPv4 or
IPv6 address, if IPv6 was configured before the packages were installed.
4. Enter a name for the new instance.
38
5. Select the CA which will issue, renew, and revoke certificates for certificates processed through the RA. All of the CAs configured in the security domain are listed in a dropdown menu.
Chapter 3. Installation and Configuration
6. Click Next on the Internal Database panel; the SQLite database is created automatically.
NOTE
The RA uses a SQLite database to store its configuration and user data rather than an
LDAP database, as the other subsystems do.
7. Select the token which will store the Certificate System certificates and keys; a list of detected hardware tokens and databases is given.
IMPORTANT
Any hardware tokens used with the instance must be configured before configuring the subsystem instance. If the HSM is not properly configured, it may not be listed in the key stores panel or the instance may not function properly. HSM configuration is described in
Section 2.5.2, “Using Hardware Security Modules with Subsystems”
.
To determine whether a token is detected by the Certificate System, use the TokenInfo tool, as
described in Section 2.5.4, “Detecting Tokens”
.
The Certificate System automatically discovers Safenet's LunaSA and nCipher's netHSM hardware security modules. The discovery process assumes that the client software installations
39
Red Hat Certificate System 8.0 Install Guide for these modules are local to the Certificate System subsystem and are in the following locations:
LunaSA: /usr/lunasa/lib/libCryptoki2.so nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so
8. Set the key size. The default RSA key size is 2048.
9. Optionally, change the subject names for the certificates.
4 0
NOTE
Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that.
Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts
(even for subsystems on different servers) will cause configuration to fail.
Chapter 3. Installation and Configuration
10. The next panels generate and show certificate requests, certificates, and key pairs.
If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the CA. When they are issued, paste the certificates into this panel to add them to the subsystem database, and then proceed with the installation. Click Apply to view the certificates as they are imported.
11. Provide the information for the new subsystem administrator.
12. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration.
13. When the configuration is complete, restart the subsystem.
service pki-ra restart
4 1
Red Hat Certificate System 8.0 Install Guide
IMPORTANT
The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.
3.5. Configuring a DRM, OCSP, or TKS
Subsystem configuration is done by accessing a unique web-based configuration page for the instance.
The only supported web browser for subsystem configuration is Mozilla Firefox.
IMPORTANT
Before any DRM, OCSP, or TKS subsystem can be set up, a Certificate System CA must be installed, configured, and running. These subsystems depend on the CA to issue their certificates and to create a security domain. If the security domain CA is not available, then the configuration process fails.
1. Install the subsystem packages. For example, to install a DRM: yum install pki-kra
NOTE
A Data Recovery Manager (DRM) is also known as a Key Recovery Agent (KRA). All command-line tools and many files for the DRM use the abbreviation kra for this reason. In the documentation, the subsystem used to archive and recover keys is called the DRM or
KRA interchangeably.
4 2
Once the packages are installed, then the installer automatically launches the pkicreate script to create the default subsystem instance automatically. A URL to access the new instance is printed to the screen which gives the subsystem instances hostname, port, and a login PIN to access the configuration wizard.
http://server.example.com:10180/kra/admin/console/config/login?
pin=kI7E1MByNIUcPJ6RKHmH
2. Open the configuration wizard using the URL returned by the package installation.
http://server.example.com:10180/kra/admin/console/config/login?
pin=kI7E1MByNIUcPJ6RKHmH
Alternatively, log into the setup wizard through admin link on the services page and supply the
preop.pin value from the /var/lib/subsystem_name/conf/CS.cfg file when prompted.
https://server.example.com:10444/kra/services
3. Join an existing security domain by entering the CA information. This URL can be identified by running service pki-ca status on the CA's host; the security domain URL is returned with
Chapter 3. Installation and Configuration the other configuration settings. For example: https://server.example.com:9445
When the CA is successfully contacted, then supply the admin username and password for the
CA so that it can be properly accessed.
4. Enter a name for the new instance.
5. Select the CA which will perform the operations processed through the subsystem, such as key archival.
4 3
Red Hat Certificate System 8.0 Install Guide
6. Fill in the information for the LDAP server which will be used for the instance's internal database.
This requires connection information for the Directory Server instance, such as the hostname, port number, bind DN (username), and password. This step also creates a database in the Directory
Server and a corresponding base directory entry (base DN) to use for the subsystem's entries.
4 4
The hostname can be the fully-qualified domain name or an IPv4 or IPv6 address.
NOTE
One thing that can derail subsystem configuration or function is having services that are unable to connect with each other. If servers that need to communicate with each other are on different servers or networks, when the firewalls and iptables must be configured to give the required access.
If the Red Hat Directory Server instances is on a different server or network than the
Certificate System subsystem, then make sure that the Certificate System host's firewall allows access to whatever LDAP port was set in the previous configuration panel.
Installation will not complete if iptables is not configured properly. To configure iptables, see the Red Hat Enterprise Linux Deployment Guide, such as "Using iptables." It is also possible to simply turn iptables off.
7. Select the token which will store the Certificate System certificates and keys; a list of detected hardware tokens and databases is given.
Chapter 3. Installation and Configuration
IMPORTANT
Any hardware tokens used with the instance must be configured before configuring the subsystem instance. If the HSM is not properly configured, it may not be listed in the key stores panel or the instance may not function properly. HSM configuration is described in
Section 2.5.2, “Using Hardware Security Modules with Subsystems”
.
To determine whether a token is detected by the Certificate System, use the TokenInfo tool, as
described in Section 2.5.4, “Detecting Tokens”
.
The Certificate System automatically discovers Safenet's LunaSA and nCipher's netHSM hardware security modules. The discovery process assumes that the client software installations for these modules are local to the Certificate System subsystem and are in the following locations:
LunaSA: /usr/lunasa/lib/libCryptoki2.so nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so
8. Set the key size. The default RSA key size is 2048.
4 5
Red Hat Certificate System 8.0 Install Guide
9. Optionally, change subject names to the listed certificates.
NOTE
Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that.
Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts
(even for subsystems on different servers) will cause configuration to fail.
10. The next panels generate and show certificate requests, certificates, and key pairs.
4 6
Chapter 3. Installation and Configuration
If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the CA. When they are issued, paste the certificates into this panel to add them to the subsystem database, and then proceed with the installation. Click Apply to view the certificates as they are imported.
11. Provide the information for the new subsystem administrator.
12. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration.
13. When the configuration is complete, restart the subsystem.
service pki-kra restart
IMPORTANT
The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.
3.6. Configuring a TPS
4 7
Red Hat Certificate System 8.0 Install Guide
Subsystem configuration is done by accessing a unique web-based configuration page for the instance.
The only supported web browser for subsystem configuration is Mozilla Firefox.
IMPORTANT
Before the TPS can be set up, a Certificate System CA and TKS must be installed and configured.
If you want to enable server-side key generation, then the DRM must also be installed and configured. The TPS configuration wizard automatically establishes relationships between the
CA, TKS, and DRM and the TPS, so specific CA, TKS, and DRM instances must be available to the TPS.
1. Install the subsystem packages. For example: yum install pki-tps
Once the packages are installed, then the installer automatically launches the pkicreate script to create the default subsystem instance automatically. A URL to access the new instance is printed to the screen which gives the subsystem instances hostname, port, and a login PIN to access the configuration wizard.
2. Open the configuration wizard using the URL returned by the package installation. For example: http://server.example.com:7888/tps/admin/console/config/login?
pin=kI7E1MByNIUcPJ6RKHmH
Alternatively, log into the setup wizard through admin link on the services page and supply the
preop.pin value from the /var/lib/pki-tps/conf/CS.cfg file when prompted.
http://server.example.com:7888/tps/services
3. Join an existing security domain by entering the CA information. This URL can be identified by running service pki-ca status on the CA's host; the security domain URL is returned with the other configuration settings. For example: https://server.example.com:9445
When the CA is successfully contacted, then supply the admin username and password for the
CA so that it can be properly accessed.
4 8
4. Enter a name for the new instance.
Chapter 3. Installation and Configuration
5. Select the CA which will issue, renew, and revoke certificates for token operations requested through the TPS subsystem.
6. Supply information about the TKS which will manage the TPS keys. Select the TKS from the dropdown menu of TKS subsystems within the security domain.
7. There is an option for server-side key generation for tokens enrolled through the TPS. If serverside key generation is selected, supply information about the DRM which will generate keys and archive encryption keys. Key and certificate recovery is initiated automatically through the TPS,
4 9
Red Hat Certificate System 8.0 Install Guide which is a DRM agent. Select the DRM from the drop-down menu of DRM subsystems within the security domain.
The hostname for the DRM can be the fully-qualified domain name or an IPv4 or IPv6 address.
8. Fill in the Directory Server authentication directory. This directory is used by the TPS to authenticate users which access the Enterprise Security Client and as an additional database for certificates and keys.
This Directory Server instance is not the same Directory Server instance used as the TPS's internal database. This is a general user directory, which may be accessed by other applications or users. The TPS's internal database is used exclusively by the TPS and is created on the fly as the TPS is configured.
50
The hostname of the LDAP server can be the fully-qualified domain name or an IPv4 or IPv6 address.
9. Fill in the information for the LDAP server which will be used for the instance's internal database.
This requires connection information for the Directory Server instance, such as the hostname, port number, bind DN (username), and password. This step also creates a database in the Directory
Server and a corresponding base directory entry (base DN) to use for the subsystem's entries.
Chapter 3. Installation and Configuration
The hostname can be the fully-qualified domain name or an IPv4 or IPv6 address.
NOTE
One thing that can derail subsystem configuration or function is having services that are unable to connect with each other. If servers that need to communicate with each other are on different servers or networks, when the firewalls and iptables must be configured to give the required access.
If the Red Hat Directory Server instances is on a different server or network than the
Certificate System subsystem, then make sure that the Certificate System host's firewall allows access to whatever LDAP port was set in the previous configuration panel.
Installation will not complete if iptables is not configured properly. To configure iptables, see the Red Hat Enterprise Linux Deployment Guide, such as "Using iptables." It is also possible to simply turn iptables off.
10. Select the token which will store the Certificate System certificates and keys; a list of detected hardware tokens and databases is given.
IMPORTANT
Any hardware tokens used with the instance must be configured before configuring the subsystem instance. If the HSM is not properly configured, it may not be listed in the key stores panel or the instance may not function properly. HSM configuration is described in
Section 2.5.2, “Using Hardware Security Modules with Subsystems”
.
To determine whether a token is detected by the Certificate System, use the TokenInfo tool, as
described in Section 2.5.4, “Detecting Tokens”
.
51
Red Hat Certificate System 8.0 Install Guide
The Certificate System automatically discovers Safenet's LunaSA and nCipher's netHSM hardware security modules. The discovery process assumes that the client software installations for these modules are local to the Certificate System subsystem and are in the following locations:
LunaSA: /usr/lunasa/lib/libCryptoki2.so nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so
11. Set the key size.
12. Optionally, change subject names to the listed certificates.
52
Chapter 3. Installation and Configuration
NOTE
Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that.
Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts
(even for subsystems on different servers) will cause configuration to fail.
13. The next panels generate and show certificate requests, certificates, and key pairs.
If an external CA is used to issue the certificates, configuration cannot go forward until they are
53
Red Hat Certificate System 8.0 Install Guide received from the CA. When they are issued, paste the certificates into this panel to add them to the TPS database, and then proceed with the installation. Click Apply to view the certificates as they are imported.
14. Provide the information for the new subsystem administrator.
15. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration.
16. When the configuration is complete, restart the subsystem.
service pki-tps restart
IMPORTANT
The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.
54
