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. 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. Stop the Directory Server instance before accessing the NSS database: Delete the old Directory Server certificate: Import the CA certificate downloaded earlier: Import the new Directory Server certificate downloaded earlier: See also Section 15.4, "Importing a certificate into an HSM" . Start the Directory Server instance: Remove the old Directory Server Certificate from PKI CA: Stop the Certificate System instance: Remove the certificate: Start the Certificate System instance: Verify that the new Directory Server certificate is signed by the CA installed in the NSS database: Display the Directory Server certificate Verify the old Directory Server certificate no longer exists in the PKI NSS database: Verify Certificate System can connect to Directory Server using the new certificate: 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: For example 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: As shown below: 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. For details about enabling the CMC Shared Token Feature, see Section 14.8.3, "Enabling the CMC Shared Secret Feature" . For details about enabling the PopLinkWittness feature, see Section 14.8.2, "Enabling the PopLinkWittnessV2 Feature" . For details about enabling CMCRevoke for the web user interface, see Section 14.8.4, "Enabling CMCRevoke for the Web User Interface" . 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 .

Commands:
systemctl stop dirsrv@ instance_name
certutil -F -d /etc/dirsrv/slapd- instance_name -f /etc/dirsrv/slapd- instance_name /password.txt -n "DS Certificate"
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
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
systemctl start dirsrv@ instance_name
systemctl stop pki-tomcatd@ instance_name .service
certutil -D -d /var/lib/pki/ instance_name /alias/ -n "DS Certificate"
systemctl start pki-tomcatd@ instance_name .service
certutil -L -d /etc/dirsrv/slapd- instance_name -n "DS Certificate" Issuer: "CN=CA Signing Certificate,O=EXAMPLE" Subject: "CN=server.example.com"
certutil -L -d /var/lib/pki/ instance_name /alias
pki cert-find
certmap rhcs <certificate issuer DN> rhcs:CmapLdapAttr seeAlso rhcs:verifyCert on
certmap rhcs CN=CA Signing Certificate,OU=pki-tomcat-ca,O=pki-tomcat-ca-SD rhcs:CmapLdapAttr seeAlso rhcs:verifyCert on
internaldb.ldapauth.bindDN internaldb.ldapauth.bindPWPrompt
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