TLS/SSL (om_ssl)
This module uses the OpenSSL library to send data over a secure TLS/SSL connection. It works like the TCP output module, but performs a TLS/SSL handshake at connection time and encrypts data in transit. Use this module instead of the TCP output module when you need to protect data from eavesdropping or tampering in transit.
| To examine the supported platforms, see the list of installation packages. |
Configuration
The om_ssl module accepts the following directives in addition to the common module directives.
Required directives
The following directive is required for the module to start.
Set this directive to the IP address or hostname of the remote host to connect to. If you specify a hostname, the module resolves it to an IP address on each new connection. The module uses port 514 by default.
To connect to a different port, add the port number after the IP address or hostname, separated by a colon ( Enclose IPv6 addresses in square brackets ( You can set this directive more than once to allow failover between different hosts or ports. List IPv4 and IPv6 addresses separately if needed. If you use a DNS name, make sure it resolves to fewer than 16 addresses or CNAMEs to prevent problems with DNS response size limits.
|
TLS/SSL directives
The following directives configure secure data transfer via TLS/SSL.
Set this directive to |
||||||||||||||||
Set this directive to |
||||||||||||||||
Set this directive to |
||||||||||||||||
Set this directive to the path of a directory containing Certificate Authority (CA) certificates.
The module uses these certificates to verify the certificate presented by the remote host.
Name the certificate files using the OpenSSL hashed format: the hash of the certificate followed by
For example, if the certificate hash is To trust a remote host’s self-signed certificate, include a copy of it in this directory. If this directive isn’t specified, NXLog Agent falls back to the default operating system root certificate store.
Unix-like operating systems commonly store root certificates in In addition, Microsoft’s PKI repository contains root certificates for Microsoft services. This directive is mutually exclusive with the CAThumbprint, CAPattern, and SearchAllCertStores directives. |
||||||||||||||||
Set this directive to the path of the Certificate Authority (CA) certificate used to verify the certificate presented by the remote host. To trust a remote host’s self-signed certificate, specify the remote host’s certificate itself. For certificates signed by an intermediate CA, the specified certificate must contain the complete certificate chain (certificate bundle). This directive is mutually exclusive with the CAThumbprint, CAPattern, and SearchAllCertStores directives. |
||||||||||||||||
Set this directive to a PCRE2-compliant regular expression to locate a suitable Certificate Authority (CA) certificate. This directive is supported on Windows and macOS. On Windows, the certificate must be in the Windows Certificate Store. On macOS, the certificate must be in the system keychain. NXLog Agent matches the pattern against a string built from the certificate’s fields in this order:
The pattern doesn’t need to match every field.
Include only the fields you want to match, and use For example, the following pattern matches only the
This produces the following output in the NXLog Agent log file:
If the pattern matches multiple certificates, NXLog Agent uses the first match. If the certificate changes, restart NXLog Agent to apply the new certificate. This directive is mutually exclusive with the CAThumbprint, CADir, CAFile, and SearchAllCertStores directives.
|
||||||||||||||||
Set this directive to the thumbprint of the Certificate Authority (CA) certificate used to verify the certificate presented by the remote host. This directive is supported on Windows and macOS. On Windows, copy the hexadecimal fingerprint string from Windows Certificate Manager (certmgr.msc). The certificate must be in a Windows certificate store accessible by NXLog Agent. On macOS, obtain the hexadecimal fingerprint string from the Keychain Access application. The certificate must be accessible in the system keychain. Whitespaces and colons are automatically removed. This directive is mutually exclusive with the CADir, CAFile, CAPattern, and SearchAllCertStores directives.
|
||||||||||||||||
Set this directive to the path of the certificate file to present to the remote host during the TLS/SSL handshake. |
||||||||||||||||
Set this directive to the path of the private key file corresponding to the certificate specified by CertFile. |
||||||||||||||||
Set this directive to a PCRE2-compliant pattern to identify the certificate and its corresponding private key. This directive is supported on Windows and macOS. NXLog Agent matches the pattern against a string built from the certificate’s fields in this order:
The pattern doesn’t need to match every field.
Include only the fields you want to match, and use On Windows, import the certificate in PFX format into the On macOS, ensure the certificate and its private key are present in the System Keychain ( If the pattern matches multiple certificates, NXLog Agent uses the first match. If the certificate changes, restart NXLog Agent to apply the new certificate. This directive is mutually exclusive with the CertThumbprint, CertFile and CertKeyFile directives. For example:
or
This produces the following output in the NXLog Agent log file:
|
||||||||||||||||
Set this directive to the thumbprint of the certificate to present to the remote server during the TLS/SSL handshake. Whitespaces and colons are automatically removed. This directive is supported on Windows and macOS.
On Windows, copy the hexadecimal fingerprint string from Windows Certificate Manager (certmgr.msc).
Import the certificate to the
When the global directive UseCNGCertificates is set to
When UseCNGCertificates is set to On macOS, obtain the hexadecimal fingerprint string from the Keychain Access application.
The certificate and its associated private key must be present in the System Keychain ( For example:
This directive is mutually exclusive with the CertFile and CertKeyFile directives.
|
||||||||||||||||
Set this directive to the path of a directory containing certificate revocation list (CRL) files.
The module uses these files to reject connections from hosts presenting a revoked certificate.
Name the files using the OpenSSL hashed format: the hash of the issuer followed by
For example, if the hash is |
||||||||||||||||
Set this directive to the path of the certificate revocation list (CRL) file used to reject connections from hosts presenting a revoked certificate. To generate a CRL file using OpenSSL:
|
||||||||||||||||
Set this directive to the path of a file containing Diffie-Hellman parameters for key exchange. Generate the parameters using dhparam(1ssl). If this directive is not set, the module uses default parameters. See the OpenSSL Wiki for further details. |
||||||||||||||||
Set this directive to the passphrase of the private key specified by CertKeyFile. This directive applies only to encrypted private keys. To generate a private key with Triple DES encryption using OpenSSL:
|
||||||||||||||||
Set this directive to This directive is only supported on Windows. |
||||||||||||||||
Set this directive to |
||||||||||||||||
Set this directive to |
||||||||||||||||
Set this directive to the signature algorithm parameter to pass to the Windows SSL library. Accepted values depend on the available encryption providers. This directive is only supported on Windows. |
||||||||||||||||
Set this directive to the hostname to use for Server Name Indication (SNI). If not set, the module uses the hostname specified in Host. |
||||||||||||||||
Set this directive to override the permitted cipher list for TLSv1.2 and below.
Use the format described in the ciphers(1ssl) man page.
For example, specify
|
||||||||||||||||
Set this directive to override the permitted cipher list for TLSv1.3. Use the same format as SSLCipher. Refer to the OpenSSL documentation for a list of valid TLS v1.3 cipher suites. The default is:
|
||||||||||||||||
Set this directive to
|
||||||||||||||||
Set this directive to restrict the TLS/SSL protocols the module accepts.
Specify a comma-separated list of the following values: |
||||||||||||||||
Set this directive to |
||||||||||||||||
Set this directive to This directive depends on the values of the AllowUntrusted and RequireCert directives:
|
||||||||||||||||
Set this directive to |
Optional directives
Set this directive to the local port number to use for the connection, for example to satisfy a firewall rule that expects traffic from a known port. If you do not set this directive, the module uses a random high port number, which a firewall may block.
|
|||
Set this directive to specify how the module formats output records. See the common OutputType directive for the available values, including support for data converters. The default is LineBased_LF, terminating each record with LF. |
|||
Set this directive to the number of seconds to wait between reconnection attempts. If you do not set this directive, the module starts with a 1 second interval and doubles it after each failed attempt, resetting to 1 second once it reconnects successfully.
|
|||
Set this directive to |
|||
Set this directive to |
|||
Set this directive to
The default is |
Procedures
The following procedures are exported by om_ssl.
-
reconnect(); -
Forces a reconnection to the server. For example, you can call this procedure from a Schedule block to reconnect periodically.
Avoid calling this procedure for every record the module processes. Doing so forces a reconnection each time, potentially overloading the destination.
Examples
The following is a basic configuration that sends data over a secure connection. If the connection to the first Host fails, the module fails over to the next one.
<Output ssl>
Module om_ssl
Host 192.168.1.2:1514
Host 192.168.1.3:1514
Host example.com:1234
CAFile %CERTDIR%/ca.pem
CertFile %CERTDIR%/agent-cert.pem
CertKeyFile %CERTDIR%/agent-key.pem
</Output>