---
title: "TLS options"
url: "https://axoflow.com/docs/axosyslog-core/4.28/chapter-encrypted-transport-tls/tlsoptions/"
last_modified: "2026-07-10T14:00:08+02:00"
---

> For the complete documentation index, see [llms.txt](https://axoflow.com/docs/axosyslog-core/4.28/llms.txt).

# 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.

> **Note:**
> The format of the TLS connections used by AxoSyslog is similar to using AxoSyslog 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` or `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 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()

|  |  |
| --- | --- |
| Accepted values: | Directory name |
| Default: | none |

*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 server authentication on the AxoSyslog clients](https://axoflow.com/docs/axosyslog-core/4.28/chapter-encrypted-transport-tls/tls-serverauth/procedure-configuring-tls-client/index.md). 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()

|  |  |
| --- | --- |
| Accepted values: | File name |
| Default: | empty |

*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:

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

> **Note:**
> The `ca-file()` option can be used together with the `ca-dir()` option, and it is relevant when `peer-verify()` is set to other than `no` or `optional-untrusted`.

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

|  |  |
| --- | --- |
| Accepted values: | Name of a cipher, or a colon-separated list |
| Default: | Depends on the OpenSSL version that AxoSyslog uses |

*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:

```shell
   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()](https://axoflow.com/docs/axosyslog-core/4.28/chapter-encrypted-transport-tls/tlsoptions/index.md).

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

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

|  |  |
| --- | --- |
| Accepted values: | string [colon-separated list] |
| Default: | none |

*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()`](https://axoflow.com/docs/axosyslog-core/4.28/chapter-encrypted-transport-tls/tlsoptions/index.md#tls-options-sigalgs) are used.

## 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`.

## dhparam-file()

|  |  |
| --- | --- |
| Accepted values: | string (filename) |
| Default: | none |

*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](https://www.ietf.org/rfc/rfc3526.txt).

## ecdh-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).

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:

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

## extended-key-usage-verify()

|  |  |
| --- | --- |
| Accepted values: | `yes`, `no` |
| Default: | `no` |

Available in AxoSyslog 4.23 and later.

*Description:* If enabled, AxoSyslog checks that the certificate of the peer contains the appropriate value in its Extended Key Usage (EKU) field: clients should have Client Auth EKU values (`X509_PURPOSE_SSL_CLIENT`), while server should have Web Server Auth (`X509_PURPOSE_SSL_SERVER`).

If `extended-key-usage-verify()` is set to `yes` and the certificate of the peer doesn’t have the appropriate Extended Key Usage value, AxoSyslog terminates the connection.

## key-file()

|  |  |
| --- | --- |
| Accepted values: | Filename |
| Default: | none |

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

|  |  |
| --- | --- |
| Accepted values: | Filename |
| Default: | N/A |

*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

> **Warning:**
> Using `keylog-file()` makes TLS connections less secure by writing secret key materials into the given file. This option should only be enabled for debugging purposes and should be disabled after that. It is also recommended to delete the file after the debugging session is over.

## ocsp-stapling-verify

|  |  |
| --- | --- |
| Accepted values: | `yes`, `no` |
| Default: | `no` |

Available in AxoSyslog 4.0 and later.

*Description:* When [OCSP stapling verification](https://en.wikipedia.org/wiki/OCSP_stapling) 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.

> **Note:**
> RFC 6961 multi-stapling and TLS 1.3-provided multiple responses are currently not validated, only the peer certificate is verified.

Example configuration:

```shell
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](https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html) 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:

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

|  |  |
| --- | --- |
| Accepted values: | `optional-trusted` , `optional-untrusted` , `required-trusted` , `required-untrusted` , `yes` , `no` |
| 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).
- 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 — AxoSyslog accepts the certificate even if it is expired, signed by an unknown CA, or its CN and the name of the machine mismatches.

> **Warning:**
> When validating a certificate, the entire certificate chain must be valid, including the CA certificate. If any certificate of the chain is invalid, AxoSyslog will reject the connection.

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.

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

## pkcs12-file()

|  |  |
| --- | --- |
| Accepted values: | Filename |
| Default: | none |

*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.

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

Example configuration:

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

## sigalgs()

|  |  |
| --- | --- |
| Accepted values: | string [colon-separated list] |
| Default: | none |

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

|  |  |
| --- | --- |
| Accepted values: | `yes` or `no` |
| Default: | `no` |

*Description:* When set to `yes` in a destination that uses TLS encryption, this option enables [Server Name Indication](https://tools.ietf.org/html/rfc6066#page-6) (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.

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

|  |  |
| --- | --- |
| Accepted values: | comma-separated list of the following options: `no-sslv2`, `no-sslv3`, `no-tlsv1`, `no-tlsv11`, `no-tlsv12`, `no-tlsv13`, `none`, `ignore-hostname-mismatch`, `ignore-validity-period` |
| Default: | no-sslv2 |

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:

```shell
   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

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

|  |  |
| --- | --- |
| Type: | string |
| Default: | None, uses the libcurl default |

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

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

|  |  |
| --- | --- |
| Accepted values: | list of accepted fingerprints |
| Default: | none |

Available in AxoSyslog version 4.26.0 and later.

*Description:* To accept connections only from hosts using certain certificates having specific fingerprints, list the fingerprints of the accepted certificates in this parameter. for example:

```shell
trusted-fingerprints("SHA1:0C:EF:34:4D:0B:74:AE:03:72:9A:4E:68:AF:90:59:A9:EF:35:1F:AA",
 "SHA512:15:B3:C5:96:48:5B:F6:20:C3:86:47:78:99:E1:2B:F2:C4:A6:93:AE:E8:0A:B3:F7:78:39:66:B4:EF:4F:A5:47:2A:E0:4A:93:06:46:72:C0:15:6A:FC:59:10:25:37:60:E3:84:E9:EC:90:30:12:F5:27:EA:22:1F:55:9B:3B:97")
```

**CAUTION:**

If the fingerprint of the peer is listed in `trusted-fingerprints()`, AxoSyslog accepts the certificate even if it’s not valid.

To create the `trusted-fingerprints` string of a certificate:

1. Find the fingerprint of a certificate, for example, using the following command:

   ```shell
   openssl x509 -sha512 -in <certificate file in pem> -fingerprint -noout
   ```

   Sample output:

   ```shell
   sha512 Fingerprint=27:42:63:34:F5:56:63:2B:AD:8F:BD:AD:29:17:94:7E:CB:17:7F:40:A2:FB:36:C1:4C:BA:6C:A7:E1:1C:A5:EE:79:E5:01:17:F2:98:F7:25:C9:FC:01:50:64:AB:5B:6C:D4:44:60:1F:5A:9F:BC:0A:E6:0A:15:16:74:21:9E:A9
   ```
2. Replace the  `Fingerprint=` part with a colon (`:`), for example: `sha512:27:42:63:34:F5:56:63:2B:AD:8F:BD:AD:29:17:94:7E:CB:17:7F:40:A2:FB:36:C1:4C:BA:6C:A7:E1:1C:A5:EE:79:E5:01:17:F2:98:F7:25:C9:FC:01:50:64:AB:5B:6C:D4:44:60:1F:5A:9F:BC:0A:E6:0A:15:16:74:21:9E:A9`

   The fingerprinting method is the word before the first colon. The name of the fingerprinting methods must match an OpenSSL-supported digest algorithm, which are (for OpenSSL 3.0.10): `blake2b512, blake2s256, md4, md5, rmd160, sha1, sha224, sha256, sha3-224, sha3-256, sha3-384, sha3-512, sha384, sha512, sha512-224, sha512-256, shake128, shake256, sm3`

> **Note:**
>
> When using the `trusted-fingerprints()` and `trusted-dn()` parameters, note the following:
>
> - First, the `trusted-fingerprints()` parameter is checked. If the fingerprint of the peer is listed, the certificate validation is skipped.
> - If the fingerprint of the peer is not listed in the `trusted-fingerprints()` parameter, the `trusted-dn()` parameter is checked. If the DN of the peer is not listed in the `trusted-dn()` parameter, the authentication of the peer fails and the connection is closed.

AxoSyslog automatically adds the fingerprint of the peer to the [`${.tls.x509_fp}`](https://axoflow.com/docs/axosyslog-core/4.28/chapter-manipulating-messages/customizing-message-format/reference-macros/index.md#macro-tls-x509) name-value pair.

## trusted-keys() (DEPRECATED)

|  |  |
| --- | --- |
| Accepted values: | list of accepted SHA-1 fingerprints |
| Default: | none |

Deprecated in AxoSyslog version 4.26.0. Use [`trusted-fingerprints()`](https://axoflow.com/docs/axosyslog-core/4.28/chapter-encrypted-transport-tls/tlsoptions/index.md#tls-options-trusted-fingerprints) instead.

*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, note the following:
>
> - First, the `trusted-keys()` parameter is checked. If the fingerprint of the peer is listed, the certificate validation is performed.
> - If the fingerprint of the peer is not listed in the `trusted-keys()` parameter, the `trusted-dn()` parameter is checked. If the DN of the peer is not listed in the `trusted-dn()` parameter, the authentication of the peer fails and the connection is closed.

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.

Last modified July 10, 2026: [Include tls option descriptions in grpc auth(tls()) (1b8456e3)](https://github.com/axoflow/axosyslog-core-docs/commit/1b8456e31751a5bb521b2c1fb264197960cd77f2)