AuditVerify(1)

📦
version 11.2.0 · 5 versions
, in centos-stream 9

💅 AuditVerify(1) — the PKI Signed Audit Log Verification Command, bestie edition 🎀

okay so picture this: it's giving manual page, section 1 of the PKI docs, and it's literally the whole vibe of "prove nobody messed with your audit logs." Buckle up, we're doing this together 🫶

✨ NAME ✨

AuditVerify — a command-line utility for verifying Certificate System signed audit logs. that's it, that's the whole job, and she ate 💅

🌸 SYNOPSIS 🌸

AuditVerify -d dbdir -n signing-cert-nickname -a logListFile [-P
db-prefix] [-v]

lowkey that's your whole incantation right there. -d, -n, -a are the main characters, -P and -v are the optional besties ✨

🦋 DESCRIPTION 🦋

So AuditVerify is a command-line utility that verifies that signed audit logs were signed with the appropriate PKI audit private signing key — and that the audit logs have not been compromised. no cap, that's the whole point 🔥

Auditors can verify the authenticity and integrity of signed audit logs using the AuditVerify tool. The way it works is genuinely so smart: 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. iconic behavior honestly 👑

The tool result indicates either that the signed audit log was successfully verified or that the signed audit log was not successfully verified. And an unsuccessful verification warns the auditor that the signature failed to verify, indicating the log file may have been tampered with (compromised). 😭 so like, if she says no, that's a big deal.

Note: an auditor can be any user that has the privilege to peruse the PKI audit logs. like, that's the whole qualification. iykyk 💜

✨ OPTIONS ✨

  • -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 $HOME/.dogtag/nssdb. 🍓
  • -n signing-cert-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. fr fr, it's just the name you gave her when you brought her home 💖
  • -P 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 PKI server and it is unlikely that the prefix should be prepended to the new audit security database files. 💀 yes, you read that right — the move is literally to pass an empty string here.
  • -a logListFile — Specifies the file which contains the list of file paths (in chronological order) of the signed audit logs to be verified. The contents of the logListFile are the full paths to the audit logs. order matters, bestie, chronological only 📋
  • -v — Optional. Specifies verbose output. she talks more. we love a chatty queen 🌈

👑 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. can't skip that part, the trust has to be there ⭐

Auditors should import the audit signing certificate into their personal certificate database before running AuditVerify. And listen — the auditor should not use the security databases of the PKI server instance that generated the signed audit log files. right? like, separate vibes, separate databases, that's the whole point 🙈 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 -p $HOME/.dogtag/nssdb

Use the certutil tool to create an empty set of certificate databases in the auditor's home directory.

$ certutil -N -d $HOME/.dogtag/nssdb

Download the CA certificate from the CA's Retrieval page at https://pki.example.com:8443/ca/ee/ca. The certificates can be obtained from the CA in ASCII format. 📥

Then import the CA certificate and log signing certificate into the databases and set trust of the certificates. If the CA certificate is in a file called cacert.pem and the log signing certificate is in a file called logsigncert.pem, then the certutil can be used to set the trust for the new audit security database directory pointing to those files, as follows:

$ certutil -A -d $HOME/.dogtag/nssdb -n "CA Certificate" -t "CT,CT,CT" -a -i cacert.pem
$ certutil -A -d $HOME/.dogtag/nssdb -n "Log Signing Certificate" -t ",,P" -a -i logsigncert.pem
Note: the signedAudit directory kept by the subsystem is not writeable by any user, including auditors. not even you. not even the auditor. not even with your cutest please 🥺 it's locked locked.

💜 Operation 💜

After a separate audit database directory has been configured, create a text file containing a 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.txt:

/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit.20030227102711
/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit.20030226094015
/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit

Assuming the audit databases do not contain prefixes and are located in the user home directory, such as $HOME/.dogtag/nssdb, and the signing certificate nickname is "Log Signing Certificate", the AuditVerify command is run as follows:

$ AuditVerify -d $HOME/.dogtag/nssdb -n "Log Signing Certificate" -a logListFile.txt -P "" -v

that's the whole run. she's gorgeous. look at her go 🧚

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. 😭 so if you see that first one flagging as wrong, deep breath — that's an expected quirk of turning signing on mid-way, not necessarily a compromised log. still worth knowing, fr fr.

🌈 SEE ALSO 🌈

  • pki(1) — go read it, she's the blueprint 💫

🎀 AUTHORS 🎀

Christina Fu <cfu@redhat.com>. thank you queen 🫶

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 http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.

so yeah, that's the whole page. this was PKI, dated July 7, 2016, and you've been reading AuditVerify(1). slay, go verify some logs, and remember: if the signature fails, it's not a vibe 💀✨

📦 where this page comes from