Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.58.13

http-tls-min-version

Globalrestart required

The lower TLS version bound for the web monitor
in the configuration this is a linehttp-tls-min-version tlsv1.2inside the block Global
The version floor on the management interface

The web monitor is a separate program (pmtahttpd) on the port from http-mgmt-port. This line sets below which protocol version it will not go. The default is tlsv1.2.

One port, two kinds of conversation. The monitor looks at the first bytes of a connection and understands both a plain request and a TLS handshake. We checked this on a fleet node: the same port answered both a simple request and a TLS 1.3 handshake. So encryption on the monitor is always available — the only question is whether the client uses it.

There are none of the compatibility arguments mail has. When sending, there are thousands of receivers, and some of them are ancient; the monitor has a browser and our own clients on the other end. Raising the floor here is cheaper than anywhere else.

The setting is read by a different process than mail. pmta reload rereads the sending configuration and does not touch the monitor — the new bound takes effect only after pmtahttpd is restarted.

The main trap is assuming a configuration reload applied the setting. It did not: the monitor reads its lines at its own startup. A check right after pmta reload will show the old behavior, and it will be taken for a non-working directive.
What the Hub does. It does not write it — and benefits from the default only on paper. The baseline configuration has http-redirect-to-https false, and polling goes over plain http://: the management key goes to the node in a header without encryption. Raising the floor here is pointless while the Hub itself does not encrypt its connection to the monitor.

The Hub already restarts the monitor after applying the configuration — PmtaConfigApplier::restartMonitor — so unlike many others, nothing in the apply order gets in this directive’s way.

Recommended values

The default is already reasonable, and lowering it is almost always wrong:

Value When
tlsv1.2 (default) always
tlsv1.3 all monitor clients are your own and modern
tlsv1.1 and below only for an old client that cannot be updated

The difference from mail is the price. There, lowering the bound saves a message’s delivery; here, it opens up the management interface.

The values and the tlsv1.2 default come from the manual (§ 3.3.1.58.13). That the port answers both a plain request and a handshake is our check on a fleet node. That pmtahttpd reads the setting at startup is also our observation.
Example configuration
# the node's management interface
http-mgmt-port 1000
http-tls-min-version tlsv1.2http-redirect-to-https true
The first line without the third gives little: while plain connections are also accepted, the client will choose them itself. The version bound and the ban on plain connections are set together.
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 ends3 mistakes▶

Checking right after a configuration reload

our experience

What it costsThe monitor reads its settings at its own startup. pmta reload does not touch it, and the check shows the previous behavior.
How to spot itThe file has the new bound, but the handshake follows the old one.
How to do it rightRestart the web monitor — systemctl restart pmtahttp where it is a unit, or through pmtawatch where it is not.

Taking your own client's refusal for the node's

our experience

What it costsOpenSSL 3 at security level 1 does not offer old versions at all. The no protocols available answer comes before any network activity, and the node looks configured more strictly than it is.
How to spot itA check of a “forbidden” version never reaches the node, whatever its configuration.
How to do it rightAllow the old version for your client — -cipher ‘DEFAULT:@SECLEVEL=0’ — and look at what the node answers.

Raising the floor while leaving plain connections open

§ 3.3.1.58.13

What it costsThe bound concerns only connections that got to encryption at all. A client for which it is simpler not to encrypt will not notice the bound.
How to spot itThe floor is raised, but the management key is still visible on the network.
How to do it rightSet http-redirect-to-https true and make sure the monitor’s clients can do https.
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-min-version <enumeration>
Values
tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3
Default
tlsv1.2 § 3.3.1.58.13
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, in the Global section, and applies to the node’s whole management interface. The monitor has no separate per-listener settings — there is only one.
⇄

Related directives

4 relations

Depends on

openssl-security-levelGlobalThe OpenSSL security level may refuse a version this bound allows. inferencehttp-redirect-to-httpsGlobalWhile plain connections are also accepted, the whole set of TLS settings decides nothing: the client simply will not encrypt. inference

Works together with

http-tls-max-versionGlobalThe other bound of the same range: together they say which versions the monitor will negotiate. § 3.3.1.58.14

Applies to

http-mgmt-portGlobalOne of the settings of the very interface that listens on this port. § 3.3.1.58.13

Referenced from

http-tls-allow-sslv3GlobalIt sets the monitor’s lower bound; separate switches are no longer needed. inferencehttp-tls-allow-tlsv1GlobalReplaced the whole set of five switches: the monitor’s version range is set by a pair of bounds. § 3.3.1.58.9http-tls-allow-tlsv1.1GlobalReplaced the whole set of five switches: the monitor’s version range is set by a pair of bounds. § 3.3.1.58.10http-tls-allow-tlsv1.2GlobalReplaced the whole set of five switches: the monitor’s version range is set by a pair of bounds. § 3.3.1.58.11

How to check on the node
It has to be checked from the client side, and there is a catch here: the refusal may come not from the node but from our own OpenSSL. First we take a version that should go through:
openssl s_client -connect NODE:1000 -tls1_2 -brief </dev/null
The line Protocol version: TLSv1.2 means the floor is not higher. Now a version that should not go through: a bare -tls1_1 will answer no protocols available — that is a refusal by our client, not the node. To ask the node itself, you have to allow the old version for yourself: -tls1_1 -cipher ‘DEFAULT:@SECLEVEL=0’. Then the answer will be tlsv1 alert protocol version — the refusal came from the other side.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security
Neighboring settings of the block Global:smtp-server-tls-certificateopenssl-security-levelsmtp-server-tls-min-versionsmtp-server-tls-cipherssmtp-server-tls-cipher-server-preferenceAll 108 directives of the block →