Prepare for External Log Shipping over TLS (Optional)

This example demonstrates a minimal rsyslog Rsyslog is an open-source software utility used on UNIX and Unix-like computer systems for forwarding log messages in an IP network. configuration that accepts audit events from Keyfactor Command over a TLS TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers.-encrypted TCP connection.

This configuration:

• Enables TLS on the syslog receiver

• Does not require client certificate authentication

• Listens on a dedicated TLS syslog port

Additional configuration may be required if the syslog server forwards logs onward to another system over TLS.

Prerequisites

• A Linux server with rsyslog installed

• A server certificate and private key Private keys are used in cryptography (symmetric and asymmetric) to encrypt or sign content. In asymmetric cryptography, they are used together in a key pair with a public key. The private or secret key is retained by the key's creator, making it highly secure. installed on the syslog server

• The issuing CA A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. certificate available for validation

SSL Server Certificate on the Log Server

To secure syslog communications over TLS, the log server must have a server certificate installed.

The certificate must:

• Include the Server Authentication extended key usage (EKU)

• Be issued by a trusted certificate authority A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. (CA)

• Contain the fully qualified domain name (FQDN) used by Keyfactor Command to connect to the log server

For example:

Enrollment Options

You can enroll for the server certificate using any method supported in your environment. Common approaches include:

• OpenSSL CSR + Keyfactor Command CSR Enrollment

  Generate a private key and CSR A CSR or certificate signing request is a block of encoded text that is submitted to a CA when enrolling for a certificate. When you generate a CSR within Keyfactor Command, the matching private key for it is stored in Keyfactor Command in encrypted format and will be married with the certificate once returned from the CA. on the log server using OpenSSL. Submit the CSR through Keyfactor Command (Management Portal or Keyfactor API An API is a set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command.), then install the issued certificate alongside the private key on the log server.

• Microsoft MMC (Windows Enrollment)

  Enroll for the certificate using the Certificates MMC snap-in on a Windows server. Export the certificate as a PFX A PFX file (personal information exchange format), also known as a PKCS #12 archive, is a single, password-protected certificate archive that contains both the public and matching private key and, optionally, the certificate chain. It is a common format for Windows servers. file and copy it to the log server. Then separate the certificate and private key components as described below.

• certreq (Windows Command Line)

  Use certreq with a request.inf file to generate and submit a request. Export the resulting certificate as a PFX file and transfer it to the log server for extraction.

• Keyfactor Command PFX Enrollment

  Use the PFX enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). method in Keyfactor Command and download the certificate as a ZIP PEM A ZIP archive containing multiple PEM encoded certificates, which may include an end entity certificate, certificate chain, and private key. bundle. Transfer the ZIP file to the log server, export the contents, and place the certificate, key, and CA files in the appropriate directories.

Be sure to include the certificate chain with the certificate in the resulting file you copy to your log server.

Installing the Certificate

To prepare the certificate for use on the log server, securely copy either the PFX file or the ZIP PEM A PEM format certificate file is a Base64-encoded certificate. Since it's presented in ASCII, you can open it in any text editor. PEM certificates always begin and end with entries like ---- BEGIN CERTIFICATE---- and ----END CERTIFICATE----. PEM certificates can contain a single certificate or a full certificate chain and may contain a private key. In general, extensions of .cer and .crt are certificate files with no private key, .key is a separate private key file, and .pem is both a certificate and private key. file to the log server and place it in a temporary working directory.

rsyslog requires:

• An unencrypted private key file

• A server certificate file

• A CA certificate (or full chain) file

The steps differ depending on the format you exported.

Option 1: Using a ZIP PEM Bundle

If you downloaded the certificate as a ZIP PEM bundle from Keyfactor Command:

1. Copy the ZIP file to the log server.

2. Export the contents:

   unzip certificate-bundle.zip

The extracted files typically include:

• Server certificate (for example, server-cert.pem)

• Private key (for example, server-key.pem)

