AuditVerify - Command-Line utility for verifying Certificate System signed audit
AuditVerify -d <dbdir> -n <signing_certificate_nickname> -a <logListFile> [-P cert/key_db_prefix] [-v]
command provides command-line utility to verify that
signed audit logs were signed with the appropriate CS audit private signing
key and that the audit logs have not been compromised. Auditors can verify the
authenticity and integrity of signed audit logs using the AuditVerify
tool. This tool uses the public key of the signed audit log signing
certificate to verify the digital signatures embedded in a signed audit log
file. The tool result indicates either that the signed audit log was
successfully verified or that the signed audit log was not successfully
verified. An unsuccessful verification warns the auditor that the signature
failed to verify, indicating the log file may have been tampered with
Note: An auditor can be any user that has the privilege to peruse the pki
- -d <dbdir>
- Specifies the directory containing the security databases
with the imported audit log signing certificate. This directory is almost
always the auditor's own personal certificate databases in a personal
directory, such as ~jsmith/auditVerifyDir/.
- -n <signing_certificate_nickname>
- Gives the nickname of the certificate used to sign the log
files. The nickname is whatever was used when the log signing certificate
was imported into that database.
- [-P cert/key_db_prefix]
- Optional. The prefix to prepend to the certificate and key
database filenames. If used, a value of empty quotation marks
(“”) should be specified for this argument, since the
auditor is using separate certificate and key databases from the
Certificate System instance and it is unlikely that the prefix should be
prepended to the new audit security database files.
- -a <logListFile>
- Specifies the file which contains the comma-separate list
of file paths (in chronological order) of the signed audit logs to be
verified. This file should be created in a directory which is writeable by
the auditor, such as a special auditing directory like ~jsmith/auditDir.
The contents of the logListFile are the full paths to the audit logs. For
- Optional. Specifies verbose output.
needs access to a set of security databases (usually the
auditor's personal security databases) containing the signed audit log signing
certificate and its chain of issuing certificates. One of the CA certificates
in the issuance chain must be marked as trusted in the database.
Auditors should import the audit signing certificate into their personal
certificate database before running AuditVerify
. The auditor should not
use the security databases of the Certificate System instance that generated
the signed audit log files. If there are no readily accessible certificate and
key database, the auditor must create a set of certificate and key databases
and import the signed audit log signing certificate chain.
To create the security databases and import the certificate chain:
certutil -d ~jsmith/auditVerifyDir -N
If the CA certificate is in a file called cacert.txt and the log signing
certificate is in a file called logsigncert.txt, then the certutil can be used
to set the trust for the new audit security database directory pointing to
those files, as follows:
certutil -d ~jsmith/auditVerifyDir/ -A -n "CA Certificate" -t
"CT,CT,CT" -a -i cacert.txt
certutil -d ~jsmith/auditVerifyDir -A -n "Log Signing Certificate" -t
",,P" -a -i logsigncert.txt
Note: The signedAudit directory kept by the subsystem is not writeable by any
user, including auditors.
After a separate audit database directory has been configured, do the following:
For example, this file could be logListFile in the ~jsmith/auditVerifyDir/
directory. The contents are the comma-separated list of audit logs to be
verified, such as "auditlog.1213, auditlog.1214, auditlog.1215."
AuditVerify -d ~jsmith/auditVerifyDir -n Log Signing Certificate -a
~jsmith/auditVerifyDir/logListFile -P "" -v
Note: It has been observed that if audit signing is enabled after system is
first started, the first audit signature would not be verified. What happens
is that the signature starts calculating from it's in-memory audit log message
when it signs, and since log signing is turned on mid-way (not from a fresh
new log file), the previous content were not signed along for calculating the
first signature (and rightfully so). When AuditVerify is run, it does not know
where the log signing begins, so it assumes it starts from the beginning of
the file till the first signature. This is why the first signature (if signing
is turned on mid-way) will always appear to be incorrect.
Christina Fu <firstname.lastname@example.org>.
Copyright (c) 2016 Red Hat, Inc. This is licensed under the GNU General Public
License, version 2 (GPLv2). A copy of this license is available at