16.3. Using Logs


16.3.1. Viewing Logs in the Console

To troubleshoot the subsystem, check the error or informational messages that the server has logged. Examining the log files can also monitor many aspects of the server's operation. Some log files can be viewed through the Console. However, the audit log is only accessible by users with the Auditor role, using a method detailed in Section 16.3.2, “Using Signed Audit Logs”.
To view the contents of a log file:
  1. Log into the Console.
  2. Select the Status tab.
  3. Under Logs, select the log to view.
  4. Set the viewing preferences in the Display Options section.
    • Entries — The maximum number of entries to be displayed. When this limit is reached, the Certificate System returns any entries that match the search request. Zero (0) means no messages are returned. If the field is blank, the server returns every matching entry, regardless of the number found.
    • Source — Select the Certificate System component or service for which log messages are to be displayed. Choosing All means messages logged by all components that log to this file are displayed.
    • Level — Select a message category that represents the log level for filtering messages.
    • Filename — Select the log file to view.
  5. Click Refresh.
  6. To view a full entry, double-click it, or select the entry, and click View.

16.3.2. Using Signed Audit Logs

This section explains how a user in the Auditor group displays and verifies signed audit logs.

16.3.2.1. Listing Audit Logs

As a user with auditor privileges, use the 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:
# 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.

16.3.2.2. Downloading Audit Logs

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:
  1. Optionally, list the available log files on the CA. See Section 16.3.2.1, “Listing Audit Logs”.
  2. Download the log file. For example, to download the ca_audit file:
    # pki -U https://server.example.com:8443 -n auditor ca-audit-file-retrieve ca_audit
    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.
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

16.3.2.3. Verifying Signed Audit Logs

If audit log signing is enabled, users with auditor privileges can verify the logs:
  1. Initialize the NSS database and import the CA certificate. For details, see Section 2.5.1.1, “pki CLI Initialization” and the Importing a certificate into an NSS Database section in the Red Hat Certificate System Planning, Installation, and Deployment Guide.
  2. If the audit signing certificate does not exist in the PKI client database, import it:
    1. Search the audit signing certificate for the subsystem logs you want to verify. For example:
      # pki ca-cert-find --name "CA Audit Signing Certificate"
      ---------------
      1 entries found
      ---------------
      	Serial Number: 0x5
      	Subject DN: CN=CA Audit Signing Certificate,O=EXAMPLE
      	Status: VALID
      	Type: X.509 version 3
      	Key Algorithm: PKCS #1 RSA with 2048-bit key
      	Not Valid Before: Fri Jul 08 03:56:08 CEST 2016
      	Not Valid After: Thu Jun 28 03:56:08 CEST 2018
      	Issued On: Fri Jul 08 03:56:08 CEST 2016
      	Issued By: system
      ----------------------------
      Number of entries returned 1
      ----------------------------
      
    2. Import the audit signing certificate into the PKI client:
      # pki client-cert-import "CA Audit Signing Certificate" --serial 0x5 --trust ",,P"
      ---------------------------------------------------
      Imported certificate "CA Audit Signing Certificate"
      ---------------------------------------------------
  3. Download the audit logs. See Section 16.3.2.2, “Downloading Audit Logs”.
  4. Verify the audit logs.
    1. Create a text file that contains a list of the audit log files you want to verify in chronological order. For example:
      # cat > ~/audit.txt << EOF
      ca_audit.20170331225716
      ca_audit.20170401001030
      ca_audit
      EOF
    2. Use the AuditVerify utility to verify the signatures. For example:
      # AuditVerify -d ~/.dogtag/nssdb/ -n "CA Audit Signing Certificate" \
      		 -a ~/audit.txt
      Verification process complete.
      Valid signatures: 10
      Invalid signatures: 0
      For further details about using AuditVerify, see the AuditVerify(1) man page.

16.3.3. Displaying Operating System-level Audit Logs

Note

To see Operating System-level audit logs using the instructions below, the auditd logging framework must be configured per the Enabling OS-level Audit Logs section in the Red Hat Certificate System Planning, Installation, and Deployment Guide.
To display operating system-level access logs, use the ausearch utility as root or as a privileged user with the sudo utility.

16.3.3.1. Displaying Audit Log Deletion Events

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

16.3.3.2. Displaying Access to the NSS Database for Secret and Private Keys

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

16.3.3.3. Displaying Time Change Events

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

16.3.3.4. Displaying Package Update Events

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

16.3.3.5. Displaying Changes to the PKI Configuration

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

16.3.4. Smart Card Error Codes

Smart cards can report certain error codes to the TPS; these are recorded in the TPS's debug log file, depending on the cause for the message.
Table 16.5. Smart Card Error Codes
Return Code Description
General Error Codes  
6400 No specific diagnosis
6700 Wrong length in Lc
6982 Security status not satisfied
6985 Conditions of use not satisfied
6a86 Incorrect P1 P2
6d00 Invalid instruction
6e00 Invalid class
Install Load Errors  
6581 Memory Failure
6a80 Incorrect parameters in data field
6a84 Not enough memory space
6a88 Referenced data not found
Delete Errors  
6200 Application has been logically deleted
6581 Memory failure
6985 Referenced data cannot be deleted
6a88 Referenced data not found
6a82 Application not found
6a80 Incorrect values in command data
Get Data Errors  
6a88 Referenced data not found
Get Status Errors  
6310 More data available
6a88 Referenced data not found
6a80 Incorrect values in command data
Load Errors  
6581 Memory failure
6a84 Not enough memory space
6a86 Incorrect P1/P2
6985 Conditions of use not satisfied
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.