Detections
Analytics

6.1.2.12 Ensure rsyslog TLS CA certificate is configured

Information

When rsyslog forwards logs over TLS, it uses a Certificate Authority (CA) certificate to verify the remote collector's TLS certificate. The CA is specified with the global DefaultNetstreamDriverCAFile directive, or per action with StreamDriver.CAFile (rsyslog 8.2108.0 and later). For mutual authentication, the client also presents its own certificate and key (DefaultNetstreamDriverCertFile / DefaultNetstreamDriverKeyFile, or the per-action StreamDriver.CertFile / StreamDriver.KeyFile). This recommendation applies where rsyslog forwards over TLS.

A trusted CA certificate ensures rsyslog only connects to log servers whose TLS certificates are signed by a known, trusted authority. Without a properly configured CA, forwarding can proceed without verifying the server's identity, exposing the host to man-in-the-middle attacks that intercept, tamper with, or silently discard forwarded logs, resulting in undetected data leakage or loss of audit-trail integrity.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Configure rsyslog with the CA certificate that signs the remote log server's TLS certificate.

 - Add the global CA directive to the drop-in file that defines the TLS forwarding action (for example /etc/rsyslog.d/60-forward-tls.conf ):

global(DefaultNetstreamDriverCAFile="/etc/pki/tls/certs/ca-bundle.crt")

Set the path to the CA that signed the log server certificate: use the system trust bundle /etc/pki/tls/certs/ca-bundle.crt when the server certificate chains to a CA already in the system trust store, or a dedicated CA file (for example /etc/pki/rsyslog/ca.pem ) for an internal certificate authority.

 - Run the following command to restart rsyslog :

# systemctl restart rsyslog

Note: On rsyslog 8.2108.0 and later the CA may instead be set per forwarding action with StreamDriver.CAFile="..." inside the action(type="omfwd" ...) block, preferred when different targets use different CA chains.

If a non-default CA path is used on a system with SELinux in enforcing mode, label the path so rsyslogd can read it, for example:

# semanage fcontext -a -t cert_t '/etc/pki/rsyslog(/.*)?'
# restorecon -Rv /etc/pki/rsyslog

Impact:

A CA certificate (and, for mutual authentication, a client certificate and key) must be provisioned and kept current. If the referenced file is missing, expired, or points to the wrong path, TLS forwarding fails until the trust chain is restored. On systems with SELinux enforcing, a CA file placed outside the paths rsyslogd is allowed to read will be blocked even when ownership and permissions are correct, so custom certificate locations require an SELinux file-context adjustment in addition to the rsyslog configuration.

See Also

https://workbench.cisecurity.org/benchmarks/27892

Item Details

Category: ACCESS CONTROL, IDENTIFICATION AND AUTHENTICATION, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|AC-17(2), 800-53|IA-5, 800-53|IA-5(1), 800-53|SC-8, 800-53|SC-8(1), 800-53|SC-17, CSCv7|14.4

Plugin: Unix

Control ID: 51d34bb6628b2a8a358639a731c6cd2eb4f7d7cda44791a50c3c0702fce3d47f