Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.58.18

http-tls-cipher-server-preference

Globalrestart required

Who chooses the cipher on the web monitor — the node or the client
in the configuration this is a linehttp-tls-cipher-server-preference falseinside the block Global
Who has the last word in choosing the cipher

In a TLS handshake the client sends a list of what it supports, and the server chooses. By default the monitor takes the first suitable one from the client’s list — that is, the client decides. With true the roles are swapped: the monitor goes through its own list and takes the first thing the client supports.

Without this line, sorting your own list is pointless. The @STRENGTH entry in http-tls-ciphers orders the list by strength — and this order has no effect while the client chooses.

The setting applies to both versions: both the list up to 1.2 and the http-tls-v1.3-ciphersuites suites.

The main trap is setting the list and not enabling this line. The work of composing the order is done, but the decision is still the client’s. The error is silent: the connection goes through, just with a different cipher.
What the Hub does. It does not write it: we do not set our own cipher list for the monitor, so there is no order to insist on.
Recommended values

It makes sense only together with your own list:

Value When
false (default) no cipher list was set
true you set your own list and want its order to decide
The default false and the selection rule are from the manual (§ 3.3.1.58.18). The remark about sorting being pointless on its own is ours.
Example configuration
# your own order only has force together with this line
http-tls-ciphers HIGH:!ADH:@STRENGTH
http-tls-cipher-server-preference true
The two lines work as a pair. Apart, the first sets the list but not the order, and the second insists on the default order.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Sorting the list and leaving the choice to the client

§ 3.3.1.58.18

What it costsThe list order is not used. The client takes what suits it — often a faster and less strong cipher.
How to spot itWhat is negotiated is not what comes first in the node’s list.
How to do it rightSet true.

Enabling it without setting your own list

our experience

What it costsThere is insistence, but nothing to insist on: the order comes from the default. The line misleads whoever reads the configuration.
How to spot itThe line is in the file, but there is no cipher list next to it.
How to do it rightEither set your own list or remove the line.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
http-tls-cipher-server-preference <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.58.18
Applying
a service restart is required
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive has no inheritance: it is written at the root of the file, the Global section, and applies to the node’s whole management interface.
How to check on the node
The setting has no direct readout — it is visible by what gets selected. We look at the negotiated cipher:
openssl s_client -connect NODE:1000 -tls1_2 -brief </dev/null
Compare Ciphersuite: with the start of your list. They match — the node decides; they do not match, and the connection went through — the client decides.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Node security