Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

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
Copiar o link

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
Copiar o link

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”

Expand
Table 13.1. Services logged
ServiceDescription

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)
Copiar o link

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.

Expand
Table 13.2. Log levels and corresponding log messages
Log levelMessage categoryDescription

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
Copiar o link

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
Copiar o link

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
Copiar o link

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
Copiar o link

13.2.1. Enabling OS-level audit logs
Copiar o link

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: 

# sudo yum install audit
Copy to Clipboard Toggle word wrap

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: 

# auditctl -l
Copy to Clipboard Toggle word wrap

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
Copiar o link

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: 

-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
Copy to Clipboard Toggle word wrap

Then restart auditd: 

# service auditd restart
Copy to Clipboard Toggle word wrap

13.2.1.2. Auditing unauthorized Certificate System use of secret keys
Copiar o link

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: 

-w /etc/pki/<instance name>/alias -p warx -k rhcs_audit_nssdb
Copy to Clipboard Toggle word wrap

<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 : 

-w /etc/pki/<instance name>/alias/<file> -p warx -k rhcs_audit_nssdb
Copy to Clipboard Toggle word wrap

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: 

-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
Copy to Clipboard Toggle word wrap

Then restart auditd: 

# service auditd restart
Copy to Clipboard Toggle word wrap

13.2.1.3. Auditing time change events
Copiar o link

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: 

-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
Copy to Clipboard Toggle word wrap

Then restart auditd: 

# service auditd restart
Copy to Clipboard Toggle word wrap

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
Copiar o link

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: 

-w /etc/pki/instance_name/server.xml -p wax -k rhcs_audit_config
Copy to Clipboard Toggle word wrap

Additionally, add for each subsystem in the /etc/pki/instance_name/ directory the following contents: 

-w /etc/pki/instance_name/subsystem/CS.cfg -p wax -k rhcs_audit_config
Copy to Clipboard Toggle word wrap

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: 

-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
Copy to Clipboard Toggle word wrap

Note that access to the PKI NSS database is already audited under rhcs_audit_nssdb.

13.3. Configuring Logs in the CS.cfg File
Copiar o link

During the installation configuration, you can configure the logging by directly editing the CS.cfg for the instance.

  1. Stop the subsystem instance. 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  2. Open the CS.cfg file in the /var/lib/pki/<instance_name>/<subsystem_type>/conf directory.
  3. Create a new log.

  4. To configure a log instance, modify the parameters associated with that log. These parameters begin with log.instance.

    Expand
    Table 13.3. Log entry parameters
    ParameterDescription

    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.
  5. Save the file.

  6. Start the subsystem instance. 

    # systemctl start pki-tomcatd@instance_name.service
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

13.3.1. Enabling and configuring signed audit log
Copiar o link

13.3.1.1. Enabling signed audit logging
Copiar o link

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: 

    # 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
    Copy to Clipboard Toggle word wrap

  • To enable signed audit logging, use the pki-server utility to set the --logSigning option to true: 

    # pki-server subsystem-audit-config-mod --logSigning True -i instance_name
    Copy to Clipboard Toggle word wrap

    1. Stop the instance: 

      # systemctl stop pki-tomcatd@instance_name.service
      Copy to Clipboard Toggle word wrap

      OR if using the Nuxwdog watchdog: 

      # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
      Copy to Clipboard Toggle word wrap

    2. Run the pki-server <subsystem>-audit-config-mod command, for example for a CA subsystem: 

      # pki-server ca-audit-config-mod --logSigning True -i rhcs10-RSA-SubCA
  ...
  Log Signing: True
  ...
      Copy to Clipboard Toggle word wrap

    3. Start the instance: 

      # systemctl start pki-tomcatd@instance_name.service
      Copy to Clipboard Toggle word wrap

      OR if using the Nuxwdog watchdog: 

      # systemctl start pki-tomcatd-nuxwdog@instance_name.service
      Copy to Clipboard Toggle word wrap

13.3.1.2. Configuring audit events
Copiar o link

13.3.1.2.1. Enabling and disabling audit events
Copiar o link

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
Copiar o link

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:

