1AuditVerify(1) PKI Signed Audit Log Verification Command AuditVerify(1)
2
6 AuditVerify - Command-Line utility for verifying Certificate System
7 signed audit logs.
8
11 AuditVerify -d <dbdir> -n <signing_certificate_nickname> -a <logListFile> [-P cert/key_db_prefix] [-v]
12
15 The AuditVerify command provides command-line utility to verify that
16 signed audit logs were signed with the appropriate CS audit private
17 signing key and that the audit logs have not been compromised. Audi‐
18 tors can verify the authenticity and integrity of signed audit logs
19 using the AuditVerify tool. This tool uses the public key of the signed
20 audit log signing certificate to verify the digital signatures embedded
21 in a signed audit log file. The tool result indicates either that the
22 signed audit log was successfully verified or that the signed audit log
23 was not successfully verified. An unsuccessful verification warns the
24 auditor that the signature failed to verify, indicating the log file
25 may have been tampered with (compromised).
26 Note: An auditor can be any user that has the privilege to peruse the
28 pki audit logs.
29
32 -d <dbdir>
33 Specifies the directory containing the security databases with
34 the imported audit log signing certificate. This directory is
35 almost always the auditor's own personal certificate databases
36 in a personal directory, such as ~jsmith/auditVerifyDir/.
37 -n <signing_certificate_nickname>
40 Gives the nickname of the certificate used to sign the log
41 files. The nickname is whatever was used when the log signing
42 certificate was imported into that database.
43 [-P cert/key_db_prefix]
46 Optional. The prefix to prepend to the certificate and key data‐
47 base filenames. If used, a value of empty quotation marks (“”)
48 should be specified for this argument, since the auditor is
49 using separate certificate and key databases from the Certifi‐
50 cate System instance and it is unlikely that the prefix should
51 be prepended to the new audit security database files.
52 -a <logListFile>
55 Specifies the file which contains the comma-separate list of
56 file paths (in chronological order) of the signed audit logs to
57 be verified. This file should be created in a directory which
58 is writeable by the auditor, such as a special auditing direc‐
59 tory like ~jsmith/auditDir. The contents of the logListFile are
60 the full paths to the audit logs. For example:
61 /var/log/pki/pki-ca/ca/signedAudit/ca_audit,/var/log/pki/pki-ca/ca/signedAudit/ca_audit.20030227102711,/var/log/pki/pki-ca/ca/signedAudit/ca_audit.20030226094015
63 [-v] Optional. Specifies verbose output.
66
69 AuditVerify needs access to a set of security databases (usually the
70 auditor's personal security databases) containing the signed audit log
71 signing certificate and its chain of issuing certificates. One of the
72 CA certificates in the issuance chain must be marked as trusted in the
73 database.
74 Auditors should import the audit signing certificate into their per‐
76 sonal certificate database before running AuditVerify. The auditor
77 should not use the security databases of the Certificate System
78 instance that generated the signed audit log files. If there are no
79 readily accessible certificate and key database, the auditor must cre‐
80 ate a set of certificate and key databases and import the signed audit
81 log signing certificate chain.
82 To create the security databases and import the certificate chain:
84 Create a special directory in the auditor's home directory to use to per‐
87 form the verification. For example:
88 mkdir ~jsmith/auditVerifyDir
89 Use the certutil tool to create an empty set of certificate databases in
92 the auditor's home directory.
93 certutil -d ~jsmith/auditVerifyDir -N
94 Download the CA certificate from the CA's Retrieval page. The certificates
97 can be obtained from the CA in ASCII format.
98 https://server.example.com:ca_https_port/ca/ee/ca/
99 Import the CA certificate and log signing certificate into the databases
102 and set trust of the certificates
103 If the CA certificate is in a file called cacert.txt and the log sign‐
104 ing certificate is in a file called logsigncert.txt, then the certutil
105 can be used to set the trust for the new audit security database direc‐
106 tory pointing to those files, as follows:
107 certutil -d ~jsmith/auditVerifyDir/ -A -n "CA Certificate" -t
109 "CT,CT,CT" -a -i cacert.txt
110 certutil -d ~jsmith/auditVerifyDir -A -n "Log Signing Certificate" -t
112 ",,P" -a -i logsigncert.txt
113 Note: The signedAudit directory kept by the subsystem is not writeable
115 by any user, including auditors.
116
119 After a separate audit database directory has been configured, do the
120 following:
121 Create a text file containing a comma-separated list of the log files to be
123 verified. The name of this file is referenced in the AuditVerify com‐
124 mand.
125 For example, this file could be logListFile in the ~jsmith/auditVerify‐
126 Dir/ directory. The contents are the comma-separated list of audit logs
127 to be verified, such as "auditlog.1213, auditlog.1214, auditlog.1215."
128 If the audit databases do not contain prefixes and are located in the user
131 home directory, such as ~jsmith/.mozilla, and the signing certificate
132 nickname is Log Signing Certificate , the AuditVerify command is run as
133 follows:
134 AuditVerify -d ~jsmith/auditVerifyDir -n Log Signing Certificate -a
135 ~jsmith/auditVerifyDir/logListFile -P "" -v
136 Note: It has been observed that if audit signing is enabled after sys‐
138 tem is first started, the first audit signature would not be verified.
139 What happens is that the signature starts calculating from it's in-mem‐
140 ory audit log message when it signs, and since log signing is turned on
141 mid-way (not from a fresh new log file), the previous content were not
142 signed along for calculating the first signature (and rightfully so).
143 When AuditVerify is run, it does not know where the log signing begins,
144 so it assumes it starts from the beginning of the file till the first
145 signature. This is why the first signature (if signing is turned on
146 mid-way) will always appear to be incorrect.
147
151 Christina Fu <cfu@redhat.com>.
152
155 Copyright (c) 2016 Red Hat, Inc. This is licensed under the GNU General
156 Public License, version 2 (GPLv2). A copy of this license is available
157 at http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.
158
161 pki(1)
162version 10.3 July 7, 2016 AuditVerify(1)