Provided by: pki-tools_10.6.0-1ubuntu2_amd64 bug


       AuditVerify - Command-Line utility for verifying Certificate System signed audit logs.


       AuditVerify -d <dbdir> -n <signing_certificate_nickname> -a <logListFile> [-P cert/key_db_prefix] [-v]


       The  AuditVerify  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 (compromised).

       Note: An auditor can be any user that has the privilege to peruse the pki audit logs.


       -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 example:


       [-v]   Optional. Specifies verbose output.

Setting up the Auditor's Database

       AuditVerify 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:

   Create a special directory in the auditor's home directory to use to perform the verification.
       For example:
       mkdir ~jsmith/auditVerifyDir

   Use the certutil tool to create an empty set of certificate databases in  the  auditor's  home
       certutil -d ~jsmith/auditVerifyDir -N

   Download  the  CA  certificate  from the CA's Retrieval page. The certificates can be obtained
       from the CA in ASCII format.

   Import the CA certificate and log signing certificate into the databases and set trust of  the
       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

       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:

   Create a text file containing a comma-separated list of the log files to be verified. The name
       of this file is referenced in the AuditVerify command.
       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."

   If the audit databases do not contain prefixes and are located in  the  user  home  directory,
       such  as ~jsmith/.mozilla, and the signing certificate nickname is Log Signing Certificate
       , the AuditVerify command is run as follows:
       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 <>.


       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