Expand
Table 13.4. Supported audit event filters
TypeFormatExample

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: 

    $ pki-server ca-audit-event-show PROFILE_CERT_REQUEST -i <instance_name>

  Event Name: PROFILE_CERT_REQUEST
  Enabled: True
  Filter: None
    Copy to Clipboard Toggle word wrap

  • To display the current settings for processed certificate requests: 

    $ *pki-server ca-audit-event-show CERT_REQUEST_PROCESSED -i <instance_name>*

  Event Name: CERT_REQUEST_PROCESSED
  Enabled: True
  Filter: None
    Copy to Clipboard Toggle word wrap

  • 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:

    1. Stop Certificate System: 

      # systemctl stop pki-tomcatd@instance_name.service
      Copy to Clipboard Toggle word wrap

      OR if using the Nuxwdog watchdog: 

      # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
      Copy to Clipboard Toggle word wrap

    2. Run the following command for profile certificate requests,: 

      $ pki-server ca-audit-event-update PROFILE_CERT_REQUEST --filter "(Outcome=Failure)" i <instance_name>
  ...
  Filter: (Outcome=Failure)
      Copy to Clipboard Toggle word wrap

      This results in the following entry in the CA’s CS.cfg: 

      log.instance.SignedAudit.filters.PROFILE_CERT_REQUEST=(Outcome=Failure)
      Copy to Clipboard Toggle word wrap

    3. Run the following command for processed certificate requests: 

      $ pki-server ca-audit-event-update CERT_REQUEST_PROCESSED --filter "(|(InfoName=rejectReason)(InfoName=cancelReason))" i <instance_name>
  ...
  Filter: (|(InfoName=rejectReason)(InfoName=cancelReason))
      Copy to Clipboard Toggle word wrap

      This results in the following entry in the CA’s CS.cfg: 

      log.instance.SignedAudit.filters.CERT_REQUEST_PROCESSED=(|(InfoName=rejectReason)(InfoName=cancelReason))
      Copy to Clipboard Toggle word wrap

    4. Start Certificate System: 

      # systemctl start pki-tomcatd@instance_name.service
      Copy to Clipboard Toggle word wrap

      OR if using the Nuxwdog watchdog: 

      # systemctl start pki-tomcatd-nuxwdog@instance_name.service
      Copy to Clipboard Toggle word wrap

13.3.2. Configuring self-tests
Copiar o link

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
Copiar o link

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: 

    selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
    Copy to Clipboard Toggle word wrap

    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: 

    selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
    Copy to Clipboard Toggle word wrap

    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
Copiar o link

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:

  1. Stop the subsystem instance.
  2. Open the CS.cfg file located in the instance’s conf/ directory.

  3. 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.

  4. 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.

  5. Save the file.
  6. Start the subsystem.

13.3.3. Additional configuration for debug log
Copiar o link

13.3.3.1. Enabling and disabling debug logging
Copiar o link

By default, debug logging is enabled in Certificate System. However, in certain situations, Administrators want to disable or re-enable this feature:

  1. Stop the Certificate System instance: 

    # systemctl stop pki-tomcatd@instance-name.service
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@instance-name.service
    Copy to Clipboard Toggle word wrap

  2. Edit the /CS.cfg file and set the debug.enabled parameter:

    • To disable debug logging, set: 

      debug.enabled=false
      Copy to Clipboard Toggle word wrap
      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: 

      debug.enabled=true
      Copy to Clipboard Toggle word wrap

  3. Start the Certificate System instance: 

    # systemctl start pki-tomcatd@instance-name.service
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@instance-name.service
    Copy to Clipboard Toggle word wrap

13.3.3.2. Setting up rotation of debug log files
Copiar o link

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: 

/var/log/pki/instance_name/subsystem/debug {
     copytruncate
     weekly
     rotate 5
     notifempty
     missingok
}
Copy to Clipboard Toggle word wrap

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: 

/var/log/pki/instance_name/ca/debug /var/log/pki/instance_name/kra/debug {
     ...
}
Copy to Clipboard Toggle word wrap

For further details about logrotate and the parameters used in the example, see the logrotate(8) man page.

13.4. Audit retention
Copiar o link

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
Copiar o link

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
Copiar o link

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
Copiar o link

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:

  1. Log into the CA EE portal under https://host_name:_port_/ca/ee/ca/.
  2. Click Check Request Status.
  3. Enter the Request Identifier.
  4. Click Issued Certificate.
  5. Search for Validity.

To display the validity from a certificate record:

  1. Log into the CA EE portal under https://host_name:_port_/ca/ee/ca/.
  2. 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.
  3. Click on the search result.
  4. Search for Validity.
Important

Do not delete the request of the certificate records of the certificates that have not yet expired.

Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat