Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.58.14

http-tls-max-version

Globalrestart required

The upper bound of the TLS version on the web monitor
in the configuration this is a linehttp-tls-max-version none, which behaves as tlsv1.3inside the block Global
The version ceiling on the management interface

The second bound of the same range as http-tls-min-version. There is no default — so the ceiling is unlimited and the monitor negotiates the newest version the client offers.

The reason to set a ceiling here is always the same: a client that announces a modern version and breaks on it. On the monitor this is most often not a browser but an old library in someone else’s program that talks to the API.

This is a workaround for someone else’s bug, not a security setting. Lowering the ceiling weakens the interface that carries the management key — if you set it at all, do it with a comment and a date.

The main trap is setting a ceiling and forgetting it. The library gets updated, the reason disappears, but the line stays and keeps the management interface on an outdated version for years.
What the Hub does. It does not write it: the ceiling is unlimited, and there is nothing to limit it for — the monitor’s only client here is our own.
Recommended values

Set it only for a specific reason:

Value When
do not set (default) always
tlsv1.2 an API client breaks on 1.3

The line is accompanied by a comment, otherwise in a year nobody will remember why the interface is kept on an old version.

The values and the absence of a default are from the manual (§ 3.3.1.58.14). The advice to record the reason and the date is ours.
Example configuration
# a workaround for a client bug, not a security setting
http-mgmt-port 1000
http-tls-max-version tlsv1.2   # client X's library breaks on 1.3; recheck in 2027
The comment with the reason and the deadline is part of the line. Without it the ceiling will outlive the reason it appeared for.
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▶

Lowering the ceiling “just in case”

our experience

What it costsA ceiling protects nothing — it only forbids the new. On the interface that carries the management key this is a pure loss.
How to spot itThe monitor negotiates 1.2 although all its clients can do 1.3.
How to do it rightRemove the line. Limiting from below is the job of http-tls-min-version.

Setting a ceiling instead of investigating the client's breakage

our experience

What it costsThe real cause — the library in the client — remains, and the same failure will surface on any other interface this client talks to.
How to spot itThe client works with the monitor and nowhere else.
How to do it rightSet the ceiling as a temporary measure and open a task to update the client.
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-max-version <enumeration>
Values
tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3
Default
none, which behaves as tlsv1.3 § 3.3.1.58.14
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
We ask the node for the newest version — it should be negotiated if no ceiling was set:
openssl s_client -connect NODE:1000 -tls1_3 -brief </dev/null
Protocol version: TLSv1.3 — there is no ceiling. If alert protocol version came back instead, a ceiling is set and lowered below 1.3.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Node security