Syslog over TLS

Syslog over TLS sends syslog over a TLS-protected TCP connection. RFC 5425; usual port 6514. The collector presents a server certificate and can require client certificates.

In Syslog Watcher this is a TLS network interface with certificate, key, protocol version, and optional client authentication.

TLS Options

Syslog Collector Configuration - Network Interface - TLS Options
Field Description

Minimum protocol version

Lowest TLS version the server accepts from clients. The default is TLS 1.2. Older versions (TLS 1.0, TLS 1.1) are deprecated and should be avoided.

Server certificate file

Path to the server’s PEM-format certificate file. The chain must start with the server certificate, followed by intermediate CAs, ending at the root CA.

Private key file

Path to the server’s PEM-format private key file (Base64 ASCII encoded). May be the same file as the server certificate if both are stored together.

Private key password

Password for the private key file, if encrypted. Leave empty for unencrypted keys.

Client certificates

Controls whether the collector asks for and validates client certificates. See Client Certificate Validation.
If the private key and the server certificate are in the same file, set its path twice in both fields.

Certificate and Private Key

Syslog Watcher expects the server certificate and private key in PEM format. Use a certificate issued by the organization’s CA, or a self-signed certificate for testing.

The example below uses OpenSSL (Command Prompt on Windows) to generate a 2048-bit RSA private key and a self-signed certificate valid for 365 days. Put the collector host name in the common name (CN). If originators connect by IP address, add that address in the Subject Alternative Name (SAN) — not in the CN:

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 -nodes -keyout server.key -out server.crt -subj "/CN=syslog-collector.example.com" -addext "subjectAltName=DNS:syslog-collector.example.com,IP:192.0.2.10"

Replace the DNS name and IP with the values originators use to reach the collector. Omit the IP:…​ entry if clients connect only by host name.

This creates two files:

  • server.crt — PEM certificate (use as Server certificate file)

  • server.key — PEM private key (use as Private key file)

Because -nodes writes an unencrypted key, leave Private key password empty. Omit -nodes for an encrypted key, then enter that password in the TLS options.

Place the certificate and key files in a directory the Syslog Collector service account can read, and restrict access so only that account (and administrators) can read the private key.

For production, prefer a certificate signed by an internal CA (or a public CA if required), and include the full chain in the certificate file: server certificate first, then intermediates, then the root if needed.

Client Certificate Validation

By default, a TLS interface only authenticates the server (the collector). Originators see the server certificate and encrypt the stream, but the collector does not check who is connecting.

Optional client certificate validation (mutual TLS) lets the collector accept connections only from authorized originators. Use it when source IP is not enough to identify senders, or when senders must authenticate.

Client Certificates Mode

The Client certificates setting under TLS Options controls how strongly the collector enforces client authentication:

Mode Behavior

Do not request (default)

The collector does not ask for a client certificate. Any client that trusts the server certificate can connect. Validate clients via and related fields are hidden.

Request, validate if received

The collector asks for a client certificate. If the client presents one, it is validated. If the client presents none, the connection is still allowed.

Require, validate

The collector requires a client certificate. Connections without a valid client certificate are refused.

When the mode is not Do not request, set Validate clients via to choose how certificates are checked.

Validate Clients Via

Method When to use

Fingerprints

Allow-list specific client certificates by SHA-1 fingerprint, tied to the client’s IP address. Best for a small or medium set of originators, or when clients use self-signed certificates without a shared CA.

CA file

Trust client certificates issued by one or more CAs listed in a single PEM file. Best when originators share an internal PKI.

CA folder

Same as CA file, but CA certificates are loaded from a folder in OpenSSL hash-named layout. Useful when CA certificates are kept as separate files.

Certificate Fingerprints

Set Validate clients via to Fingerprints, then point Fingerprints file to a text file that maps each originator IP address to the SHA-1 fingerprint of its client certificate.

Each line has this form:

<ip-address> sha1:<fingerprint>

Example with one IPv4 and one IPv6 client:

192.0.2.1 sha1:56:97:8E:2C:39:74:62:DB:78:5F:E6:CB:3B:D2:B9:02:C0:81:1F:E6
2001:0db8:85a3:0000:0000:8a2e:0370:7334 sha1:4B:9A:53:B1:E6:0E:FE:E9:BA:6D:BE:96:B3:18:F9:07:06:D7:89:D2

Rules:

  • One IP address and one fingerprint per line

  • The fingerprint must use the sha1: prefix and colon-separated hex bytes

  • The connecting client’s IP must match the IP on the line — a fingerprint alone is not enough

  • The same IP may appear on more than one line to allow certificate rotation

When a client connects, the collector takes the client certificate from the TLS handshake, computes its SHA-1 fingerprint, and looks up the client IP in the file. The connection is accepted only if that IP is listed with a matching fingerprint. Otherwise the connection is refused and the unknown fingerprint is written to Diagnostic Records.

After a refused attempt, copy the fingerprint from Diagnostic Records and add a line for that client’s IP to the fingerprints file. The collector reloads the file automatically, so a service restart is usually unnecessary.

Certificate Authority (CA) File

Set Validate clients via to CA file, then set CA file to a PEM file that contains one or more CA certificates used to issue client certificates.

A CA file can hold several certificates, each delimited as:

-----BEGIN CERTIFICATE-----
... (CA certificate in base64 encoding) ...
-----END CERTIFICATE-----

Also configure a Hosts file so the collector can map each client IP to the host name expected in the certificate.

Certificate Authority (CA) Folder

Set Validate clients via to CA folder, then set CA folder to a directory of CA certificates in PEM format.

Each file holds one CA certificate. Files are looked up by the CA subject name hash (OpenSSL c_rehash layout). Certificates that share the same hash use numbered extensions, for example 9da13359.0, 9da13359.1.

As with CA file, configure a Hosts file for certificate path validation.

Hosts File

The Hosts file is used with CA file and CA folder validation. It maps each originator IP address to the host name that OpenSSL uses when verifying the client certificate (similar to hostname verification).

Each line has this form:

<ip-address> <hostname>

Example:

192.0.2.1 router01.example.com
192.0.2.2 switch02.example.com
2001:0db8:85a3::7334 firewall03.example.com

If the hosts file is missing or empty, CA-based client validation cannot match certificates to senders correctly — check Diagnostic Records for related warnings.