TLS Listener Policy: When mf-server.dat Overrides ESCWA
Rocket Enterprise Server can centralize TLS listener defaults in mf-server.dat, but honor-server-cipher-list and the TLS 1.3 middlebox setting are stronger than ordinary defaults: values in the file override listener-level choices. [1] [2]
Read the full briefing
TLS Listener Policy: When mf-server.dat Overrides ESCWA
Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX), configuring Enterprise Server TLS listeners.
Enterprise Server supports two layers for TLS listener policy. A listener can carry its own settings, while $COBDIR/bin/mf-server.dat can define defaults under [TLS]. At listener startup, Enterprise Server checks that file; when the listener has no value for a property, the file’s value is used. This makes mf-server.dat useful for consistent protocol, cipher, Diffie-Hellman, and cipher-group defaults across listeners. The important exception is that this is not a uniform “listener wins” hierarchy. Rocket documents that middlebox workaround and honor server cipher list values in mf-server.dat override values configured on a listener. See To configure TLS default properties for listeners.
The relevant structure is:
[TLS]
protocols=
cipher suites=
TLS1.3 cipher suites=
min dh size=
cipher groups=
middlebox workaround=
honor server cipher list=The last setting accepts yes/1 or no/0. When enabled, the server enforces its ordered cipher list instead of allowing the client’s ordering to decide the negotiated choice. Rocket explains that clients normally send an ordered supported-cipher list during the handshake; honoring the server list changes selection to the server’s protocol and cipher preference. Blank protocol or cipher fields still cause defaults to be used. See Specifying a Server Protocol and Cipher Suite Preference.
Protocol-list syntax is additive, which matters when building an explicit policy. In Configuring a TLS Protocols List, + adds a protocol, - removes one but permits it to be added later, and ! excludes it permanently for that expression. To replace inherited defaults rather than modify them, begin with -ALL and then add the intended protocols. A blank or whitespace-only string leaves default behavior unchanged; !ALL creates an error state that prevents the client or server from starting. The same page records TLS 1.0 and 1.1 as deprecated and recommends avoiding them unless older clients require compatibility.
For an EZASOCKET-enabled region, ESCWA exposes the listener workflow at Operation > General > Listeners > Edit > TLS Settings. After enabling TLS and supplying the certificate and key file, expand Advanced to set server cipher-list enforcement, protocols, and cipher suites. If either list is blank, its default applies. The documented procedure specifically requires EZASOCKET support; it is not a generic setup recipe for every endpoint. See Configuring a Listener to use TLS Protocols and Cipher Suites.
Takeaway: Treat mf-server.dat as a policy layer, and remember that its middlebox and server-cipher-order settings override ESCWA listener choices.