Chat now with support
Chat with Support

syslog-ng Premium Edition 6.0.17 - Administration Guide

Preface Chapter 1. Introduction to syslog-ng Chapter 2. The concepts of syslog-ng Chapter 3. Installing syslog-ng Chapter 4. The syslog-ng PE quick-start guide Chapter 5. The syslog-ng PE configuration file Chapter 6. Collecting log messages — sources and source drivers Chapter 7. Sending and storing log messages — destinations and destination drivers Chapter 8. Routing messages: log paths, reliability, and filters Chapter 9. Global options of syslog-ng PE Chapter 10. TLS-encrypted message transfer Chapter 11. FIPS-compliant syslog-ng Chapter 12.  Reliable Log Transfer Protocol™ Chapter 13. Reliability and minimizing the loss of log messages Chapter 14. Manipulating messages Chapter 15. Parsing and segmenting structured messages Chapter 16. Processing message content with a pattern database Chapter 17. Statistics and metrics of syslog-ng Chapter 18. Multithreading and scaling in syslog-ng PE Chapter 19. Troubleshooting syslog-ng Chapter 20. Best practices and examples

Chapter 10. TLS-encrypted message transfer

Secure logging using TLS

The syslog-ng application can send and receive log messages securely over the network using the Transport Layer Security (TLS) protocol using the network() and syslog() drivers.

TLS uses certificates to authenticate and encrypt the communication, as illustrated on the following figure:

Figure 10.1. Certificate-based authentication

Certificate-based authentication

The client authenticates the server by requesting its certificate and public key. Optionally, the server can also request a certificate from the client, thus mutual authentication is also possible.

In order to use TLS encryption in syslog-ng, the following elements are required:

  • A certificate on the syslog-ng server that identifies the syslog-ng server.

  • The certificate of the Certificate Authority that issued the certificate of the syslog-ng server (or the self-signed certificate of the syslog-ng server) must be available on the syslog-ng client.

When using mutual authentication to verify the identity of the clients, the following elements are required:

  • A certificate must be available on the syslog-ng client. This certificate identifies the syslog-ng client.

  • The certificate of the Certificate Authority that issued the certificate of the syslog-ng client must be available on the syslog-ng server.

Mutual authentication ensures that the syslog-ng server accepts log messages only from authorized clients.

For details on configuring TLS communication in syslog-ng, see the section called “Encrypting log messages with TLS”.

Encrypting log messages with TLS

This section describes how to configure TLS encryption in syslog-ng. For the concepts of using TLS in syslog-ng, see the section called “Secure logging using TLS”.

Create an X.509 certificate for the syslog-ng server.

NOTE:

The subject_alt_name parameter (or the Common Name parameter if the subject_alt_name parameter is empty) of the server's certificate must contain the hostname or the IP address (as resolved from the syslog-ng clients and relays) of the server (for example syslog-ng.example.com).

Alternatively, the Common Name or the subject_alt_name parameter can contain a generic hostname, for example *.example.com.

Note that if the Common Name of the certificate contains a generic hostname, do not specify a specific hostname or an IP address in the subject_alt_name parameter.

Procedure 10.1. Configuring TLS on the syslog-ng clients

Purpose: 

Complete the following steps on every syslog-ng client host. Examples are provided using both the legacy BSD-syslog protocol (using the network() driver) and the new IETF-syslog protocol standard (using the syslog() driver):

