Chapter 18. Subsystem control and maintenance This chapter provides information on how to control (start, stop, restart, and status check) a Red Hat Certificate System subsystem, as well as general maintenance (health check) recommendation. 18.1. Starting, stopping, restarting and obtaining status You can start and stop the Red Hat Certificate System subsystem instances using the systemctl utility on Red Hat Enterprise Linux 8. Note You can also use the pki-server alias to start and stop instances: pki-server <command> <instance> is an alias to systemctl <command> pki-tomcatd@ <instance> .service . To start an instance: To stop an instance: To restart an instance: To display the status of an instance: unit_file has one of the following values: pki-tomcat : with watchdog disabled pki-tomcat-nuxwdog : with watchdog enabled 18.2. Subsystem health check It is important for administrators to periodically monitor possible failures, such as the following: Audit failure caused by a full disk Signing failure caused by HSM connection issue LDAP server connection issues And so on Self-tests can also be run by demand as described in Chapter 10, Self-tests . PKI Healthcheck is a command-line tool that helps find issues that may impact the health of your Certificate System environment. If needed, this tool can report to the Healthcheck tool present in Red Hat Identity Management. 18.2.1. PKI Healthcheck Test Modules PKI Healthcheck consists of independent modules that test for: Certificate sync between CS.cfg and NSS database Checks whether the system certificates in CS.cfg (located in /var/lib/pki/<instance>/<subsystem>/conf/CS.cfg ) and NSS database (located in /var/lib/pki/<instance>/alias/ ) match. Else, the Certificate Authority (CA) fails to start. System certificate expiry Checks the expiry status of the installed system certificates (See System Certificates for more information). System certificate trust flags Checks whether the installed system certificates carry the correct Trust flags (See System Certificates for more information). Subsystem connectivity check Checks whether a subsystem is running and able to respond to requests. Subsystem clones connectivity and data check Checks simple connectivity and data sanity for a set of clones configured within a given CS subsystem. A given CA subsystem's security domain is consulted to identify clones that have been set. The check then proceeds to reach out to each clone and verify data sanity where applicable. 18.2.2. PKI Healthcheck configuration The PKI Healthcheck tool configuration is stored at /etc/pki/healthcheck.conf . It looks like the following: 18.2.3. Running PKI Healthcheck To perform a health check, run the pki-healthcheck command. You can also execute a specific check. For example: For more information on the possible options, see the man page: man pki-healthcheck . 18.2.4. PKI Healthcheck output formats Healthcheck generates the following outputs, which you can set using the --output-type : By default, machine-readable output in JSON format ( json ). Alternatively, human-readable output ( human ). You can specify a alternative file destination with the --output-file option. 18.2.5. PKI Healthcheck results The report consists of a message describing what was run and the status. Each health check module returns one of the following results: SUCCESS configured as expected, the check executed and found no issue WARNING not an error, but worth keeping an eye on or evaluating (e.g. a certificate will expire soon) ERROR not configured as expected, something is wrong but your server is probably still working (e.g. a clone conflict) CRITICAL not configured as expected, with a high possibility for impact (e.g. a service is not started, certificates are expired, etc.) If the status is not successful, the message may include additional information or recommandations, which can be used by the admin to correct the issue (e.g. a file has the wrong permissions, expected X and got Y).

Commands:
*systemctl start unit_file@instance_name.service*
pki-server start instance_name
*systemctl stop unit_file@instance_name.service*
pki-server stop instance_name
*systemctl restart unit_file@instance_name.service*
pki-server restart instance_name
*systemctl status unit_file@instance_name.service*
[global] plugin_timeout=300 cert_expiration_days=30 # Dogtag specific section [dogtag] instance_name=pki-tomcat
pki-healthcheck --source pki.server.healthcheck.meta.csconfig --check DogtagCertsConfigCheck