Inter-Cluster TLS

Inter-Cluster TLS encrypts TCP connections between Cluster Servers: Frontend Servers, Backend Servers, and the Dynamic Cluster Controller. TLS for client connections (HTTPS, SMTPS, and similar) is configured separately and is not covered here.

Typical protected paths include Frontend Server <-> Backend Server, Backend Server <-> Backend Server, and Backend Server <-> Controller. See Cluster for roles. Backend ports are set under Inter-Cluster Communications.

The Server logs Inter-Cluster TLS events with the TLSC prefix in Monitor Log. Configuration and status are available via the CLI command GETCLUSTERTLSSTATUS (requires the Monitoring access right).

Configuration

Inter-Cluster TLS has two independent parts for each Backend Server port:

Part	Where to configure	Meaning
Cluster TLS (outbound)	Cluster settings (DeliveryUseTLS, IMAPUseTLS, PWDUseTLS, etc.)	This Server uses TLS when connecting to other Cluster Servers on that port.
Local Listener Init SSL/TLS	Settings -> Services -> Listener for the corresponding module	The Init SSL/TLS option is enabled on this Server's TCP Listener for that port (see Listeners). On a Backend Server, compare it with outbound UseTLS of the Cluster Server that connects here. On a Frontend Server, this is the public listener mode, not the remote side of Frontend Server -> Backend Server.

Both sides must agree: if outbound TLS is enabled on the connecting Server, the target Server must accept TLS on the corresponding Listener.

Supported Backend Server ports: Delivery, Submit, POP, IMAP, PWD, HTTP User, HTTP Admin, XIMSS, XMPP, LDAP.

Server certificates and Trusted Certificates for TLS are configured in PKI.

Status via CLI

You can retrieve Inter-Cluster TLS configuration and runtime status with GETCLUSTERTLSSTATUS. Field descriptions and a sample response are in the CLI reference.

Logging

Messages related to Inter-Cluster TLS are written to Monitor Log with the prefix TLSC. The prefix is used only for connections between Cluster Servers when the remote address is listed in the Frontend or Backend Cluster address lists. Regular TLS traffic is logged without this prefix.

Monitor Log tags

Each Monitor Log record has a tag that identifies the component. For Inter-Cluster TLS, look for these tags together with the TLSC text prefix:

Monitor Log tag	Cluster / Settings option	Covers
LOCKER	Cluster -> Dynamic Cluster Locker Log	Backend Server connection to the Controller on the PWD port (LOCKER).
CLUSTER	Cluster -> Mailboxes log level (SingleImageLogLevel)	Dynamic Cluster Server connection to the Controller for Shared Domain Account access synchronization.
ADMIN	Cluster -> Object Admin log level	Inter-Cluster administration commands via PWD.
SUBMIT, IMAP, ...	Corresponding Cluster log levels	Submit, remote mailbox access, and other Inter-Cluster connections between Cluster Servers.

Handshake details (cipher, certificate) are controlled on the TLS Sessions panel in PKI (Log Level). Those lines usually keep the module tag above (LOCKER, IMAP, and similar); they are not a separate Monitor Log component named TLS.

Recommended filter in Monitor Log: open the active log file with Filter=TLSC. Also search for LOCKER, ADMIN, and failed.

Recommended log levels for troubleshooting

When diagnosing Inter-Cluster TLS problems, temporarily raise these levels, then return them to normal:

1. Cluster -> Dynamic Cluster Locker Log = Problems, Object Admin = Problems, Mailboxes = Problems.
2. PKI -> TLS Sessions -> Log Level = Problems (or All Info for a single session).
3. Confirm UseTLS is enabled on the needed ports (PWDUseTLS, IMAPUseTLS, ...).

Typical messages

The following Monitor Log lines help confirm success or failure of TLS between Cluster Servers.

• With TLSC controller %T TLS handshake failed, a Backend Server failed to establish TLS with the Controller (LOCKER tag).
• With TLSC connected to CONTROLLER%T, a Backend Server established a TLS LOCKER connection to the Controller.
• With TLSC TLS to CONTROLLER%T failed, a Dynamic Cluster Server failed TLS to the Controller (CLUSTER tag, Shared Domain Account access synchronization).
• With TLSC %T -> %T TCP connect failed, TLS handshake failed, or protocol open failed, an outgoing Inter-Cluster connection between Cluster Servers failed (ADMIN, SUBMIT, IMAP, and similar tags).
• With TLSC backend %T TLS handshake failed, this Server failed TLS while connecting to a Backend Server (often Frontend Server -> Backend Server for IMAP, POP, PWD, and similar). The word backend in the log line is the remote Backend Server address, not the role of the Server that writes the log.
• With TLSC server cluster %T STLS failed, incoming STLS on PWD from a Cluster Server failed.
• With TLSC client %T STLS failed, outgoing STLS on the PWD administration client path failed. The word client here is the PWD session acting as a TLS client for STLS, not an end-user mail client.

OpenSSL-layer messages (failed to open a secure connection, cipher acceptance) stay without the TLSC prefix. Raise Log Level on the TLS Sessions panel in PKI to see them.

Limitations

Outbound Inter-Cluster TLS does not verify the peer Server certificate, because no server name is set for verification. Diagnostics rely on TCP and TLS setup failures with the TLSC prefix, not on a separate certificate Subject verdict.