Este contenido no está disponible en el idioma seleccionado.
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:
- Log into the Console.
- Select the Status tab.
- Under Logs, select the log to view.
- 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.
- Click .
- To view a full entry, double-click it, or select the entry, and click .
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:
- Optionally, list the available log files on the CA. See Section 16.3.2.1, “Listing Audit Logs”.
- Download the log file. For example, to download the
ca_auditfile:# 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:
- 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.
- If the audit signing certificate does not exist in the PKI client database, import it:
- 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 ----------------------------
- 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" ---------------------------------------------------
- Download the audit logs. See Section 16.3.2.2, “Downloading Audit Logs”.
- Verify the audit logs.
- 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
- Use the
AuditVerifyutility 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 usingAuditVerify, 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.
| 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 |
