TLS-encrypted message transfer

• 1: Secure logging using TLS
• 2: Encrypting log messages with TLS
• 2.1: Configuring TLS on the AxoSyslog clients
• 2.2: Configuring TLS on the AxoSyslog server
• 3: Mutual authentication using TLS
• 3.1: Configuring TLS on the AxoSyslog clients
• 3.2: Configuring TLS on the AxoSyslog server
• 4: Password-protected keys
• 5: TLS options

1 - Secure logging using TLS

The AxoSyslog 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:

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 AxoSyslog server that identifies the server.

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

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

• A certificate must be available on the AxoSyslog client. This certificate identifies the AxoSyslog client.

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

Mutual authentication ensures that the AxoSyslog server accepts log messages only from authorized clients.

For more information about configuring TLS communication, see Encrypting log messages with TLS.

For more information about TLS-related error messages, see Error messages.

2 - 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 Secure logging using TLS.

2.1 - Configuring TLS on the AxoSyslog clients

Purpose:

Complete the following steps on every AxoSyslog 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 AxoSyslog server (or the self-signed certificate of the AxoSyslog server) to the AxoSyslog 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.

   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

2. Add a destination statement to the syslog-ng.conf 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 AxoSyslog server.

   Example: A destination statement using TLS

   The following destination encrypts the log messages using TLS and sends them to the 6514/TCP port of the AxoSyslog 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.

   Warning

   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 AxoSyslog clients and relays) of the server.

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

2.2 - Configuring TLS on the AxoSyslog server

Purpose:

Complete the following steps on the AxoSyslog server:

Steps:

1. Create an X.509 certificate for the AxoSyslog 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.

2. Copy the certificate (for example, syslog-ng.cert) of the AxoSyslog server to the AxoSyslog 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.

3. Copy the private key (for example, syslog-ng.key) matching the certificate of the AxoSyslog server to the AxoSyslog server host, for example, into the /opt/syslog-ng/etc/syslog-ng/key.d directory. The key must be in PEM format. If you want to use a password-protected key, see Password-protected keys.

4. Add a source statement to the syslog-ng.conf 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 AxoSyslog client.

   Example: 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 AxoSyslog 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")
               )
           );
       };
   

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

   If you want to authenticate the clients, you have to configure mutual authentication. For details, see Mutual authentication using TLS.

   For the details of the available tls() options, see TLS options.

   Example: Disabling mutual authentication

   The following source receives log messages encrypted using TLS, arriving to the 1999/TCP port of any interface of the AxoSyslog server. The identity of the AxoSyslog 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)
               )
           );
       };
   

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

3 - Mutual authentication using TLS

This section describes how to configure mutual authentication between the AxoSyslog server and the client. Configuring mutual authentication is similar to configuring TLS (for details, see 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 Secure logging using TLS.

3.1 - Configuring TLS on the AxoSyslog clients

Purpose:

Complete the following steps on every AxoSyslog 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 AxoSyslog client.

2. Copy the certificate (for example, client_cert.pem) and the matching private key (for example, client.key) to the AxoSyslog 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. If you want to use a password-protected key, see Password-protected keys.

3. Copy the CA certificate of the Certificate Authority (for example, cacert.pem) that issued the certificate of the AxoSyslog server (or the self-signed certificate of the syslog-ng server) to the AxoSyslog 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.

   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

4. Add a destination statement to the syslog-ng.conf 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 AxoSyslog server. Include the client’s certificate and private key in the tls() options.

   Example: 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 AxoSyslog 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.

   Warning

   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 match the hostname or the IP address (as resolved from the AxoSyslog clients and relays) of the server.

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

3.2 - Configuring TLS on the AxoSyslog server

Purpose:

Complete the following steps on the AxoSyslog server:

Steps:

1. Copy the certificate (for example, syslog-ng.cert) of the AxoSyslog server to the AxoSyslog 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 AxoSyslog clients to the AxoSyslog 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.

   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

3. Copy the private key (for example, syslog-ng.key) matching the certificate of the AxoSyslog server to the AxoSyslog server host, for example, into the /opt/syslog-ng/etc/syslog-ng/key.d directory. The key must be in PEM format. If you want to use a password-protected key, see Password-protected keys.

4. Add a source statement to the syslog-ng.conf 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 TLS options.

   Example: 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 AxoSyslog 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")        
               )
           );
       };
   

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