Steps: 

  1. Copy the CA certificate (for example cacert.pem) of the Certificate Authority that issued the certificate of the syslog-ng server (or the self-signed certificate of the syslog-ng server) to the syslog-ng client hosts, for example into the /opt/syslog-ng/etc/syslog-ng/ca.d directory.

    Issue the following command on the certificate: openssl x509 -noout -hash -in cacert.pem The result is a hash (for example 6d2962a8), a series of alphanumeric characters based on the Distinguished Name of the certificate.

    Note that by default, syslog-ng PE expects SHA-1 hashes. If you want to use MD5 hashes for some reason, use the ca_dir_layout(md5-based) option in your configuration (for details, see Collecting log messages from UDP sources).

    Issue the following command to create a symbolic link to the certificate that uses the hash returned by the previous command and the .0 suffix.

    ln -s cacert.pem 6d2962a8.0

    On Microsoft Windows, use the following command: mklink 6d2962a8.0 cacert.pem

  2. Add a destination statement to the syslog-ng configuration file that uses the tls( ca-dir(path_to_ca_directory) ) option and specify the directory using the CA certificate. The destination must use the network() or the syslog() destination driver, and the IP address and port parameters of the driver must point to the syslog-ng server.

    Example 10.1. A destination statement using TLS

    The following destination encrypts the log messages using TLS and sends them to the 6514/TCP port of the syslog-ng server having the 10.1.2.3 IP address.

    destination demo_tls_destination {
        network("10.1.2.3" port(6514)
            transport("tls")
            tls( ca-dir("/opt/syslog-ng/etc/syslog-ng/ca.d"))
        );
    };

    A similar statement using the IETF-syslog protocol and thus the syslog() driver:

    destination demo_tls_syslog_destination {
        syslog("10.1.2.3" port(6514)
            transport("tls")
            tls(ca-dir("/opt/syslog-ng/etc/syslog-ng/ca.d"))
        );
    };

  3. Include the destination created in Step 2 in a log statement.

    Caution:

    The encrypted connection between the server and the client fails if the Common Name or the subject_alt_name parameter of the server certificate does not contain the hostname or the IP address (as resolved from the syslog-ng clients and relays) of the server.

    Do not forget to update the certificate files when they expire.

Procedure 10.2. Configuring TLS on the syslog-ng server

Purpose: 

Complete the following steps on the syslog-ng server:

