Syslog over TLS

Syslog over TLS (RFC 5425) sends syslog over an encrypted TCP connection, usually to port 6514. The collector presents a server certificate and can require client certificates.

In Syslog Watcher this is a TLS network interface. You do not point the interface to certificate files. Instead, you add the certificate once to the Syslog Watcher Server’s certificate store, and then select it by name in the interface settings. To manage the store, use TLS Certificates (More → TLS Certificates… in the Server section of the main toolbar).

TLS Options

The TLS Options section of a TLS interface has these settings:

Setting Description

Setting	Description
Minimum protocol version	Lowest TLS version the collector accepts: TLS 1.0, TLS 1.1, TLS 1.2, or TLS 1.3. The initial value is TLS 1.2. Lower it only when an older originator cannot connect otherwise.
Certificate	Server certificate and private key, chosen by name from TLS Certificates. The button next to the list opens TLS Certificates, where you can generate or import a certificate.
Private key password	Password for an encrypted private key. Use a secret string (`%SECRET%`) instead of the actual password. When you select a Certificate, Manager fills in the secret string stored for it, if there is one; otherwise it clears the field. Leave it empty for an unencrypted key.
Client certificates	Do not request (initial value), Request, validate if received, or Require, validate. See Client Certificate Validation.

Minimum protocol version

Lowest TLS version the collector accepts: TLS 1.0, TLS 1.1, TLS 1.2, or TLS 1.3. The initial value is TLS 1.2. Lower it only when an older originator cannot connect otherwise.

Certificate

Server certificate and private key, chosen by name from TLS Certificates. The button next to the list opens TLS Certificates, where you can generate or import a certificate.

Private key password

Password for an encrypted private key. Use a secret string (%SECRET%) instead of the actual password. When you select a Certificate, Manager fills in the secret string stored for it, if there is one; otherwise it clears the field. Leave it empty for an unencrypted key.

Client certificates

Do not request (initial value), Request, validate if received, or Require, validate. See Client Certificate Validation.

If Certificate is empty when the configuration is applied, Manager offers to generate a self-signed certificate and selects it. A TLS interface does not work without a certificate.

Server Certificate

Originators check the collector’s certificate when they connect. The name they use to reach the collector (host name or IP address) must appear in the certificate, and the certificate must be trusted by the originator.

There are two ways to get a certificate into the store:

► Generate Self-signed Certificate — quick to set up; every originator must be configured to trust that certificate (or to skip verification). Add the collector host name and, if originators connect by IP, its IP address as Subject Alternative Names (SAN).
► Import — a certificate issued by the organization’s CA (or a public CA), with its private key, in PEM format. Include the chain in the certificate file: server certificate first, then intermediate CAs.

Both are described in TLS Certificates.

A certificate can also be created outside Syslog Watcher, for example with OpenSSL, and then imported:

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, then import server.crt and server.key with Import → From PEM File….

Client Certificate Validation

By default, only the originator checks the other side: it verifies the collector’s server certificate. The connection is encrypted, but the collector does not check who connects.

With client certificate validation (mutual TLS), the collector accepts connections only from authorized originators.

Client Certificates Mode

Mode

Behavior

Do not request

No client certificate is requested. Any client that trusts the server certificate can connect.

Request, validate if received

A client certificate is requested. If the client sends one, it must pass validation. A client that sends none is still accepted.

Rarely needed. Example: during a gradual rollout of client certificates, originators that already have one are validated, while the others keep sending until they get theirs. Then switch to Require, validate.

Require, validate

A client certificate is required and must pass validation. Clients without one are refused.

When the mode is not Do not request, two validation methods appear. A client is accepted if it passes either method.

Setting	Description
Allow self-signed certificates	Yes accepts a client certificate whose fingerprint is allowed in Certificate fingerprints. The certificate does not need to be issued by a CA.
Certificate Authority (CA)	CA certificate, by name, from TLS Certificates. Client certificates must be issued by this CA. Blank turns CA validation off.

Setting

Description

Allow self-signed certificates

Yes accepts a client certificate whose fingerprint is allowed in Certificate fingerprints. The certificate does not need to be issued by a CA.

Certificate Authority (CA)

CA certificate, by name, from TLS Certificates. Client certificates must be issued by this CA. Blank turns CA validation off.

If neither method is on, every client certificate is refused.

Certificate Fingerprints

Use fingerprints for a small set of originators, or for originators with self-signed certificates and no shared CA.

Set Allow self-signed certificates to Yes.
Let the originator try to connect once. The collector refuses it and records the certificate fingerprint. When Certificate Authority (CA) is blank, it also writes a warning to Diagnostic Records.
Double-click Certificate fingerprints, or click its … button. The value shows how many fingerprints are allowed.
In the Certificate fingerprints window, check the row for that originator and click Apply.

Each row shows From IP, Algorithm, and Fingerprint; the window title shows the allowed and total counts. A checked row is allowed; an unchecked row is known but refused. An allowed fingerprint is valid only for the IP address it came from.

The list is saved when you click Apply in that window, separately from the interface settings; the collector picks up the change without a restart.

With no allowed fingerprints, every self-signed client is refused.

CA Validation, IP, and Names

Use a CA when originators share an internal PKI.

When Certificate Authority (CA) is set, the client certificate chain must lead to that CA. Two more settings can then tie the certificate to the connecting client:

Setting	Description
Allow clients by IP	Yes accepts the client when its certificate has the client’s source IP address in a SAN IP entry.
Allow clients by name	Allow any name (no check) (initial value) accepts every certificate from the CA. N allowed accepts only certificate names (CN or DNS SAN) that are allowed in the Client names list.

Setting

Description

Allow clients by IP

Yes accepts the client when its certificate has the client’s source IP address in a SAN IP entry.

Allow clients by name

Allow any name (no check) (initial value) accepts every certificate from the CA. N allowed accepts only certificate names (CN or DNS SAN) that are allowed in the Client names list.

With both left off (No and Allow any name), any certificate from the CA is accepted.

With either on, the client must match at least one of them; otherwise it is refused and a name check warning is written to Diagnostic Records.

Troubleshooting

Symptom What to check

Symptom	What to check
`TLS handshake failed`	The originator does not trust the server certificate, or the name it connects with is not in the certificate. Add the right SAN entries, or import a CA-issued certificate. With client certificates on: the client certificate is not from the configured CA, or no validation method is on.
`TLS handshake failed` with a protocol version error	The originator’s TLS version is below Minimum protocol version. Update the originator if possible; lower the minimum only if needed.
`The received client certificate is unknown`	Self-signed client not allowed yet. Allow it in Certificate fingerprints.
`Client certificate name check failed`	CA-issued client certificate does not match Allow clients by IP or Allow clients by name. Allow the name in Client names, or add the client IP to its certificate SAN.

TLS handshake failed

The originator does not trust the server certificate, or the name it connects with is not in the certificate. Add the right SAN entries, or import a CA-issued certificate.
With client certificates on: the client certificate is not from the configured CA, or no validation method is on.

TLS handshake failed with a protocol version error

The originator’s TLS version is below Minimum protocol version. Update the originator if possible; lower the minimum only if needed.

The received client certificate is unknown

Self-signed client not allowed yet. Allow it in Certificate fingerprints.

Client certificate name check failed

CA-issued client certificate does not match Allow clients by IP or Allow clients by name. Allow the name in Client names, or add the client IP to its certificate SAN.