4 - Password-protected keys

Starting with AxoSyslog version 3.14, you can use password-protected private keys in the network() and syslog() source and destination drivers.

Restrictions and limitations

• Note Hazard of data loss! If you use password-protected keys, you must provide the passphrase of the password-protected keys every time AxoSyslog is restarted (AxoSyslog keeps the passphrases over reloads). The sources and destinations that use these keys will not work until you provide the passwords. Other parts of the AxoSyslog configuration will be unaffected.

  This means that if you use a password-protected key in a destination, and you use this destination in a log path that has multiple destinations, neither destinations will receive log messages until you provide the password. In this cases, always use disk-based buffering to avoid data loss.

• The path and the filename of the private key cannot contain whitespaces.

• Depending on your platform, the number of passwords AxoSyslog can use at the same time might be limited (for example, on Ubuntu 16.04 you can store 16 passwords if you are running AxoSyslog as a non-root user). If you use lots of password-protected private keys in your AxoSyslog configuration, increase this limit using the following command: sudo ulimit -l unlimited

Providing the passwords

The syslog-ng-ctl credentials status command allows you to query the status of the private keys that AxoSyslog uses in the network() and syslog() drivers. The command returns the list of private keys used, and their status. For example:

   syslog-ng-ctl credentials status
    Secret store status:
    /home/user/ssl_test/client-1/client-encrypted.key SUCCESS

If the status of a key is PENDING, you must provide the passphrase for the key, otherwise AxoSyslog cannot use it. The sources and destinations that use these keys will not work until you provide the passwords. Other parts of the AxoSyslog configuration will be unaffected. You must provide the passphrase of the password-protected keys every time AxoSyslog is restarted.

The following log message also notifies you of PENDING passphrases:

   Waiting for password; keyfile='private.key'

You can add the passphrase to a password-protected private key file using the following command. AxoSyslog will display a prompt for you to enter the passphrase. We recommend that you use this method.

   syslog-ng-ctl credentials add --id=<path-to-the-key>

Alternatively, you can include the passphrase in the --secret parameter:

   syslog-ng-ctl credentials add --id=<path-to-the-key> --secret=<passphrase-of-the-key>

Or you can pipe the passphrase to the syslog-ng-ctl command, for example:

   echo "<passphrase-of-the-key>" | syslog-ng-ctl credentials add --id=<path-to-the-key>

For details on the syslog-ng-ctl credentials command, see The syslog-ng control tool manual page.

5 - TLS options

This page describes the TLS-related options of the network() and syslog() drivers. Where applicable, other drivers also support encrypted transport, see the documentation of the other drivers for details.

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()

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

Available in version 3.19 and later.

ca-dir()

Description: The 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. For an example, see Configuring TLS on the AxoSyslog clients. The AxoSyslog application uses the CA certificates in this directory to validate the certificate of the peer.

This option can be used together with the optional ca-file() option.

ca-file()

Description: Optional. The name of a file that contains a set of trusted CA certificates in PEM format. The AxoSyslog application uses the CA certificates in this file to validate the certificate of the peer.

Example format in configuration:

   ca-file("/etc/pki/tls/certs/ca-bundle.crt")

cert-file()

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 set in the key-file() option. The AxoSyslog application uses this certificate to authenticate the AxoSyslog client on the destination server. 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.

cipher-suite()

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 AxoSyslog. 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")

For a list of available algorithms, execute the openssl ciphers -v command. The first column of the output contains the name of the algorithms to use in the cipher-suite() option, the second column specifies which encryption protocol uses the algorithm (for example, TLSv1.2). That way, the cipher-suite() 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. You can also specify the encryption protocols using ssl-options().

