Chapter 13. Configuring logs The Certificate System subsystem log files record events related to operations within that specific subsystem instance. For each subsystem, different logs are kept for issues such as installation, access, and web servers. All subsystems have similar log configuration, options, and administrative paths. For details about log administration after the installation, see Chapter 12 Configuring Subsystem Logs in the Administration Guide (Common Criteria Edition) . For an overview on logs, see Section 2.3.14, "Logs" . 13.1. Log settings The way that logs are configured can affect Certificate System performance. For example, log file rotation keeps logs from becoming too large, which slows down subsystem performance. This section explains the different kinds of logs recorded by Certificate System subsystems and covers important concepts such as log file rotation, buffered logging, and available log levels. 13.1.1. Services that are logged All major components and protocols of Certificate System log messages to log files. The following table lists services that are logged by default. To view messages logged by a specific service, customize log settings accordingly. For details, see Section 13.1.5, "Signing log files" Table 13.1. Services logged Service Description ACLs Logs events related to access control lists. Administration Logs events related to administration activities, such as HTTPS communication between the Console and the instance. All Logs events related to all the services. Authentication Logs events related to activity with the authentication module. Certificate Authority Logs events related to the Certificate Manager. Database Logs events related to activity with the internal database. HTTP Logs events related to the HTTP activity of the server. Note that HTTP events are actually logged to the errors log belonging to the Apache server incorporated with the Certificate System to provide HTTP services. Key Recovery Authority Logs events related to the KRA. LDAP Logs events related to activity with the LDAP directory, which is used for publishing certificates and CRLs. OCSP Logs events related to OCSP, such as OCSP status GET requests. Others Logs events related to other activities, such as command-line utilities and other processes. Request Queue Logs events related to the request queue activity. User and Group Logs events related to users and groups of the instance. 13.1.2. Log levels (message categories) The different events logged by Certificate System services are determined by the log levels, which makes identifying and filtering events simpler. The different Certificate System log levels are listed in Table 13.2, "Log levels and corresponding log messages" . Log levels are represented by numbers 0 to 10 , each number indicating the level of logging to be performed by the server. The level sets how detailed the logging should be. A higher priority level means less detail because only events of high priority are logged. Note The default log level is 1 and this value should not be changed. To enable debug logging, see Section 13.3.3, "Additional configuration for debug log" . The following table is provided for reference to better understand log messages. Table 13.2. Log levels and corresponding log messages Log level Message category Description 0 Debugging These messages contain debugging information. This level is not recommended for regular use because it generates too much information. 1 Informational (default selection for audit log) These messages provide general information about the state of the Certificate System, including status messages such as Certificate System initialization complete and Request for operation succeeded . 2 Warning These messages are warnings only and do not indicate any failure in the normal operation of the server. 3 Failure; the default selection for system and error logs These messages indicate errors and failures that prevent the server from operating normally, including failures to perform a certificate service operation ( User authentication failed or Certificate revoked ) and unexpected situations that can cause irrevocable errors ( The server cannot send back the request it processed for a client through the same channel the request came from the client ). 4 Misconfiguration These messages indicate that a misconfiguration in the server is causing an error. 5 Catastrophic failure These messages indicate that, because of an error, the service cannot continue running. 6 Security-related events These messages identify occurrences that affect the security of the server. For example, Privileged access attempted by user with revoked or unlisted certificate. 7 PDU-related events (debugging) These messages contain debugging information for PDU events. This level is not recommended for regular use because it generates more information than is normally useful. 8 PDU-related events These messages relate transactions and rules processed on a PDU, such as creating MAC tokens. 9 PDU-related events This log levels provides verbose log messages for events processed on a PDU, such as creating MAC tokens. 10 All logging levels This log level enables all logging levels. Log levels can be used to filter log entries based on the severity of an event. The log level is successive; specifying a value of 3 causes levels 4, 5, and 6 to be logged. Log data can be extensive, especially at lower (more verbose) logging levels. Make sure that the host machine has sufficient disk space for all the log files. It is also important to define the logging level, log rotation, and server-backup policies appropriately so that all the log files are backed up and the host system does not get overloaded; otherwise, information can be lost. 13.1.3. Buffered and unbuffered logging The Java subsystems support buffered logging for all types of logs. The server can be configured for either buffered or unbuffered logging. If buffered logging is configured, the server creates buffers for the corresponding logs and holds the messages in the buffers for as long as possible. The server flushes out the messages to the log files only when one of the following conditions occurs: The buffer gets full. The buffer is full when the buffer size is equal to or greater than the value specified by the bufferSize configuration parameter. The default value for this parameter is 512 KB. The flush interval for the buffer is reached. The flush interval is reached when the time interval since the last buffer flush is equal to or greater than the value specified by the flushInterval configuration parameter. The default value for this parameter is 5 seconds. When current logs are read from Console. The server retrieves the latest log when it is queried for current logs. If the server is configured for unbuffered logging, the server flushes out messages as they are generated to the log files. Because the server performs an I/O operation (writing to the log file) each time a message is generated, configuring the server for unbuffered logging decreases performance. Setting log parameters is described in Chapter 13, Configuring logs . 13.1.4. Log file rotation The subsystem logs have an optional log setting that allows them to be rotated and start a new log file instead of letting log files grow indefinitely. Log files are rotated when either of the following occur: The size limit for the corresponding file is reached. The size of the corresponding log file is equal to or greater than the value specified by the maxFileSize configuration parameter. The default value for this parameter is 2000 KB. The age limit for the corresponding file is reached. The corresponding log file is equal to or older than the interval specified by the rolloverInterval configuration parameter. The default value for this parameter is 2592000 seconds (every thirty days). Note Setting both these parameters to 0 effectively disables the log file rotation. When a log file is rotated, the old file is named using the name of the file with an appended time stamp. The appended time stamp is an integer that indicates the date and time the corresponding active log file was rotated. The date and time have the forms YYYYMMDD (year, month, day) and HHMMSS (hour, minute, second). Log files, especially the audit log file, contain critical information. These files should be periodically archived to some backup medium by copying the entire log directory to an archive medium. Note Certificate System does not provide any tool or utility for archiving log files. Section 13.1.5, "Signing log files" suggests ways to ensure the integrity of the log files to be archived. 13.1.5. Signing log files As an alternative to the signed audit log feature ( Section 13.3.1.1, "Enabling signed audit logging" ), which creates audit logs where audit entries are automatically signed, log files can be signed by using COTS tools such as gpg , before they are archived or distributed for audit purposes. Doing so will allow to check files for tampering. 13.2. Operating system (external to RHCS) log settings 13.2.1. Enabling OS-level audit logs Warning All operations in the following sections have to be performed as root or a privileged user via sudo . The auditd logging framework provides many additional audit capabilities. These OS-level audit logs complement functionality provided by Certificate System directly. Before performing any of the following steps in this section, make sure the audit package is installed: Auditing of system package updates (using yum and rpm and including Certificate System) is automatically performed and requires no additional configuration. Note After adding each audit rule and restarting the auditd service, validate the new rules were added by running: The contents of the new rules should be visible in the output. For instructions on viewing the resulting audit logs, see 12.2.3 Displaying OS-level audit logs in the Administration Guide (Common Criteria Edition) . 13.2.1.1. Auditing Certificate System audit log deletion To receive audit events for when audit logs are deleted, you need to audit system calls whose targets are Certificate System logs. Create the file /etc/audit/rules.d/rhcs-audit-log-deletion.rules with the following contents: Then restart auditd : 13.2.1.2. Auditing unauthorized Certificate System use of secret keys To receive audit events for all access to Certificate System Secret or Private keys, you need to audit the file system access to the nssdb. Create the /etc/audit/rules.d/rhcs-audit-nssdb-access.rules file with the following contents: <instance name> is the name of the current instance. For each file ( <file> ) in /etc/pki/<instance name>/alias , add to /etc/audit/rules.d/rhcs-audit-nssdb-access.rules the following line : For example, if the instance name is pki-ca121318ec and cert9.db , key4.db , NHSM-CONN-XCcert9.db , NHSM-CONN-XCkey4.db , and pkcs11.txt are files, then the configuration file would contain: Then restart auditd : 13.2.1.3. Auditing time change events To receive audit events for time changes, you need to audit a system call access which could modify the system time. Create the /etc/audit/rules.d/rhcs-audit-rhcs_audit_time_change.rules file with the following contents: Then restart auditd : For instructions on how to set time, see Section 7.13.1, "Setting date and time for RHCS" . 13.2.1.4. Auditing access to Certificate System configuration To receive audit events for all modifications to the Certificate System instance configuration files, audit the file system access for these files. Create the /etc/audit/rules.d/rhcs-audit-config-access.rules file with the following contents: Additionally, add for each subsystem in the /etc/pki/instance_name/ directory the following contents: Example 13.1. rhcs-audit-config-access.rules configuration file For example, if the instance name is pki-ca121318ec and only a CA is installed, the /etc/audit/rules.d/rhcs-audit-config-access.rules file would contain: Note that access to the PKI NSS database is already audited under rhcs_audit_nssdb . 13.3. Configuring Logs in the CS.cfg File During the installation configuration, you can configure the logging by directly editing the CS.cfg for the instance. Stop the subsystem instance. Open the CS.cfg file in the /var/lib/pki/<instance_name>/<subsystem_type>/conf directory. Create a new log. To configure a log instance, modify the parameters associated with that log. These parameters begin with log.instance . Table 13.3. Log entry parameters Parameter Description type The type of log file. e.g. signedAudit . enable Sets whether the log is active. Only enabled logs actually record events. level Sets the log level in the text field. The level must be manually entered in the field; there is no selection menu. The log level setting is a numeric value, as listed in Section 13.1.2, "Log levels (message categories)" . fileName The full path, including the file name, to the log file. The subsystem user should have read/write permission to the file. bufferSize The buffer size in kilobytes (KB) for the log. Once the buffer reaches this size, the contents of the buffer are flushed out and copied to the log file. The default size is 512 KB. For more information on buffered logging, see Section 13.1.3, "Buffered and unbuffered logging" . flushInterval The amount of time, in seconds, before the contents of the buffer are flushed out and added to the log file. The default interval is 5 seconds. maxFileSize The size, kilobytes (KB), a log file can become before it is rotated. Once it reaches this size, the file is copied to a rotated file, and the log file is started new. For more information on log file rotation, see Section 13.1.4, "Log file rotation" . The default size is 2000 KB. rolloverInterval The frequency which the server rotates the active log file. The available choices are hourly, daily, weekly, monthly, and yearly. The default value is 2592000, which represents monthly in seconds. is monthly. For more information, see Section 13.1.4, "Log file rotation" . register [a] This variable is set to false by default and should remain so due to feature improvements. The self-test messages are only logged to the log file specified by selftests.container.logger.fileName . logSigning [b] Enables signed logging. When this parameter is enabled, provide a value for the signedAuditCertNickname parameter. This option means the log can only be viewed by an auditor. The value is either true or false . signedAuditCertNickname [c] The nickname of the certificate used to sign audit logs. The private key for this certificate must be accessible to the subsystem in order for it to sign the log. events [d] Specifies which events are logged to the audit log. Log events are separated by commas with no spaces. [a] register is for self-test logs only. [b] logSigning is for audit logs only. [c] signedAuditCertNickname is for audit logs only. [d] events is for audit logs only. Save the file. Start the subsystem instance. OR if using the Nuxwdog watchdog: 13.3.1. Enabling and configuring signed audit log 13.3.1.1. Enabling signed audit logging By default, audit logging is enabled upon installation. However, log signing needs to be enabled manually after installation. To display the current audit logging configuration, use the following command: pki-server subsystem-audit-config-show -i <instance_name> . For example, for a CA subsystem: To enable signed audit logging, use the pki-server utility to set the --logSigning option to true : Stop the instance: OR if using the Nuxwdog watchdog: Run the pki-server <subsystem> -audit-config-mod command, for example for a CA subsystem: Start the instance: OR if using the Nuxwdog watchdog: 13.3.1.2. Configuring audit events 13.3.1.2.1. Enabling and disabling audit events For details about enabling and disabling audit events, see 12.1.2.3 Configuring a Signed Audit Log in the Console in the Administration Guide (Common Criteria Edition) . In addition, audit event filters can be set to finer grained selection. See Section 13.3.1.2.2, "Filtering audit events" . For a complete list of auditable events in Certificate System, see Appendix E Audit events appendix in the Administration Guide (Common Criteria Edition) . 13.3.1.2.2. Filtering audit events In Certificate System administrators can set filters to configure which audit events will be logged in the audit file based on the event attributes. The format of the filters is the same as for LDAP filters. However, Certificate System only supports the following filters: Table 13.4. Supported audit event filters Type Format Example Presence ( attribute =*) (ReqID=*) Equality ( attribute = value ) (Outcome=Failure) Substring ( attribute = initial * any *... * any * final ) (SubjectID=*admin*) AND operation (&( filter_1 )( filter_2 )... ( filter_n )) (&(SubjectID=admin)(Outcome=Failure)) OR operation (|( filter_1 )( filter_2 )... ( filter_n )) (|(SubjectID=admin)(Outcome=Failure)) NOT operation (!( filter )) (!(SubjectID=admin)) For further details on LDAP filters, see the Using Compound Search Filters in the Red Hat Directory Server Administration Guide . Example 13.2. Filtering audit events To display the current settings for profile certificate requests: To display the current settings for processed certificate requests: To log only failed events for profile certificate requests and events for processed certificate requests that have the InfoName field set to rejectReason or cancelReason : Stop Certificate System: OR if using the Nuxwdog watchdog: Run the following command for profile certificate requests,: This results in the following entry in the CA's CS.cfg : Run the following command for processed certificate requests: This results in the following entry in the CA's CS.cfg : Start Certificate System: OR if using the Nuxwdog watchdog: 13.3.2. Configuring self-tests The self-tests feature and individual self-tests are registered and configured in the CS.cfg file. If a self-test is enabled, that self-test is listed for either on-demand or start up and is either empty or set as critical . Critical self-tests have a colon and the word critical after the name of the self-test. Otherwise, nothing is in this place. The server shuts down when a critical self-test fails during on demand self-tests; the server will not start when a critical self-test fails during start up. The implemented self-tests are automatically registered and configured when the instance was installed. The self-tests that are registered and configured are those associated with the subsystem type. A self-test's criticality is changed by changing the respective settings in the CS.cfg file. 13.3.2.1. Default self-tests at startup The following self-tests are enabled by default at startup. For the CA subsystem, the following self-tests are enabled by default at startup: CAPresence - used to verify the presence of the CA subsystem. CAValidity - used to determine that the CA subsystem is currently valid and has not expired. This involves checking the expiration of the CA certificate. SystemCertsVerification - used to determine that the system certificates are currently valid and have not expired or been revoked. For the CA subsystem, only validity tests for each certificate are done, leaving out certificate verification tests which could result in an OCSP request. This behavior can be overridden with the following config parameter: By default, this configuration parameter is considered false if not present at all. For the KRA subsystem, the following-self-tests are enabled: KRAPresence - used to verify the presence of the KRA subsystem. SystemCertsVerification - used to determine that the system certificates are currently valid and have not expired or been revoked. For the OCSP subsystem, the following self-tests are enabled: OCSPPresence - used to verify the presence of the OCSP subsystem. OCSPValidity - used to determine that the OCSP subsystem is currently valid and has not expired. This involves checking the expiration of the OCSP certificate. SystemCertsVerification - used to determine that the system certificates are currently valid and have not expired or been revoked. For the OCSP subsystem, only validity tests for each certificate are done, leaving out certificate verification tests which could result in an OCSP request. This behavior can be overridden with the following config parameter: By default, this configuration parameter is considered false if not present at all. For the TKS subsystem, the following-self-tests are enabled: SystemCertsVerification - used to determine that the system certificates are currently valid and have not expired or been revoked. For the TPS subsystem, the following-self-tests are enabled: TPSPresence - used to verify the presence of the TPS subsystem. TPSValidity - used to determine that the TPS subsystem is currently valid and has not expired. This involves checking the expiration of the TPS certificate. SystemCertsVerification - used to determine that the system certificates are currently valid and have not expired or been revoked. 13.3.2.2. Modifying self-test configuration By default, the self-test configuration is compliant. However, some settings can change the visibility of self-test logging or improve performance. To modify the configuration settings for self-tests: Stop the subsystem instance. Open the CS.cfg file located in the instance's conf/ directory. To edit the settings for the self-test log, edit the entries that begin with selftests.container.logger . Unless otherwise specified, these parameters do not affect compliance. These include the following parameters: bufferSize - Specify the buffer size in kilobytes (KB) for the log. The default size is 512 KB. Once the buffer reaches this size, the contents of the buffer are flushed out and copied to the log file. enable - Specify true to enable. Only enabled logs actually record events. This value must be enabled for compliance. fileName - Specify the full path, including the filename, to the file to write messages. The server must have read/write permission to the file. By default, the self-test log file is /selftests.log flushInterval - Specify the interval, in seconds, to flush the buffer to the file. The default interval is 5 seconds. The flushInterval is the amount of time before the contents of the buffer are flushed out and added to the log file. level - The default selection is 1; this log is not set up for any level beside 1. maxFileSize - Specify the file size in kilobytes (KB) for the error log. The default size is 2000 KB. The maxFileSize determines how large a log file can become before it is rotated. Once it reaches this size, the file is copied to a rotated file, and a new log file is started. register - This variable is set to false by default and should remain so due to feature improvements. The self-test messages are only logged to the log file specified by selftests.container.logger.fileName . rolloverInterval - Specify the frequency at which the server rotates the active error log file. The choices are hourly, daily, weekly, monthly, and yearly. The default value is 2592000 , which represents monthly in seconds. To edit the order in which the self-test are run, specify the order by listing any of the self-test as the value of the following parameters separated by a comma and a space. To mark a self-test critical, add a colon and the word critical to the name of the self-test in the list. To disable a self-test, remove it as the value of either the selftests.container.order.onDemand or selftests.container.order.startup parameters. Save the file. Start the subsystem. 13.3.3. Additional configuration for debug log 13.3.3.1. Enabling and disabling debug logging By default, debug logging is enabled in Certificate System. However, in certain situations, Administrators want to disable or re-enable this feature: Stop the Certificate System instance: OR if using the Nuxwdog watchdog: Edit the /CS.cfg file and set the debug.enabled parameter: To disable debug logging, set: Note Debug logs are not part of audit logging. Debug logs are helpful when trying to debug specific failures in Certificate System or a failing installation. By default, debug logs are enabled. If it is not desired, the administrator can safely disable debug logging to turn down verbosity. To enable debug logging, set: Start the Certificate System instance: OR if using the Nuxwdog watchdog: 13.3.3.2. Setting up rotation of debug log files Certificate System is not able to rotate debug logs. Debug logging is enabled by default and these logs grow until the file system is full. Use an external utility, such as logrotate , to rotate the logs. Example 13.3. Using logrotate to Rotate Debug Logs Create a configuration file, such as /etc/logrotate.d/rhcs_debug with the following content: To rotate debug logs for multiple subsystems in one configuration file, list the paths to the logs, each separated by white space, before the opening curly bracket. For example: For further details about logrotate and the parameters used in the example, see the logrotate(8) man page. 13.4. Audit retention Audit data are required to be retained in a way according to their retention categories: Extended Audit Retention: Audit data that is retained for necessary maintenance for a certificate's lifetime (from issuance to its expiration or revocation date). In Certificate System, they appear in the following areas: Signed audit logs: All events defined in Appendix E Audit events in the Administration Guide (Common Criteria Edition) . In the CA's internal LDAP server, certificate request records received by the CA and the certificate records as the requests are approved. Normal Audit Retention: Audit data that is typically retained only to support normal operation. This includes all events that do not fall under the extended audit retention category. Note Certificate System does not provide any interface to modify or delete audit data. 13.4.1. Location of audit data This section explains where Certificate System stores audit data and where to find the expiration date which plays a crucial role to determine the retention category. 13.4.1.1. Location of audit logs Certificate System stores audit logs in the /var/log/pki/instance_name/subsystem_type/signedAudit/ directory. For example, the audit logs of a CA are stored in the /var/log/pki/instance_name/ca/signedAudit/ directory. Normal users cannot access files in this directory. See 12.1.2 Managing Audit logs in the Administration Guide (Common Criteria Edition). For a list of audit log events that need to follow the extended audit retention period, see Appendix E Audit events in the Administration Guide (Common Criteria Edition) . Important Do not delete any audit logs that contain any events listed in the "Extended Audit Events" appendix. These audit logs will consume storage space potentially up to all space available in the disk partition. 13.4.1.2. Location of certificate requests and certificate records When certificate signing requests (CSR) are submitted, the CA stores the CSRs in the request repository provided by the CA's internal Directory Server. When these requests are approved, each certificate issued successfully, will result in an LDAP record being created in the certificate repository by the same internal Directory Server. The CA's internal Directory Server was specified in the following parameters when the CA was created using the pkispawn utility: pki_ds_hostname pki_ds_ldap_port pki_ds_database pki_ds_base_dn If a certificate request has been approved successfully, the validity of the certificate can be viewed by accessing the CA EE portal either by request ID or by serial number. To display the validity for a certificate request record: Log into the CA EE portal under https:// host_name :_port_/ca/ee/ca/ . Click Check Request Status . Enter the Request Identifier. Click Issued Certificate . Search for Validity . To display the validity from a certificate record: Log into the CA EE portal under https:// host_name :_port_/ca/ee/ca/ . Enter the serial number range. If you search for one specific record, enter the record's serial number in both the lowest and highest serial number field. Click on the search result. Search for Validity . Important Do not delete the request of the certificate records of the certificates that have not yet expired.

