Install RHCS and deploy the subsystem
This section outlines the basic installation method for RHCS. It assumes that you already installed Red Hat Enterprise Linux (RHEL), subscribed the system to the Red Hat subscription management service, attached the RHCS subscription, and enabled the required repositories. Refer to the RHCS Get Started article for instructions on how to perform the preceding actions.
Perform the tasks in the following sections to install RHCS and deploy the subsystem.
RHCS requires Red Hat Directory Server, which serves as an internal repository for certificate requests, certificates, and so on. Install the directory server packages by using the following command:
Run the directory server installation script, selecting the defaults or customizing as needed:
By default, Red Hat Directory Server does not automatically run on system startup. Run the following command to ensure that the directory server starts automatically when the computer is rebooted:
Run the following command to install the certificate system packages:
If you want to deploy an RHCS subsystem on a Hardware Security Module (HSM) and run SELinux in enforcing mode, you must manually update certain SELinux and firewalld settings before deploying the subsystem. The following section describes the required actions:
Run the following commands to reset the context of the fxpkcs11.cfg file and the main fxpkcs11 directory, modifying the paths to match the locations of the fxpkcs11.cfg file and the main fxpkcs11 directory on your system:
Run the following commands to allow outbound connections to TCP port 2001, the System/Host API port on the KMES:
Use the pkispawn command line tool to install and configure a new PKI instance. The command eliminates the need for separate installation and configuration steps, and you can run it interactively, as a batch process, or a combination of both (that is, a batch process with prompts for passwords). Refer to pkispawn documentation for detailed information about all supported options by running the following command: man pkispawn.
The pkispawn command reads in its default installation and configuration values from a plain text configuration file: (/etc/pki/default.cfg). This file consists of name=value pairs divided into [DEFAULT], [Tomcat], [CA], [KRA], [OCSP], [TKS], and [TPS] sections.
We strongly recommend that you read the full documentation to understand the purpose of every parameter in the /etc/pki/default.cfg file. This enables you to customize your PKI environment to your specific needs.
Red Hat recommends a procedure for spawning a subsystem that uses an HSM to create an override configuration file that contains only the parameters necessary for using the HSM as its token. Any parameter settings in this file override the parameter settings in the default.cfg file.
The system can spawn any of the various RHCS subsystems (CA, KRA, OCSP, TKS, and TPS) to use the HSM, but this integration guide focuses solely on the Certificate Authority (CA) subsystem for brevity.
In a terminal, go to the directory where you installed the Futurex PKCS #11 module on your system (such as /usr/local/bin/fxpkcs11).
Run the following sudo vim command:
You can use the following example override file to spawn a CA subsystem with the KMES, setting the values in angle brackets to your specifications:
The pki_ds_password value must match the password set for the directory manager when you installed the Red Hat Directory Server.
Save the file.
In a terminal, run the following command to deploy a CA subsystem using the KMES Series 3:
The full path to the default_futurex.txt file is required if you are not running the command from the same directory where default_futurex.txt is saved.
If the deployment succeeds, an installation summary similar to the following displays after the command completes:
If the pkispawn command fails, you must perform the following steps before re-attempting to run the command:
Log in to the KMES Series 3 application interface, go to PKI > Certificate Authorities, and confirm if a certificate container named CA Signing Certificate exists. If you can find it, you must delete the CA Signing Certificate certificate container (which also deletes all certificates inside it). If you don't delete the certificate container before running pkispawn again, the command will fail.
Delete the partially created CA subsystem instance by running the following command:
Then, execute the steps in the Run the pkispawn utility section.
To view the keys and certificates that RHCS created on the KMES, perform the following steps:
Log in to the KMES Series 3 application interface with the default Admin identities.
Go to the PKI > Certificate Authorities menu.
All of the certificates that RHCS created for the CA subsystem instance display in the CA Signing Certificate X.509 certificate container.
Go to the Key Management > Keys menu and select the ASYM-RHCS asymmetric key group.
In the Keys section, you can see the private keys of the certificates viewed in step 2 of this workflow.
The following steps use a Firefox web browser. The steps might vary when using a different browser, but the basic process is same.
In Firefox, go to Settings > Privacy & Security > Certificates and select [ View Certificates ].
On the Your Certificates tab, select [ Import ] to import the CA Administrator PKCS #12 file, ca_ admin_cert.p12. The location of the ca_admin_cert.p12 file was included in the installation summary for the CA subsystem deployment
When prompted for a password, enter the value that was configured for the pki_client_ pkcs12_password define in the default_futurex.txt file.
Access the Red Hat Certificate System subsystem console by navigating to the following URL:
When submitting CSRs in RHCS, you must include both the Common Name and UID fields. If you submit a request with only the Common Name field completed, the request fails, and you receive an error stating that the Subject Name does not match.