You can also use the following command to automatically list only ciphers permitted in a specific encryption protocol, for example, TLSv1.2:

   echo "cipher-suite(\"$(openssl ciphers -v | grep TLSv1.2 | awk '{print $1}' | xargs echo -n | sed 's/ /:/g' | sed -e 's/:$//')\")"

Note that starting with version 3.10, when AxoSyslog receives TLS-encrypted connections, the order of ciphers set on the AxoSyslog server takes precedence over the client settings.

client-sigalgs()

Description: A colon-separated list that specifies the supported signature algorithms associated with client authentication for TLSv1.2 and higher, for example, RSA-PSS+SHA256:ed25519.

• For servers, the value is used in the signature_algorithms field of a CertificateRequest message.
• For clients, it is used to determine which signature algorithm to use with the client certificate.

If client-sigalgs() is not set but sigalgs() is, then the values of sigalgs() are used.

crl-dir()

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.

dhparam-file()

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

ecdh-curve-list()

Description: A colon-separated list that specifies the curves that are permitted in the connection when using Elliptic Curve Cryptography (ECC).

This option is only available when syslog-ng is compiled with OpenSSL version 1.0.2 or later. In the case of older versions, prime256v1 (NIST P-256) is used.

The following example curves work for all versions of OpenSSL that are equal to or later than version 1.0.2:

   ecdh-curve-list("prime256v1:secp384r1")

key-file()

Description: The name of a file that contains an unencrypted private key in PEM format, suitable as a TLS key. If properly configured, the AxoSyslog application uses this private key and the matching certificate (set in the cert-file() option) to authenticate the AxoSyslog client on the destination server.

keylog-file()

Description: This option enables saving TLS secrets (decryption keys) for a given source or destination, which can be used to decrypt data with, for example, Wireshark. The given path and name of a file will be used to save these secrets.

This option is only available with the following drivers:

• network

• syslog

• tcp

• tcp6

ocsp-stapling-verify

Available in AxoSyslog 4.0 and later.

Description: When OCSP stapling verification is enabled, AxoSyslog requests the server to send back its OCSP status. AxoSyslog verifies this status response using the trust store you have configured using the ca-file(), ca-dir(), or the pkcs12-file() options.

Example configuration:

destination {

    network("example.com" transport(tls)
        tls(
            pkcs12-file("/path/to/test.p12")
            peer-verify(yes)
            ocsp-stapling-verify(yes)
        )
    );
};

openssl-conf-cmds()

Available in AxoSyslog version 4.0 and later.

IMPORTANT: openssl-conf-cmds() always has the highest priority, so it overrides any other options that can be found in the tls() section.

OpenSSL offers an alternative, software-independent configuration mechanism through the SSL_CONF_cmd interface for setting the various SSL_CTX and SSL options.

The order of operations within openssl-conf-cmds() is significant and the commands are executed in top-down order. This means that if the same option occurs multiple times, then the ’last one wins’. This is also true for options that can be set multiple ways (for example, cipher suites or protocols).

Example configuration:

tls(
    ca-dir("/etc/ca.d")
    key-file("/etc/cert.d/serverkey.pem")
    cert-file("/etc/cert.d/servercert.pem")
    peer-verify(yes)

    openssl-conf-cmds(
        # For system wide available cipher suites use: /usr/bin/openssl ciphers -v
        # For formatting rules see: https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
        "CipherString" => "ECDHE-RSA-AES128-SHA",                                   # TLSv1.2 and bellow
        "CipherSuites" => "TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384",    # TLSv1.3+ (OpenSSl 1.1.1+)

        "Options" => "PrioritizeChaCha",
        "Protocol" => "-ALL,TLSv1.3",
    )
)

peer-verify()

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).
• 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.

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

Starting with AxoSyslog version 3.10, you can also use a simplified configuration method for the peer-verify option, simply setting it to yes or no. The following table summarizes the possible options and their results depending on the certificate of the peer.

pkcs12-file()

Description: The name of a PKCS #12 file that contains an unencrypted private key, an X.509 certificate, and an optional set of trusted CA certificates.

