The daily edition.

Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX) documentation, bundle enterprisedevelopereclux_ug_120. The listener procedure applies to an enterprise server region that is enabled for EZASOCKET support. I did not test any of the settings below; everything is taken from the manual pages cited.

Turning on TLS for a listener is only the first step. What the listener will actually negotiate is controlled by two further things: the Protocols list, which has its own small operator language, and Honor Server Cipher List, which decides who picks the cipher suite. Both are easy to get subtly wrong.

The protocol list starts from defaults, not from empty

The TLS protocols field has a documented default state. According to Configuring a TLS Protocols List:

• SSL2: disabled permanently.
• SSL3: disabled.
• TLS1 and TLS1.1: enabled, but marked deprecated.
• TLS1.2 and TLS1.3: enabled.

The page notes that RFC 8996 deprecates TLS 1.0 and 1.1, that Rocket Software strongly recommends avoiding them unless needed for compatibility with older devices or applications that cannot be upgraded, and that a future release will disable them by default. In other words, in 12.0 a listener left on defaults still accepts those two deprecated versions.

The operators

Each option in the field must be preceded by an operator, except the special option ALL. The syntax is the same one used in Apache configurations, and the page says Apache configurations can be copied across with little modification.

• + adds the following option to the existing protocol list.
• - deletes the following option; it can be added again later in the string.
• ! excludes the following option permanently and ignores any later attempt to add it back.

Because the list is additive on top of the defaults, the page gives two rules. To remove one protocol while keeping the rest of the defaults, add something like -SSL3. To discard every default, begin the string with -ALL and then add what you want. The manual's examples show the evaluation order:

-ALL+TLS1.1+TLS1.2          Only TLS1.1 and TLS1.2
-ALL-TLS1.1+TLS1.1+TLS1.2   Only TLS1.1 and TLS1.2 (a - option can be re-added later)
-ALL+TLS1.1 +TLS1.2-TLS1.2  Only TLS1.1
!ALL                        Syntactically valid, but removes all protocols permanently
                            and puts the client or server in an error state at start-up

Two input details matter operationally. A zero-length string, or a string containing only a space, leaves the default behavior unchanged. Space and tab characters inside the string are ignored, but any other unexpected character produces error condition 0089.

Honor Server Cipher List: who chooses the cipher suite

The Honor Cipher List page explains the switch. With Honor Server Cipher List enabled, the server determines which cipher suite the client uses. With it disabled, the client decides. The page states that letting the client choose is insecure, because an attacker could then choose weaker encryption to exploit. If no cipher list is specified for a TLS-encrypted endpoint, a default is used.

The setting is configured per network endpoint, and ESCWA exposes it in different places depending on which endpoint you are securing:

• ESCWA itself: Server Settings, then TLS Settings, then Advanced; restart the ESCWA process after applying.
• A Directory Server: its Connection properties with Enable TLS and Use Custom Certificates checked, then Advanced; restart the Directory Server process.
• An Enterprise Directory Server (EDS): configured for each listener, so the page says to repeat the steps for every listener.
• A region's Communications Process: General, then Listeners, then TLS Settings and Advanced; restart the region so the changes are applied.
• A region's listener: same navigation, with the certificate file and keyfile set first; restart the region.

The EDS case is the one most likely to leave a gap: the page says to enable it on every listener to ensure all connections enforce the server cipher order.

Putting both on a region listener

The procedure in Configuring a Listener to use TLS Protocols and Cipher Suites runs, in ESCWA, from the region's Operation tab through General, then Listeners, then the edit icon for the listener. On the Listener Properties page open TLS Settings, check Enable TLS and fill in Certificate File and Keyfile. Then expand Advanced, check TLS Honor Server Cipher List, and fill in the Protocols and Cipher Suites fields in priority order. The page's examples are:

Protocols:     -ALL+SSL3+TLS1
Cipher Suites: HIGH:!SSLv2:!RC4:!aNULL@STRENGTH

Read the protocols example with the operator rules above in mind: -ALL+SSL3+TLS1 clears everything and then enables SSL3 and TLS1, the very protocols the other page treats as disabled by default or deprecated. It illustrates the field's syntax; it is not a hardened value. For a modern list, the operator rules point to something like -ALL+TLS1.2+TLS1.3, which is my application of the documented syntax rather than an example the manual gives. The same page notes that the Protocols field now supports TLS 1.3, and that a blank Protocols or Cipher Suites field falls back to the default.

Related prerequisites

A listener sends whatever is in its certificate file, so Additional TLS notes matters here: a listener can send a full certificate chain rather than a single certificate by putting all the necessary certificates into one file and configuring that file as the certificate file. PEM and PKCS#12 (PFX) formats can hold multiple certificates; for PEM, concatenate the files. The same page also describes requiring client certificates on other TLS-enabled listeners as a way to make it harder for attackers to connect, where you are already issuing client certificates to users.

Takeaway

On a 12.0 UNIX listener, an empty Protocols field means the defaults, including deprecated TLS 1.0 and 1.1; use a leading -ALL to replace them rather than assuming the list starts empty, tick Honor Server Cipher List so the server rather than the client picks the cipher suite, and treat the manual's -ALL+SSL3+TLS1 example as syntax illustration, not a security baseline.