• CA certificate or chain file (for example, cacert.pem)

Decrypt the private key:

Move the files to their final locations (for example):

Option 2: Using a PFX File

If your certificate is in a PFX file, export the required components using OpenSSL.

1. Export the private key:

   openssl pkcs12 -in certfile.pfx -nocerts -out key.pem

   You will be prompted for:

   • The PFX password

   • A new password for the PEM key file

2. Export the server certificate:

   openssl pkcs12 -in certfile.pfx -clcerts -nokeys -out cert.pem

3. Export the CA certificates:

   openssl pkcs12 -in certfile.pfx -cacerts -nokeys -chain -out cacerts.pem

4. Remove encryption from the private key:

   openssl rsa -in key.pem -out decrypted-key.key

Final Placement

After separating the files:

• Place the server certificate and CA certificate in a secure certificate directory (for example, /etc/tls/certs)

• Place the unencrypted private key in a restricted directory (for example, /etc/tls/private)

• Set ownership and permissions so that the syslog user can read the files

By default, rsyslog runs as the syslog user (after startup privilege drop). The private key file must therefore be readable by the syslog user.

Private key (sensitive)

• Owner: root

• Group: syslog

• Mode: 640

• Not world-readable

• Not writable by syslog

Server certificate and CA certificate (public material)

Ensure the directories themselves are not world-writable.

Configuring rsyslog for TLS Support

Configuration of rsyslog for TLS support may vary by Linux distribution. TLS support may require separate installation of the GnuTLS driver module for rsyslog.

Ensure that:

• rsyslog is installed

• The rsyslog GnuTLS module (commonly provided by a package such as rsyslog-gnutls) is installed

On Debian-based systems (for example, Ubuntu), you can install the required packages using:

On Red Hat–based systems, the TLS module is typically included in the main rsyslog package, but may require activating the appropriate module or installing additional packages depending on your distribution.

For troubleshooting and certificate validation, tools such as OpenSSL or the GnuTLS utilities package may also be helpful.

Create the rsyslog Configuration File

The following is an example rsyslog.conf file configured for both TLS and non-TLS support using ports 514 and 6514.

Although TCP port 514 for non-TLS and TCP port 6514 for TLS are common for this, any port may be used if both systems are configured consistently.

# /etc/rsyslog.conf
#
# Example syslog receiver configuration for Keyfactor Command audit log shipping.
# This example supports:
#   - Non-TLS syslog (TCP/514; optional UDP/514)
#   - TLS syslog (TCP/6514)
#
# NOTE: The port values are examples. Use any port as long as the sender and receiver match.

#################
#### MODULES ####
#################

module(load="imuxsock")                          # local system logging
module(load="imklog" permitnonkernelfacility="on")

module(load="imtcp")                             # required for TCP syslog (non-TLS and TLS)
# module(load="imudp")                           # optional: only needed if you want UDP syslog

###########################
#### GLOBAL DIRECTIVES ####
###########################

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$RepeatedMsgReduction off                         # set to 'on' if you want duplicate suppression

$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog

$WorkDirectory /var/spool/rsyslog

###########################
#### NON-TLS LISTENERS ####
###########################

# Non-TLS syslog over TCP (commonly 514)
# (Keyfactor Command connection validation expects TCP.)
input(type="imtcp" port="514")

# Optional: Non-TLS syslog over UDP (commonly 514)
# Uncomment both the module(load="imudp") line above and the input below to enable.
# input(type="imudp" port="514")

###########################
#### TLS CONFIGURATION ####
###########################

# TLS settings used by GTLS-based inputs.
# These lines apply only when you enable the TLS listener below.
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile   /etc/tls/certs/cacert.pem
$DefaultNetstreamDriverCertFile /etc/tls/certs/server-cert.pem
$DefaultNetstreamDriverKeyFile  /etc/tls/private/server-key.pem

###########################
#### TLS LISTENER ONLY  ####
###########################