If this option is used in the configuration, the value of key-file() and cert-file() will be omitted.

You can use the ca-dir() option together with pkcs12-file(). However, this is optional because the PKCS #12 file may contain CA certificates as well.

Passphrase is currently not supported.

Example: Using pkcs12-file()

In the following example, the first command creates a single PKCS #12 file from the private key, X.509 certificate, and CA certificate files. Then, the second half of the example uses the same PKCS #12 file in the AxoSyslog configuration.

openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca.crt -out server.p12

Example configuration:

   source s_tls {
        syslog(
            transport(tls)
            tls(
                pkcs12-file("/path/to/server.p12")
                ca-dir("/path/to/cadir") # optional
                peer-verify(yes)
            )
        );
    };

sigalgs()

Description: A colon-separated list that specifies the supported signature algorithms (in order of decreasing preference) for TLSv1.2 and higher, for example, RSA-PSS+SHA256:ed25519. If this option is not set then all supported signature algorithms supported are permissible.

• For servers, it is used to determine which signature algorithms to support.
• For clients, this value is used directly for the supported signature algorithms extension.

sni()

Description: When set to yes in a destination that uses TLS encryption, this option enables Server Name Indication (also called Server Name Identification, SNI). The AxoSyslog sends the hostname or the IP address set in the destination to the server during the TLS handshake.

Available in AxoSyslog 3.24 and newer.

Example: Using Server Name Indication

The following destination sends the hostname of its destination during the TLS handshake.

   destination demo_tls_destination_with_sni {
        network(
             "logserver.example.com" port(6514)
            transport("tls")
            tls(
                ca_dir("/etc/syslog-ng/ca.d")
                key-file("/etc/syslog-ng/cert.d/clientkey.pem")
                cert-file("/etc/syslog-ng/cert.d/clientcert.pem")
                sni(yes)
            )
        );
    };

ssl-options()

Available in AxoSyslog 3.7 and newer.

Description: Sets the specified options of the SSL/TLS protocols. You can use it to disable specific protocol versions, and set other options. Note that disabling a newer protocol version (for example, TLSv1.1) does not automatically disable older versions of the same protocol (for example, TLSv1.0). For example, use the following option to permit using only TLSv1.1 or newer:

   ssl-options(no-sslv2, no-sslv3, no-tlsv1)

Using ssl-options(none) means that AxoSyslog does not specify any restrictions on the protocol used. However, in this case, the underlying OpenSSL library can restrict the available protocols, for example, certain OpenSSL versions automatically disable SSLv2.

By specifying ignore-hostname-mismatch, you can ignore the subject name of a certificate during the validation process. This means that AxoSyslog checks only that the certificate itself is trusted by the current set of trust anchors (e.g. trusted CAs), and ignores the mismatch between the targeted hostname and the certificate subject. ignore-hostname-mismatch is available in AxoSyslog 4.4 and newer.

By specifying ignore-validity-period, you can ignore the you can ignore the validity periods of certificates during the certificate validation process. ignore-validity-period is available in AxoSyslog 4.5 and newer.

Example: Using ssl-options

The following destination explicitly disables SSL and TLSv1.0

   destination demo_tls_destination {
        network(
             "172.16.177.147" port(6514)
            transport("tls")
            tls(
                ca_dir("/etc/syslog-ng/ca.d")
                key-file("/etc/syslog-ng/cert.d/clientkey.pem")
                cert-file("/etc/syslog-ng/cert.d/clientcert.pem")
                ssl-options(no-sslv2, no-sslv3, no-tlsv1)
            )
        );
    };

ssl-version()

Available in AxoSyslog version 4.5.0 and later.

Description: Specifies the permitted SSL/TLS version. Possible values: sslv2, sslv3, tlsv1, tlsv1_0, tlsv1_1, tlsv1_2, tlsv1_3.

trusted-dn()

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()

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

Starting with version 4.8.1, if trusted-keys() is set, AxoSyslog automatically adds the key fingerprint of the peer to the ${.tls.x509_fp} name-value pair.