Chapter 12. Configuring subsystem logs

For a list of audit events in Certificate System, see Appendix E, Audit events.

By default, audit logging is enabled upon installation. However, you need to enable log signing manually after installation. Please see "Enabling signed audit logging" in the Installation Guide.

Signed audit logs are configured by default when the instance is first created, but it is possible to edit the configuration or change the signing certificates after configuration.

A log is set to a signed audit log by setting the logSigning parameter to enable and providing the nickname of the certificate used to sign the log. A special log signing certificate is created when the subsystems are first configured.

Only a user with auditor privileges can access and view a signed audit log. Auditors can use the AuditVerify tool to verify that signed audit logs have not been tampered with.

The signed audit log is created and enabled when the subsystem is configured, but it needs additional configuration to begin creating and signing audit logs.

After enabling signed audit logging, assign auditor users by creating the user and assigning that entry to the auditor group. Members of the auditor group are the only users who can view and verify the signed audit log. See Section 11.3.2.1, “Creating role users” for details about setting up auditors.

Auditors can verify logs by using the AuditVerify tool. See the AuditVerify(1) man page for details about using this tool.

There are events that could cause the audit logging function to fail, so events cannot be written to the log. For example, audit logging can fail when the file system containing the audit log file is full or when the file permissions for the log file are accidentally changed. If audit logging fails, the Certificate System instance shuts down in the following manner.

When this happens, administrators and auditors should work together with the operating system administrator to resolve the disk space or file permission issues. When the IT problem is resolved, the auditor should make sure that the last audit log entries are signed. If not, they should be preserved by manual signing, archived, and removed to prevent audit verification failures in the future. When this is completed, the administrators can restart the Certificate System.

As a user with auditor privileges, use the pki subsystem-audit-file-find command to list existing audit log files on the server.

For example, to list the audit log files on the CA hosted on server.example.com:8443:

# pki -h server.example.com -p 8443 -n auditor ca-audit-file-find
-----------------
3 entries matched
-----------------
	File name: ca_audit.20170331225716
	Size: 2883

	File name: ca_audit.20170401001030
	Size: 189

	File name: ca_audit
	Size: 6705
----------------------------
Number of entries returned 3
----------------------------

The command uses the client certificate with the auditor nickname stored in the ~/.dogtag/nssdb/ directory for authenticating to the CA. For further details about the parameters used in the command and alternative authentication methods, see the pki(1) man page.

As a user with auditor privileges, use the pki subsystem-audit-file-retrieve command to download a specific audit log from the server.

For example, to download an audit log file from the CA hosted on server.example.com:

After downloading a log file, you can search for specific log entries, for example, using the grep utility:

# grep "\[AuditEvent=ACCESS_SESSION_ESTABLISH\]" log_file

If audit log signing is enabled, users with auditor privileges can verify the logs:

Since these events are keyed (with rhcs_audit_deletion), use the -k parameter to find events matching that key:

# ausearch -k rhcs_audit_deletion

Since these events are keyed (with rhcs_audit_nssdb), use the -k parameter to find events matching that key:

# ausearch -k rhcs_audit_nssdb

Since these events are keyed (with rhcs_audit_time_change), use the -k parameter to find events matching that key:

# ausearch -k rhcs_audit_time_change

Since these events are a typed message (of type SOFTWARE_UPDATE), use the -m parameter to find events matching that type:

# ausearch -m SOFTWARE_UPDATE

Since these events are keyed (with rhcs_audit_config), use the -k parameter to find events matching that key:

# ausearch -k rhcs_audit_config