Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-user>›Directive§ 3.3.8.4

tls-ca-file

<smtp-user>

Trusted authorities whose certificates will do for this login
in the configuration this is a linetls-ca-fileinside the block <smtp-user>
The same name 2:<smtp-listener><smtp-user><transmissions-api-listener>— some of them are other settings, some are the same one
Not one certificate, but any from your own authority

The line names files with certificate authority certificates. A client authenticates if its certificate chains up to at least one of the specified chains.

It works with authentication-method set to ca-file and requires an encrypted connection.

There can be several files — comma-separated in one line or in several lines. The manual gives exactly such an example, and it explains why: chains from different years live side by side while a transition is under way.

The check is softer than with the single-file method. Any certificate from a trusted authority will do — including one issued to someone else. It can be narrowed with a name check: tls-certificate-san-or-cn.

The main trap is forgetting that a chain does not check who exactly has come. Any certificate issued by the same authority will do for this login. If the authority issues certificates not only to you, the name check is mandatory, not optional.
What the Hub does. It does not write it: submission goes by login and password. The method will be useful where there are many submitters sharing a certificate authority — then adding a platform does not require editing the node’s configuration.
Recommended values

The value is a path or several paths:

Form When
one file one authority, the usual case
several separated by commas a transition between chains from different years
several lines the same thing, reads better

And almost always next to it — tls-certificate-san-or-cn: without it any certificate from this authority will do.

The “any of the chains will do” rule, several files and the PEM requirement come from the manual (§ 3.3.8.4). The advice about a mandatory name check is ours.
Example configuration
# chains from different years live side by side while a transition is under way
<smtp-user foo>
    authentication-method ca-file
    tls-ca-file /etc/pmta/ca-certs2020.pem    tls-ca-file /etc/pmta/ca-certs2021.pem, /etc/pmta/ca-certs2022.pem
    tls-certificate-san-or-cn pmta.messagebird.com
</smtp-user>
The manual’s example, with the last line added: without it any certificate from any of the listed authorities will do, not only the one issued to this platform.
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 ends1 mistake▶

Relying on the chain without a name check

our experience

What it costsAny certificate from this authority will do for the login. With a public authority that means “anyone on the internet”; with a corporate one, any employee or service.
How to spot itIt is discovered during an access review, not in operation.
How to do it rightAdd tls-certificate-san-or-cn with the full name. Chain verification answers “is it our authority,” not “is it the right 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
tls-ca-file <path>
Values
a path to a PEM file; several — separated by commas or by repeating the line
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-user>
How many times
may be repeated
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <smtp-user> and applies to one login; it has no inheritance, but it can be repeated — the chains add up. The encryption requirement is set separately, in <source>.
⇄

Related directives

2 relations

Does not work without

authentication-method<smtp-user>The line works with the “trusted authority” method and only with it. § 3.3.8.4

Works together with

tls-certificate-san-or-cn<smtp-user>An additional check on top of the chain: the name in the certificate must match the one specified. § 3.3.8.5

How to check on the node
That the file is readable and contains the expected authorities is checked before enabling it:
openssl crl2pkcs7 -nocrl -certfile /etc/pmta/ca-certs.pem | openssl pkcs7 -print_certs -noout
The output lists the subjects of all certificates in the file. If the authority issues certificates not only to you, add a name check — otherwise any of its clients will do.
◇

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 <smtp-user>:tls-certificatetls-certificate-san-or-cnauthentication-methodpasswordsourceAll 6 directives of the block →