Commands:
sudo yum install audit
auditctl -l
-a always,exit -F arch=b32 -S unlink -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b32 -S rename -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b32 -S rmdir -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b32 -S unlinkat -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b32 -S renameat -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b64 -S unlink -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b64 -S rename -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b64 -S rmdir -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b64 -S unlinkat -F dir=/var/log/pki -F key=rhcs_audit_deletion -a always,exit -F arch=b64 -S renameat -F dir=/var/log/pki -F key=rhcs_audit_deletion
service auditd restart
-w /etc/pki/<instance name>/alias -p warx -k rhcs_audit_nssdb
-w /etc/pki/<instance name>/alias/<file> -p warx -k rhcs_audit_nssdb
-w /etc/pki/pki-ca121318ec/alias -p warx -k rhcs_audit_nssdb -w /etc/pki/pki-ca121318ec/alias/cert9.db -p warx -k rhcs_audit_nssdb -w /etc/pki/pki-ca121318ec/alias/key4.db -p warx -k rhcs_audit_nssdb -w /etc/pki/pki-ca121318ec/alias/NHSM-CONN-XCcert9.db -p warx -k rhcs_audit_nssdb -w /etc/pki/pki-ca121318ec/alias/NHSM-CONN-XCkey4.db -p warx -k rhcs_audit_nssdb -w /etc/pki/pki-ca121318ec/alias/pkcs11.txt -p warx -k rhcs_audit_nssdb
service auditd restart
-a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F key=rhcs_audit_time_change -a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=rhcs_audit_time_change -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=rhcs_audit_time_change -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=rhcs_audit_time_change -a always,exit -F arch=b32 -S clock_adjtime -F key=rhcs_audit_time_change -a always,exit -F arch=b64 -S clock_adjtime -F key=rhcs_audit_time_change -w /etc/localtime -p wa -k rhcs_audit_time_change
service auditd restart
-w /etc/pki/instance_name/server.xml -p wax -k rhcs_audit_config
-w /etc/pki/instance_name/subsystem/CS.cfg -p wax -k rhcs_audit_config
-w /etc/pki/pki-ca121318ec/server.xml -p wax -k rhcs_audit_config -w /etc/pki/pki-ca121318ec/ca/CS.cfg -p wax -k rhcs_audit_config
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
systemctl start pki-tomcatd@instance_name.service
systemctl start pki-tomcatd-nuxwdog@instance_name.service
pki-server ca -audit-config-show -i rhcs10-RSA-SubCA Enabled: True Log File: var/lib/pki/rhcs10-RSA-SubCA/logs/ca/signedAudit/ca_audit Buffer Size (bytes): 512 Flush Interval (seconds): 5 Max File Size (bytes): 2000 Rollover Interval (seconds): 2592000 Expiration Time (seconds): 0 Log Signing: False Signing Certificate: NHSM-CONN-XC:auditSigningCert cert-rhcs10-RSA-SubCA CA
pki-server subsystem -audit-config-mod --logSigning True -i instance_name
systemctl stop pki-tomcatd@ instance_name .service
systemctl stop pki-tomcatd-nuxwdog@ instance_name .service
pki-server ca -audit-config-mod --logSigning True -i rhcs10-RSA-SubCA Log Signing: True
systemctl start pki-tomcatd@ instance_name .service
systemctl start pki-tomcatd-nuxwdog@ instance_name .service
pki-server ca-audit-event-show PROFILE_CERT_REQUEST -i <instance_name> Event Name: PROFILE_CERT_REQUEST Enabled: True Filter: None
*pki-server ca-audit-event-show CERT_REQUEST_PROCESSED -i <instance_name>* Event Name: CERT_REQUEST_PROCESSED Enabled: True Filter: None
systemctl stop pki-tomcatd@instance_name.service
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
pki-server ca-audit-event-update PROFILE_CERT_REQUEST --filter "(Outcome=Failure)" i <instance_name> Filter: (Outcome=Failure)
log.instance.SignedAudit.filters.PROFILE_CERT_REQUEST=(Outcome=Failure)
pki-server ca-audit-event-update CERT_REQUEST_PROCESSED --filter "(|(InfoName=rejectReason)(InfoName=cancelReason))" i <instance_name> Filter: (|(InfoName=rejectReason)(InfoName=cancelReason))
log.instance.SignedAudit.filters.CERT_REQUEST_PROCESSED=(|(InfoName=rejectReason)(InfoName=cancelReason))
systemctl start pki-tomcatd@instance_name.service
systemctl start pki-tomcatd-nuxwdog@instance_name.service
selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
systemctl stop pki-tomcatd@instance-name.service
systemctl stop pki-tomcatd-nuxwdog@instance-name.service
debug.enabled=false
debug.enabled=true
systemctl start pki-tomcatd@instance-name.service
systemctl start pki-tomcatd-nuxwdog@instance-name.service
/var/log/pki/instance_name/subsystem/debug { copytruncate weekly rotate 5 notifempty missingok }
/var/log/pki/instance_name/ca/debug /var/log/pki/instance_name/kra/debug { }