7.10. Post-installation Tasks

Once installation using the pkispawn utility is complete, further steps could be taken to customize the configuration, depending on the site's preferences. These are described in Part III, “Configuring Certificate System”.
This section provides a list of operations from Part III, “Configuring Certificate System” which are suggested for improving the security for the deployment.

7.10.1. Setting Date/Time for RHCS

It is important to have the time set up correctly for running RHCS; see the Setting Time and Date section in the Red Hat Certificate System Administration Guide.

7.10.2. Replacing the Temporary Certificate

Note

This section requires a root CA installed and running. These steps are to be performed once the installation is complete.
The following procedure describes the process to replace the temporary self-signed Directory Server certificate with a permanent Directory Server certificate issued by the newly-installed CA, or to replace an old Directory Server certificate with a new one.
  1. Obtain a new Directory Server server certificate. Submit the request for the new certificate signed by the CA. To get a new Directory Server certificate using the CMC method, see the Obtaining System and Server Certificates section in the Red Hat Certificate System Administration Guide.
    In the above section, follow the guidance to create a TLS server certificate. Once the certificate is created, it must be imported back into the Directory Server's certificate database.
  2. Stop the Directory Server instance before accessing the NSS database: 
    # systemctl stop dirsrv@instance_name
  3. Delete the old Directory Server certificate: 
    # certutil -F -d /etc/dirsrv/slapd-instance_name -f /etc/dirsrv/slapd-instance_name/password.txt -n "DS Certificate"
  4. Import the CA certificate downloaded earlier: 
    # PKICertImport -d /etc/dirsrv/slapd-instance_name -f /etc/dirsrv/slapd-instance_name/password.txt -n "CA Certificate" -t "CT,C,C" -a -i ca.crt -u L
  5. Import the new Directory Server certificate downloaded earlier: 
    # PKICertImport -d /etc/dirsrv/slapd-instance_name -f /etc/dirsrv/slapd-instance_name/password.txt -n "DS Certificate" -t ",," -a -i ds.crt -u V
    See also Section 15.4, “Importing a certificate into an HSM”.
  6. Start the Directory Server instance: 
    # systemctl start dirsrv@instance_name
  7. Remove the old Directory Server Certificate from PKI CA:
    1. Stop the Certificate System instance: 
      # systemctl stop pki-tomcatd@instance_name.service
    2. Remove the certificate: 
      # certutil -D -d /var/lib/pki/instance_name/alias/ -n "DS Certificate"
    3. Start the Certificate System instance: 
      # systemctl start pki-tomcatd@instance_name.service
  8. Verify that the new Directory Server certificate is signed by the CA installed in the NSS database:
    1. Display the Directory Server certificate 
      $ certutil -L -d /etc/dirsrv/slapd-instance_name -n "DS Certificate"

		Issuer: "CN=CA Signing Certificate,O=EXAMPLE"
		Subject: "CN=server.example.com"
    2. Verify the old Directory Server certificate no longer exists in the PKI NSS database: 
      $ certutil -L -d /var/lib/pki/instance_name/alias
    3. Verify Certificate System can connect to Directory Server using the new certificate: 
      $ pki cert-find

7.10.3. Enabling TLS Client Authentication

Note

This section requires a root CA installed and running. If you used a temporary LDAP server certificate, replace it first by following Section 7.10.2, “Replacing the Temporary Certificate”. These steps are to be performed once the installation is complete.
If you choose to enable TLS client authentication, once the basic TLS server authentication has been configured and running when installing the CS subsystem, we can now double back and attempt to enable client authentication from a given subsystem to the LDAP server.
There are two parts to setting up client authentication. The first part is configuring the LDAP directory to require TLS mutual authentication. This procedure is detailed in Using Certificate-based Client Authentication in the Red Hat Directory Server Administration Guide.
Note the following:
  • pkispawn already automatically created a pkidbuser on its internal directory server, where the CS instance's "subsystem certificate" (for example subsystemCert cert-pki-ca) that is used for outbound TLS client authentication is stored in the user entry. Therefore, there is no need to create another LDAP user or another certificate for the TLS client-authentication.
  • When creating content for /etc/dirsrv/slapd-instance_name/certmap.conf, use the following format: 
    certmap rhcs <certificate issuer DN>
		rhcs:CmapLdapAttr seeAlso
		rhcs:verifyCert on
    For example 
    certmap rhcs CN=CA Signing Certificate,OU=pki-tomcat-ca,O=pki-tomcat-ca-SD
		rhcs:CmapLdapAttr seeAlso
		rhcs:verifyCert on
  • After configuring, restart the Directory Server.