# TLS syslog over TCP (commonly 6514)
# AuthMode="anon" enables encryption without requiring a client certificate (no mutual TLS).
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"          # TLS-only
  StreamDriver.AuthMode="anon"   # do not require client certificate
)

###########################
#### INCLUDE SNIPPETS  ####
###########################

$IncludeConfig /etc/rsyslog.d/*.conf

Create a Keyfactor Command Audit Routing Rule

After configuring the syslog listeners in rsyslog.conf, create a separate configuration snippet to route Keyfactor Command audit events to a dedicated log file.

Define application-specific routing rules in /etc/rsyslog.d/ rather than modifying the main configuration file. Files in /etc/rsyslog.d/ are processed in lexical order. Place the Keyfactor Command audit routing rule in a file that loads before any general remote catch-all rules. Otherwise, a catch-all rule may capture the messages first and prevent the Keyfactor Command rule from running.

For example:

• 10-keyfactor.conf: Routes Keyfactor Command audit events to /var/log/keyfactor/audit.log

• 30-remote.conf: Routes all other remote syslog traffic to /var/log/remote/<host>/syslog.log

Create the file:

This example writes Keyfactor Command audit events to a dedicated log file. It matches on message content rather than syslog tag to ensure compatibility with both RFC 3164 (non-TLS) and RFC 5424 (TLS) formats.

Example: 10-keyfactor.conf

# 10-keyfactor.conf
#
# Route Keyfactor Command audit events received from remote systems
# to a dedicated audit log file.

if ($fromhost-ip != "127.0.0.1" and $fromhost-ip != "::1") and
   ($msg contains "performed the operation" and
    $msg contains "operation code") then {

    action(
        type="omfile"
        file="/var/log/keyfactor/audit.log"
        createDirs="on"
    )

    stop
}

Example: 30-remote.conf

# Catch-all: store any other remote syslog messages.
template(name="RemoteSyslogFile" type="string"
         string="/var/log/remote/%HOSTNAME%/syslog.log")

if ($fromhost-ip != "127.0.0.1" and $fromhost-ip != "::1") then {
  action(type="omfile" dynaFile="RemoteSyslogFile" createDirs="on")
  stop
}

Explanation

• $msg contains

  Filters based on message body content to ensure compatibility with both TLS and non-TLS formatting.

• file="/var/log/keyfactor/audit.log"

  Specifies the destination log file.

• createDirs="on"

  Automatically creates the directory if it does not exist.

• stop

  Prevents further processing of matched audit messages by later rules.

Apply the Configuration

After creating the file, run rsyslog in config validation mode to test the configuration and if it returns with no errors, restart the rsyslog daemon.

For example:

If your system does not use systemd, use the appropriate service management command for your distribution.

Log Rotation and Retention

Audit logs written by rsyslog will continue to grow until rotated. To prevent excessive disk usage, configure log rotation and retention policies appropriate for your environment.

Most Linux distributions include the logrotate utility for managing log file size and retention.

Configure logrotate for Keyfactor Command Audit Logs

Create a file such as:

Example configuration:

/var/log/keyfactor/audit.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog adm
    sharedscripts
    postrotate
        systemctl reload rsyslog >/dev/null 2>&1 || true
    endscript
}

What This Configuration Does

• daily

  Rotates the log once per day.

• rotate 30

  Keeps 30 archived log files before deleting the oldest.

• compress

  Compresses rotated logs to conserve disk space.

• delaycompress

  Delays compression until the next rotation cycle (avoids issues with active file handles).

• create 0640 syslog adm

  Ensures the new log file has correct ownership and permissions.

• postrotate

  Reloads rsyslog so it continues writing to the newly created file.

Retention Considerations

Retention policies should be determined based on:

• Organizational compliance requirements

• Audit retention policies

• Available disk capacity

• Whether logs are forwarded to a centralized logging platform

If audit logs are forwarded to a centralized solution for long-term retention, the local retention period may be shorter.