The audit log is an append-only, filterable record of everything that changes state in Skyrsoft CertOps — issuance, revocation, approvals, CA lifecycle changes, template and rule edits, and admin actions — searchable by event type and actor. It’s the record to search first when investigating an unexpected certificate: who requested it, who approved it, and what rule or admin action put it there. Forwarding a copy to an external syslog collector or SIEM is available on every edition, including Free.
How it works
Two streams forward independently, so the audit trail can reach a SIEM without also shipping the operational noise of the application log. Audit events cover the same entries that reach the Audit Log page — from the console, an agent, the REST API or a background engine — with severity derived from the event type: failures and denials map to Warning, destructive and revocation events to Notice, everything else to Informational. The server log is the application’s own log output, filtered by a configurable minimum level. Forwarding is fire-and-forget: producers write onto a bounded in-memory queue and a single background sender owns the connection, reconnecting with backoff if the collector drops. If that queue fills, events are dropped and counted rather than blocking — issuance, renewal and revocation keep working regardless of whether the collector is reachable. The audit log in the database remains the authoritative copy; treat the forwarded stream as best-effort telemetry alongside it, not a replacement for it.
Formats and transports
Three wire formats are available — RFC 5424 (the default), RFC 3164 for a collector that only parses legacy BSD syslog, and JSON behind a syslog priority header for a SIEM with a native JSON parser. Three transports are available — UDP, plain TCP, and TCP wrapped in TLS — and TCP framing can be a trailing newline or an octet count, matching whichever your collector expects.
TLS to the collector: what each mode actually checks
Three TLS behaviours are available when the transport is TCP over TLS, and they check different things:
| Mode | What is verified |
|---|---|
| Default (no pinned CA configured) | The OS trust store validates the chain, and the collector’s hostname is checked against the certificate — ordinary TLS validation. |
| Pinned CA certificate supplied | The presented certificate must chain to the CA you pinned. The collector’s hostname is not checked at all, and revocation checking is off for that chain build. |
| “Allow untrusted” explicitly set | Any certificate is accepted, regardless of what it chains to. |
Pinned-CA mode exists for a collector whose certificate doesn’t chain to a public root — an internal SIEM issued from your own CA is the common case. What it buys you is narrower than a normal TLS check: it proves the presented certificate was issued by the CA you named, not that you’re talking to the specific collector you intended. An internal CA typically issues certificates to many hosts, so any of them can present a valid certificate under that same CA and be accepted in the collector’s place — there is no name-matching step to catch a different host doing so. Point this mode at a CA that issues narrowly (ideally one scoped to the collector alone), and treat it as authenticating “a member of this PKI” rather than “this exact machine.”
Limits
Pinned-CA TLS does not check the collector’s hostname, and does not check revocation. Restated plainly because it’s the one thing to get right before relying on this mode: any certificate that chains to the pinned CA is accepted as the collector, and a certificate revoked by that CA is still accepted since the chain build runs with revocation checking off. Where the pinned CA is broad, place the collector somewhere that assumption is acceptable, or use a CA scoped to the collector alone.
A dropped collector never blocks a certificate operation, but it does drop events. The in-memory queue is bounded; once full, further events are discarded and counted rather than queued indefinitely, so a collector that stays unreachable for long enough produces gaps rather than backpressure.
The database-backed Audit Log is the record of truth. Syslog and SIEM forwarding is best-effort delivery of the same events, so where the two ever disagree, the Audit Log is the one to read.