Sending logs over TLS protects bytes in transit, but encryption alone does not tell a collector who sent a message or tell a sender which collector accepted it. rsyslog's TLS documentation has a direct warning about anonymous authentication: a peer can be replaced and the transport can still look healthy. A log pipeline needs certificate verification, an explicit authentication mode, and a way to detect when either side falls back to a weaker configuration.
Encryption is only one property
The omfwd output module can forward messages over UDP, TCP, or TLS. TLS adds a protected channel, but the connection still needs a trust decision. Configure a CA file, a certificate, a private key where mutual authentication is required, and a permitted peer name. Use a driver mode that enables TLS rather than relying on a port number to imply it. The sender must validate the receiver's certificate and the receiver must validate the sender's certificate when the receiver is expected to accept only known clients.
Anonymous authentication is useful for a quick lab test and a poor default for production. It leaves the receiver unable to distinguish a legitimate sender from another host that can reach the port. An attacker who can intercept the network path may also be able to present a different endpoint. The rsyslog FAQ describes this as a MITM condition rather than a theoretical warning.
Put the policy in configuration review
An rsyslog action should show the trust material near the forwarding rule. Check StreamDriver, StreamDriverMode, StreamDriverAuthMode, StreamDriver.CAFile, StreamDriver.CertFile, and StreamDriver.KeyFile. Where the driver supports it, pin the permitted peer name and certificate purpose. Make the CA path a configuration item owned by the same team that manages the log receiver. Do not copy a private key into a generic application configuration repository.
Mutual TLS is not a substitute for message integrity inside the application. Syslog messages remain separate records, and a sender can still emit false content. TLS protects transport and endpoint identity. It does not prove that a process on an authorized host was uncompromised.
Test failure, not just delivery
Build four test cases:
- 1.
A correctly configured sender reaches the collector and the collector records the message.
- 2.
The sender is given the wrong CA and the connection fails.
- 3.
The receiver is given a client certificate from an untrusted CA and rejects it.
- 4.
The permitted peer name is changed and the connection fails even when the CA is trusted.
These tests turn certificate verification into evidence. Also monitor certificate expiry, handshake failures, and gaps in expected sender coverage. A sender that silently stops forwarding is an outage even when the receiver is healthy.
Keep the collection path usable
Use a dedicated collector port and a certificate lifecycle owned by operations. Rotate certificates before expiry and retain the old public CA only for the approved overlap window. Separate transport credentials from log content permissions. Restrict who can alter the forwarding configuration. Back up the trust material and document recovery, because a collector that cannot validate its own clients can become a costly outage during an incident.
The goal is not a green TLS icon. It is a log path where both identities are checked, failed verification is visible, and the evidence survives a restart.