| |
The eloqsd server is primarily intended to support the execution
of Eloquence applications.
In addition, the eloqsd server may be used to launch background
programs, using various clients such as Eloquence JDLG and WebDLG.
The eloqsd server was enhanced to support IPv6.
As a consequence, IPv6 addresses are accepted
in the configuration (enclosed in square brackets). Also, the eloqsd
configuration allows to selectively enable IPv4 and
IPv6 support.
To enhance the reach of Eloquence applications in the cloud or through
the Internet, the eloqsd server now supports secure TLS-encrypted
communication.
This way, JDLG 2.0
can use secure eloqsd and DLG communication over insecure (wide area
Internet) connections.
JDLG 2.0
provides the new tls
application configuration attribute. If enabled, network communication
between JDLG and the eloqsd server is TLS-encrypted.
In addition, if the
rdlg protocol
is configured, the DLG communication between JDLG and the application is
TLS-encrypted as well.
JDLG application configuration example (INI file format):
[APP1]
name = Application 1
server = 192.168.77.88
protocol = rdlg
tls = 1
command = APP1,APPS
This requires that the Eloquence B.08.30 eloqsd is started on the specified
server system. The eloqsd server is expected to have TLS configured and
enabled (see below). Otherwise the configured
application cannot be launched.
See also:
eloqsd.app configuration
JDLG application configuration
The eloqsd server may be configured to accept TLS-encrypted network
connections. JDLG
2.0 can use this to securely communicate over insecure network
(wide area Internet) connections.
In addition, the HTTPS status can be used.
To use TLS communication, a server certificate is needed for the eloqsd
host name. JDLG and web browsers require a certificate which is issued
by a known authority. In particular, the associated root certificate
must be contained in the Java truststore / web browser cert store.
Using TLS requires that OpenSSL version 0.9.8 or newer is installed.
The [TLS] section was added to the eloqsd.cfg
configuration file.
-
[TLS] Enabled
-
If nonzero, TLS communication is enabled and the other configuration
items in the [TLS] section are read.
The default value is 0 (TLS communication disabled).
-
[TLS] CertChainFile
-
Absolute path to a file in PEM format containing the server certificate
and optionally any additional intermediate certificates which represent
the verification chain up to the root certificate.
The certificates in this file must be sorted in the verification order,
starting with the server certificate.
The file may in addition contain the private key associated with the
server certificate, in which case the CertKeyFile configuration
below can be omitted.
For additional information, please refer to the section about
how to obtain the TLS CertChainFile.
-
[TLS] CertKeyFile
-
Absolute path to a file in PEM format containing the private key associated
with the server certificate.
If this key is contained in the CertChainFile above, configuring
CertKeyFile is not necessary.
-
[TLS] RequiredFrom and OptionalFrom
-
RequiredFrom is used to configure client network addresses which
are required to use secure TLS communication.
Note: This does not affect the HTTPS status.
If RequiredFrom is configured, OptionalFrom may be used to
configure exceptions for client addresses within the RequiredFrom
address range(s) which are not required to use secure TLS communication.
For example:
RequiredFrom = All
OptionalFrom = [::1]
OptionalFrom = 127.0.0.1
OptionalFrom = 192.168.1.0/24
RequiredFrom / OptionalFrom argument syntax:
{ All | hostname | ip-address [/{addrbits|netmask}] }
-
Multiple RequiredFrom / OptionalFrom entries are
recognized and combined.
-
hostname is the name of a host or network that is resolved into one
or more ip addresses.
-
ip-address is either an IPv4 or IPv6 address.
-
An IPv6 address, enclosed in square brackets,
such as [::1]. The addrbits option may be used to specify the number
of relevant bits in the IP address.
-
An IPv4 address, such as 127.0.0.1. The addrbits option may be used
to specify the number of relevant bits in the IP address.
The netmask option allows to specify an IPv4 network mask, such as
255.255.255.0.
See also:
eloqsd.cfg configuration
The eloqsd server was enhanced to support IPv6.
The configuration allows to specify how the eloqsd server should listen
for incoming IPv4 and/or IPv6 requests.
In addition, the HTTP status now supports the HTTPS (secure HTTP) protocol.
The configuration allows to specify whether the HTTP or HTTPS protocols
or both are accepted. Using the HTTPS protocol requires that TLS is configured
(see above).
The [Config] section of the eloqsd.cfg configuration file
has the following configuration changes:
-
[Config] Service
-
The service name (as defined in /etc/services) or the port number where
the server should listen for requests. The default value is eloqsd.
A suffix /4, /6, or /46 may be used for establishing IPv4 only,
IPv6 (with implied IPv4) or separate IPv4
and IPv6 listening sockets.
By default, separate IPv4 and IPv6 sockets are
used.
For example: eloqsd/46
-
[Config] ServiceHttp
-
The service name (as defined in /etc/services) or the port number where
the server should listen for HTTP requests.
If neither ServiceHttp nor ServiceHttps are specified, the HTTP/HTTPS
status is disabled.
A suffix /4, /6, or /46 may be used (see Service above).
-
[Config] ServiceHttps
-
The service name (as defined in /etc/services) or the port number where
the server should listen for HTTPS (secure HTTP) requests.
This requires that TLS is configured (see above).
If neither ServiceHttp nor ServiceHttps are specified, the HTTP/HTTPS
status is disabled.
A suffix /4, /6, or /46 may be used (see Service above).
See also:
eloqsd.cfg configuration
The AllowFrom and DenyFrom configuration items are
used in the eloqsd.share and eloqsd.app configuration files to
specify share and application access rules.
They now support IPv6 addresses and host names.
Eloqsd supports host names that resolve to multiple IP addresses
which could be either IPv4 or IPv6.
Any IPv4 addresses also apply to mapped IPv4 access using
IPv6 sockets.
-
AllowFrom and DenyFrom
-
Used to enable or reject access to a share or application
based on the client network address.
AllowFrom / DenyFrom argument syntax:
{ All | hostname | ip-address [/{addrbits|netmask}] }
-
Multiple AllowFrom / DenyFrom entries are
recognized and combined.
-
hostname is the name of a host or network that is resolved into one
or more ip addresses.
-
ip-address is either an IPv4 or IPv6 address.
-
An IPv6 address, enclosed in square brackets,
such as [::1]. The addrbits option may be used to specify the number
of relevant bits in the IP address.
-
An IPv4 address, such as 127.0.0.1. The addrbits option may be used
to specify the number of relevant bits in the IP address.
The netmask option allows to specify an IPv4 network mask, such as
255.255.255.0.
If neither AllowFrom nor DenyFrom are configured
access to a share or application is enabled from all network addresses
(implied AllowFrom=All).
If AllowFrom and/or DenyFrom are configured, access
to a share or application is denied unless specifically allowed
(implied DenyFrom=All).
See also:
eloqsd.app configuration
eloqsd.share configuration
The TLS CertChainFile configuration requires
a single file in PEM format containing the server
certificate and optionally any additional intermediate
certificates which represent the verification chain up to the
root certificate. PEM is a text file format, containing one
or multiple Base64-encoded sections, each starting with a BEGIN
line and ending with an END line.
When obtaining, e.g., purchasing, a TLS/SSL server certificate, it
depends on the issuing certification authority (CA) how the
certificate and optionally any additional intermediate certificates
are delivered.
Typically, to obtain a certificate, a certificate signing request
(CSR) must be issued to the CA. This requires to create a private key
which is stored on the local disk, typically in PEM format.
This file can be configured as TLS CertKeyFile.
The CA then issues the certificate and typically delivers multiple files,
one file containing the server certificate (named "your_host_name.crt"
or similar), and another file containing the intermediate certificates
(its name typically contains "CA.crt" or "bundle" or "chain").
Please refer to the CA's documentation about how exactly the certificate
is delivered.
If there is an additional file containing the server certificate along
with the intermediate certificates, its name typically contains "fullchain"
or similar.
If this is present, it can be configured as TLS
CertChainFile. For example, letsencrypt.org delivers a
"your_host_name/fullchain.pem" file below "/etc/letsencrypt/live/".
Otherwise, the TLS CertChainFile can be created
from the server certificate file and the intermediate certificate file.
For example, if the server certificate file is named "xy_yourdomain_com.crt"
and the intermediate certificate file is named "xy_yourdomain_com.ca-bundle",
the resulting "xy_yourdomain_com.fullchain" file can be created like below:
cat xy_yourdomain_com.crt \
xy_yourdomain_com.ca-bundle \
> xy_yourdomain_com.fullchain
The resulting file will have the following content:
-----BEGIN CERTIFICATE-----
... server certificate contained in the xy_yourdomain_com.crt file ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... intermediate certificates contained in the xy_yourdomain_com.ca-bundle
file, possibly multiple BEGIN/END CERTIFICATE sections ...
-----END CERTIFICATE-----
|
|