The second part is adding configuration to the Red Hat Certificate System instance so that it knows which port and certificate is to be used to communicate with its internal LDAP server using TLS mutual authentication. This involves editing the RHCS instance's CS.cfg file located at <instance directory>/<subsystem type>/conf/CS.cfg. For example /var/lib/pki/instance_name/ca/conf/CS.cfg
In the CS.cfg, please add the RHCS instance's subsystem certificate nickname to internaldb.ldapauth.clientCertNickname, and remove the two unused entries: 
internaldb.ldapauth.bindDN
		internaldb.ldapauth.bindPWPrompt
As shown below: 
internaldb._000=##
		internaldb._001=## Internal Database
		internaldb._002=##
		internaldb.basedn=o=pki-tomcat-ca-SD
		internaldb.database=pki-tomcat-ca
		internaldb.maxConns=15
		internaldb.minConns=3
		internaldb.ldapauth.authtype=SslClientAuth
		internaldb.ldapauth.clientCertNickname=HSM-A:subsystemCert pki-tomcat-ca
		internaldb.ldapconn.host=example.com
		internaldb.ldapconn.port=11636
		internaldb.ldapconn.secureConn=true
Restart the CS instance at the end of the Post-installation step.

Note

The internaldb.basedn and internaldb.database parameters must be configured to match your specific LDAP instance.
For compliance, internaldb.ldapauth.authtype=SslClientAuth and internaldb.ldapconn.secureConn=true must be set, and the value of the internaldb.ldapauth.clientCertNickname must match the nickname of the TLS client certificate to authenticate against LDAP with in the NSS DB.
All other values can be changed as desired to reflect your environment or availability needs.

7.10.4. Configuring Session Timeout

Various timeout configurations exist on the system that could affect how long a TLS session is allowed to remain idle before termination. For details, see Section 14.4.2, “Session Timeout”.

7.10.5. CRL or Certificate Publishing

CRL publishing is critical in providing OCSP service. Certificate publishing is optional but often desired by sites. For details, see the Publishing Certificates and CRLs section in the Red Hat Certificate System Administration Guide.

7.10.6. Configuring Certificate Enrollment Profiles (CA)

RHCS has a rich profile framework that allows for customization of the certificate enrollment profiles. It is very common for a site to enable/disable default profiles that come with the system, or modify existing profiles, or create their own profiles. For details, see Chapter 16, Certificate Profiles Configuration.

7.10.7. Enabling Access Banner

To enable user interface banners, refer to Section 14.7.1, “Enabling an Access Banner”.

7.10.8. Enabling the Watchdog Service

The watchdog (nuxwdog) service provides secure system password management. For details, see Section 14.3.2.1, “Enabling the Watchdog Service”.

7.10.9. Configuration for CMC Enrollment and Revocation (CA)

Certificate enrollments and revocation can be done via CMC.

7.10.10. TLS client-authentication for the Java Console

To require Certificate System administrators to present a user TLS client certificate when logging into the Java console, see Section 14.2.3.15, “Setting Requirement for pkiconsole to use TLS Client Certificate Authentication”.

Note

pkiconsole is being deprecated.

7.10.11. Creating a Role User

Create real role users so that you can remove the bootstrap user.
To create users and assign them to different privileged roles to manage Certificate System, see Chapter 19, Creating a Role User.

7.10.12. Removing the Bootstrap User

Once the real role users are created, the bootstrap user that was created automatically during the installation is not needed anymore. To delete this account, see Chapter 20, Deleting the Bootstrap User after making sure you created a new administrator account assigned to an individual person.

7.10.13. Disabling Multi-role Support

To disable the multi-role support once the bootstrap user is removed, see Section 20.1, “Disabling Multi-roles Support”.

7.10.14. KRA Configurations

7.10.14.1. Adding Requirement for Multiple Agent Approval for Key Recovery Authority (KRA)

To set up a requirement for multiple KRA agents to approve key recovery, see the Configuring Agent-Approved Key Recovery in the Command Line section in the Red Hat Certificate System Administration Guide.

7.10.14.2. Configuring KRA Encryption Settings

To configure key encryption/wrapping algorithms, see Section 17.2, “Encryption Of KRA Operations”.

7.10.15. Setting up Users to use User Interfaces

Before a user could use an approved user interface, initialization needs to be performed. Users (administrative roles or otherwise) are required to setup their clients for accessing the user interface. See the Client NSS Database Initialization section in the Red Hat Certificate System Administration Guide.