Steps: 

  1. Copy the certificate (for example syslog-ng.cert) of the syslog-ng server to the syslog-ng server host, for example into the /opt/syslog-ng/etc/syslog-ng/cert.d directory. The certificate must be a valid X.509 certificate in PEM format.

  2. Copy the private key (for example syslog-ng.key) matching the certificate of the syslog-ng server to the syslog-ng server host, for example into the /opt/syslog-ng/etc/syslog-ng/key.d directory. The key must be in PEM format, and must not be password-protected.

  3. Add a source statement to the syslog-ng configuration file that uses the tls( key-file(key_file_fullpathname) cert-file(cert_file_fullpathname) ) option and specify the key and certificate files. The source must use the source driver (network() or syslog()) matching the destination driver used by the syslog-ng client.

    Example 10.2. A source statement using TLS

    The following source receives log messages encrypted using TLS, arriving to the 1999/TCP port of any interface of the syslog-ng server.

    source demo_tls_source {
        network(ip(0.0.0.0) port(1999)
            transport("tls")
            tls( key-file("/opt/syslog-ng/etc/syslog-ng/key.d/syslog-ng.key")
                 cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/syslog-ng.cert"))
        );
    };

    A similar source for receiving messages using the IETF-syslog protocol:

    source demo_tls_syslog_source {
        syslog(ip(0.0.0.0) port(1999)
            transport("tls")
            tls( key-file("/opt/syslog-ng/etc/syslog-ng/key.d/syslog-ng.key")
                 cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/syslog-ng.cert"))
        );
    };

  4. Disable mutual authentication for the source by setting the following TLS option in the source statement: tls( peer-verify(optional-untrusted);

    For details on how to configure mutual authentication, see the section called “Mutual authentication using TLS”.

    For the details of the available tls() options, see the section called “TLS options”.

    Example 10.3. Disabling mutual authentication

    The following source receives log messages encrypted using TLS, arriving to the 1999/TCP port of any interface of the syslog-ng server. The identity of the syslog-ng client is not verified.

    source demo_tls_source {
        network(ip(0.0.0.0) port(1999)
            transport("tls")
            tls( key-file("/opt/syslog-ng/etc/syslog-ng/key.d/syslog-ng.key")
                 cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/syslog-ng.cert")
                 peer-verify(optional-untrusted))
        );
    };

    A similar source for receiving messages using the IETF-syslog protocol:

    source demo_tls_syslog_source {
        syslog(ip(0.0.0.0) port(1999)
            transport("tls")
            tls( key-file("/opt/syslog-ng/etc/syslog-ng/key.d/syslog-ng.key")
                 cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/syslog-ng.cert")
                 peer-verify(optional-untrusted))
        );
    };

    Caution:

    Do not forget to update the certificate and key files when they expire.

Mutual authentication using TLS

This section describes how to configure mutual authentication between the syslog-ng server and the client. Configuring mutual authentication is similar to configuring TLS (for details, see the section called “Encrypting log messages with TLS”), but the server verifies the identity of the client as well. Therefore, each client must have a certificate, and the server must have the certificate of the CA that issued the certificate of the clients. For the concepts of using TLS in syslog-ng, see the section called “Secure logging using TLS”.

Procedure 10.3. Configuring TLS on the syslog-ng clients

Purpose: 

Complete the following steps on every syslog-ng client host. Examples are provided using both the legacy BSD-syslog protocol (using the network() driver) and the new IETF-syslog protocol standard (using the syslog() driver):

Steps: 

  1. Create an X.509 certificate for the syslog-ng client.

  2. Copy the certificate (for example client_cert.pem) and the matching private key (for example client.key) to the syslog-ng client host, for example into the /opt/syslog-ng/etc/syslog-ng/cert.d directory. The certificate must be a valid X.509 certificate in PEM format and must not be password-protected.

  3. Copy the CA certificate of the Certificate Authority (for example cacert.pem) that issued the certificate of the syslog-ng server (or the self-signed certificate of the syslog-ng server) to the syslog-ng client hosts, for example into the /opt/syslog-ng/etc/syslog-ng/ca.d directory.

    Issue the following command on the certificate: openssl x509 -noout -hash -in cacert.pem The result is a hash (for example 6d2962a8), a series of alphanumeric characters based on the Distinguished Name of the certificate.

    Note that by default, syslog-ng PE expects SHA-1 hashes. If you want to use MD5 hashes for some reason, use the ca_dir_layout(md5-based) option in your configuration.

    Issue the following command to create a symbolic link to the certificate that uses the hash returned by the previous command and the .0 suffix.

    ln -s cacert.pem 6d2962a8.0

    On Microsoft Windows, use the following command: mklink 6d2962a8.0 cacert.pem

  4. Add a destination statement to the syslog-ng configuration file that uses the tls( ca-dir(path_to_ca_directory) ) option and specify the directory using the CA certificate. The destination must use the network() or the syslog() destination driver, and the IP address and port parameters of the driver must point to the syslog-ng server. Include the client's certificate and private key in the tls() options.

    Example 10.4. A destination statement using mutual authentication

    The following destination encrypts the log messages using TLS and sends them to the 1999/TCP port of the syslog-ng server having the 10.1.2.3 IP address. The private key and the certificate file authenticating the client is also specified.

    destination demo_tls_destination {
        network("10.1.2.3" port(1999)
            transport("tls")
            tls( ca-dir("/opt/syslog-ng/etc/syslog-ng/ca.d")
                 key-file("/opt/syslog-ng/etc/syslog-ng/key.d/client.key")
                 cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/client_cert.pem")) ); };
    destination demo_tls_syslog_destination {
        syslog("10.1.2.3" port(1999)
            transport("tls")
                tls( ca-dir("/opt/syslog-ng/etc/syslog-ng/ca.d")
                     key-file("/opt/syslog-ng/etc/syslog-ng/key.d/client.key")
                     cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/client_cert.pem")) ); };

  5. Include the destination created in Step 2 in a log statement.

    Caution:

    The encrypted connection between the server and the client fails if the Common Name or the subject_alt_name parameter of the server certificate does not the hostname or the IP address (as resolved from the syslog-ng clients and relays) of the server.

    Do not forget to update the certificate files when they expire.

Procedure 10.4. Configuring TLS on the syslog-ng server

Purpose: 

Complete the following steps on the syslog-ng server:

Steps: 

  1. Copy the certificate (for example syslog-ng.cert) of the syslog-ng server to the syslog-ng server host, for example into the /opt/syslog-ng/etc/syslog-ng/cert.d directory. The certificate must be a valid X.509 certificate in PEM format.

  2. Copy the CA certificate (for example cacert.pem) of the Certificate Authority that issued the certificate of the syslog-ng clients to the syslog-ng server, for example into the /opt/syslog-ng/etc/syslog-ng/ca.d directory.

    Issue the following command on the certificate: openssl x509 -noout -hash -in cacert.pem The result is a hash (for example 6d2962a8), a series of alphanumeric characters based on the Distinguished Name of the certificate.

    Note that by default, syslog-ng PE expects SHA-1 hashes. If you want to use MD5 hashes for some reason, use the ca_dir_layout(md5-based) option in your configuration.

    Issue the following command to create a symbolic link to the certificate that uses the hash returned by the previous command and the .0 suffix.

    ln -s cacert.pem 6d2962a8.0

    On Microsoft Windows, use the following command: mklink 6d2962a8.0 cacert.pem

  3. Copy the private key (for example syslog-ng.key) matching the certificate of the syslog-ng server to the syslog-ng server host, for example into the /opt/syslog-ng/etc/syslog-ng/key.d directory. The key must be in PEM format, and must not be password-protected.

  4. Add a source statement to the syslog-ng configuration file that uses the tls( key-file(key_file_fullpathname) cert-file(cert_file_fullpathname) ) option and specify the key and certificate files. The source must use the source driver (network() or syslog()) matching the destination driver used by the syslog-ng client. Also specify the directory storing the certificate of the CA that issued the client's certificate.

    For the details of the available tls() options, see the section called “TLS options”.

    Example 10.5. A source statement using TLS

    The following source receives log messages encrypted using TLS, arriving to the 1999/TCP port of any interface of the syslog-ng server.

    source demo_tls_source {
        network(ip(0.0.0.0) port(1999)
            transport("tls")
            tls( key-file("/opt/syslog-ng/etc/syslog-ng/key.d/syslog-ng.key")
                 cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/syslog-ng.cert")
                 ca-dir("/opt/syslog-ng/etc/syslog-ng/ca.d")) ); };

    A similar source for receiving messages using the IETF-syslog protocol:

    source demo_tls_syslog_source {
        syslog(ip(0.0.0.0) port(1999)
        transport("tls")
        tls( key-file("/opt/syslog-ng/etc/syslog-ng/key.d/syslog-ng.key")
             cert-file("/opt/syslog-ng/etc/syslog-ng/cert.d/syslog-ng.cert")
             ca-dir("/opt/syslog-ng/etc/syslog-ng/ca.d")) ); };

    Caution:

    Do not forget to update the certificate and key files when they expire.

TLS options

The syslog-ng application can encrypt incoming and outgoing syslog message flows using TLS if you use the network() or syslog() drivers.

NOTE:

The format of the TLS connections used by syslog-ng is similar to using syslog-ng and stunnel, but the source IP information is not lost.

To encrypt connections, use the transport("tls") and tls() options in the source and destination statements.

The tls() option can include the following settings:

allow-compress()
Accepted values: yes | no
Default: no

Description: Enable on-the-wire compression in TLS communication. Note that this option must be enabled both on the server and the client side to have any effect. Enabling compression can significantly reduce the bandwidth required to transport the messages, but can slightly decrease the performance of syslog-ng PE, reducing the number of transferred messages during a given period.

ca-dir()
Accepted values: Directory name
Default: none

Description: Name of a directory, that contains a set of trusted CA certificates in PEM format. The CA certificate files have to be named after the 32-bit hash of the subject's name. This naming can be created using the c_rehash utility in openssl.

ca-dir-layout() (DEPRECATED)

Accepted values: sha1-based
Default: sha1-based

Description: The type of the hash used for the CA certificates. NOTE: This option is deprecated.

Caution:

If you are upgrading to syslog-ng PE version 6.x from a version earlier than 5.0, you must rehash the trusted CA certificates.

cert-file()
Accepted values: Filename
Default: none

Description: Name of a file, that contains an X.509 certificate (or a certificate chain) in PEM format, suitable as a TLS certificate, matching the private key. If the file contains a certificate chain, the file must begin with the certificate of the host, followed by the CA certificate that signed the certificate of the host, and any other signing CAs in order.

cert-subject()
Accepted values: string
Default: none

Description: Only available on Windows systems. The subject of the certificate you wish to use for authenticating the local endpoint of the TLS connection. If set, syslog-ng PE will retrieve the certificate that has the specified subject from the Local Computer > Personal certificate store. Therefore, if this option is used, first import the respective certificate and the corresponding private key to the appropriate certificate store as a .pfx file.

To get the format for the cert-subject() string right, check the certificate's subject first. Concatenate the different key-value pairs in the subject, going from bottom to top, omitting the keys and equals signs, and adding commas for newline characters.

In the example provided in Figure 10.2, “Getting details of the certificate subject for the cert-subject() string”, the cert-subject() string would look like this:

cert-subject("HU, Some-State, Budapest, Balabit, syslog-ng team, client")

Figure 10.2. Getting details of the certificate subject for the cert-subject() string

Getting details of the certificate subject for the cert-subject() string

cipher-suite()
Accepted values: Name of a cipher, or a colon-separated list
Default: aes-128-cbc

Description: Specifies the cipher, hash, and key-exchange algorithms used for the encryption, for example, ECDHE-ECDSA-AES256-SHA384. The list of available algorithms depends on the version of OpenSSL used to compile syslog-ng PE. To specify multiple ciphers, separate the cipher names with a colon, and enclose the list between double-quotes, for example:

cipher-suite("ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384")

The cipher-suite() option also determines the encryption protocol used in the connection: to disable SSLv3, use an algorithm that is available only in TLSv1.2, and that both the client and the server supports.

  • Supports TLS v1.2: ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-SHA384, ECDHE-ECDSA-AES256-SHA384, DH-DSS-AES256-GCM-SHA384, DHE-DSS-AES256-GCM-SHA384, DH-RSA-AES256-GCM-SHA384, DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES256-SHA256, DHE-DSS-AES256-SHA256, DH-RSA-AES256-SHA256, DH-DSS-AES256-SHA256, ADH-AES256-GCM-SHA384, ADH-AES256-SHA256, ECDH-RSA-AES256-GCM-SHA384, ECDH-ECDSA-AES256-GCM-SHA384, ECDH-RSA-AES256-SHA384, ECDH-ECDSA-AES256-SHA384, AES256-GCM-SHA384, AES256-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-SHA256, ECDHE-ECDSA-AES128-SHA256, DH-DSS-AES128-GCM-SHA256, DHE-DSS-AES128-GCM-SHA256, DH-RSA-AES128-GCM-SHA256, DHE-RSA-AES128-GCM-SHA256, DHE-RSA-AES128-SHA256, DHE-DSS-AES128-SHA256, DH-RSA-AES128-SHA256, DH-DSS-AES128-SHA256, ADH-AES128-GCM-SHA256, ADH-AES128-SHA256, ECDH-RSA-AES128-GCM-SHA256, ECDH-ECDSA-AES128-GCM-SHA256, ECDH-RSA-AES128-SHA256, ECDH-ECDSA-AES128-SHA256, AES128-GCM-SHA256, AES128-SHA256, NULL-SHA256

  • Supports SSL v3: ECDHE-RSA-AES256-SHA, ECDHE-ECDSA-AES256-SHA, SRP-DSS-AES-256-CBC-SHA, SRP-RSA-AES-256-CBC-SHA, SRP-AES-256-CBC-SHA, DHE-RSA-AES256-SHA, DHE-DSS-AES256-SHA, DH-RSA-AES256-SHA, DH-DSS-AES256-SHA, DHE-RSA-CAMELLIA256-SHA, DHE-DSS-CAMELLIA256-SHA, DH-RSA-CAMELLIA256-SHA, DH-DSS-CAMELLIA256-SHA, AECDH-AES256-SHA, ADH-AES256-SHA, ADH-CAMELLIA256-SHA, ECDH-RSA-AES256-SHA, ECDH-ECDSA-AES256-SHA, AES256-SHA, CAMELLIA256-SHA, PSK-AES256-CBC-SHA, ECDHE-RSA-AES128-SHA, ECDHE-ECDSA-AES128-SHA, SRP-DSS-AES-128-CBC-SHA, SRP-RSA-AES-128-CBC-SHA, SRP-AES-128-CBC-SHA, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA, DH-RSA-AES128-SHA, DH-DSS-AES128-SHA, DHE-RSA-SEED-SHA, DHE-DSS-SEED-SHA, DH-RSA-SEED-SHA, DH-DSS-SEED-SHA, DHE-RSA-CAMELLIA128-SHA, DHE-DSS-CAMELLIA128-SHA, DH-RSA-CAMELLIA128-SHA, DH-DSS-CAMELLIA128-SHA, AECDH-AES128-SHA, ADH-AES128-SHA, ADH-SEED-SHA, ADH-CAMELLIA128-SHA, ECDH-RSA-AES128-SHA, ECDH-ECDSA-AES128-SHA, AES128-SHA, SEED-SHA, CAMELLIA128-SHA, PSK-AES128-CBC-SHA, ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, RC4-SHA, RC4-MD5, PSK-RC4-SHA, ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, SRP-DSS-3DES-EDE-CBC-SHA, SRP-RSA-3DES-EDE-CBC-SHA, SRP-3DES-EDE-CBC-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, DES-CBC3-SHA, PSK-3DES-EDE-CBC-SHA, ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA, NULL-MD5

crl-dir()
Accepted values: Directory name
Default: none

Description: Name of a directory that contains the Certificate Revocation Lists for trusted CAs. Similarly to ca-dir() files, use the 32-bit hash of the name of the issuing CAs as filenames. The extension of the files must be .r0.

If the crl-dir() is set, and the peer certificate has been revoked, syslog-ng PE rejects the connection. If the peer certificate has not been revoked, or syslog-ng PE cannot access the CRL, syslog-ng PE accepts the connection.

curve-list()
Accepted values: string (colon-separated list)
Default: none

Description: A colon-separated list that specifies the curves that are permitted in the connection when using Elliptic Curve Cryptography (ECC). The syslog-ng PE application uses automatically the highest preference curve that both peers support. If not specified, the list includes every supported curve. For example:

curve-list('prime256v1:secp521r1')

The syslog-ng Premium Edition application currently supports the following curves: sect163k1, sect163r1, sect163r2, sect193r1, sect193r2,, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1,, sect409k1, sect409r1, sect571k1, sect571r1, secp160k1,, secp160r1, secp160r2, secp192k1, prime192v1, secp224k1,, secp224r1, secp256k1, prime256v1, secp384r1, secp521r1,, brainpoolP256r1, brainpoolP384r1, brainpoolP512r1.

dhparam-file()
Accepted values: string (filename)
Default: none

Description: Specifies a file containing Diffie-Hellman parameters, generated using the openssl dhparam utility. Note that syslog-ng PE supports only DH parameter files in the PEM format. If you do not set this parameter, syslog-ng PE uses the 2048-bit MODP Group, as described in RFC 3526.

key-file()
Accepted values: Filename
Default: none

Description: Name of a file, that contains an unencrypted private key in PEM format, suitable as a TLS key.

peer-verify()
Accepted values: optional-trusted | optional-untrusted | required-trusted | required-untrusted
Default: required-trusted

Description: Verification method of the peer, the four possible values is a combination of two properties of validation:

  • whether the peer is required to provide a certificate (required or optional prefix), and

  • whether the certificate provided needs to be valid or not.

The following table summarizes the possible options and their results depending on the certificate of the peer.

The remote peer has:
no certificate invalid certificate valid certificate
Local peer-verify() setting optional-untrusted TLS-encryption TLS-encryption TLS-encryption
optional-trusted TLS-encryption rejected connection TLS-encryption
required-untrusted rejected connection TLS-encryption TLS-encryption
required-trusted rejected connection rejected connection TLS-encryption

For untrusted certificates only the existence of the certificate is checked, but it does not have to be valid — syslog-ng accepts the certificate even if it is expired, signed by an unknown CA, or its CN and the name of the machine mismatches.

Caution:

When validating a certificate, the entire certificate chain must be valid, including the CA certificate. If any certificate of the chain is invalid, syslog-ng PE will reject the connection.

trusted-dn()
Accepted values: list of accepted distinguished names
Default: none

Description: To accept connections only from hosts using certain certificates signed by the trusted CAs, list the distinguished names of the accepted certificates in this parameter. For example using trusted-dn("*, O=Example Inc, ST=Some-State, C=*") will accept only certificates issued for the Example Inc organization in Some-State state.

trusted-keys()
Accepted values: list of accepted SHA-1 fingerprints
Default: none

Description: To accept connections only from hosts using certain certificates having specific SHA-1 fingerprints, list the fingerprints of the accepted certificates in this parameter. For example trusted-keys("SHA1:00:EF:ED:A4:CE:00:D1:14:A4:AB:43:00:EF:00:91:85:FF:89:28:8F", "SHA1:0C:42:00:3E:B2:60:36:64:00:E2:83:F0:80:46:AD:00:A8:9D:00:15").

To find the fingerprint of a certificate, you can use the following command: openssl x509 -in <certificate-filename> -sha1 -noout -fingerprint

NOTE:

When using the trusted-keys() and trusted-dn() parameters at the same time, note the following:

  • If the fingerprint of the peer is listed in the trusted-keys() parameter and the DN of the peer is listed in the trusted-dn() parameter, then the certificate validation is performed.

  • If either the fingerprint of the peer is not listed in the trusted-keys() parameter or the DN of the peer is not listed in the trusted-dn() parameter, then the authentication of the peer fails and the connection is closed.

Related Documents