Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.11

smtp-server-tls-ca-file

Global

The list of root certificates for verifying submitting clients
in the configuration this is a linesmtp-server-tls-ca-fileinside the block Global
Whom to trust when verifying whoever submits mail

The other side of verification: not us presenting a certificate, but someone presenting one to us. The line names the file with root certificates against which the chain presented by the client is verified.

This is needed only with mutual verification. Ordinary submission does not use it: the client encrypts the connection and authenticates with a login and password. Client certificates appear where the parties have agreed on exactly that.

Certificates are in PEM format, as everywhere.

The main trap is thinking the line enables something. It names whom to trust, but does not require the client to present a certificate. Mutual verification is configured on the source and listener side; the list by itself changes nothing.
What the Hub does. It does not write it: submission goes by login and password or from allowed addresses, and we have no client certificates. The line will be needed if a platform appears that submits mail with mutual verification — then, together with it, you need to decide who issues client certificates and how to revoke them.
Recommended values

The value is a file path. What to take into account:

What Note
your own authority’s list the usual case for mutual verification
public roots almost always superfluous: submitting clients are few and your own
certificate revocation the node does not check it — a revoked but not expired certificate will pass

Without an agreement with the submitting side the line is useless.

The purpose and the PEM requirement come from the manual (§ 3.3.1.11). The remarks about revocation and about uselessness on its own are ours.
Example configuration
# mutual verification: your own authority issues certificates to submitters
smtp-server-tls-ca-file /etc/pmta/certchain.pem
The manual’s example. The line by itself requires nothing — it only names whose certificates to trust if the client presents them.
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▶

Setting the list, expecting clients to start presenting certificates

our experience

What it costsThe line only names trusted authorities. The requirement to present a certificate is set elsewhere, and without it the list takes part in no connection.
How to spot itThe file is configured, submission behavior has not changed.
How to do it rightSettle the question on the reception side — source and listener — and keep the list as an addition to that.
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
smtp-server-tls-ca-file <path>
Values
path to a file with root certificates in PEM format
Applying
reload, no restart needed
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 is written at the root of the file, in the Global section, and applies to the whole node. It has no levels; an individual listener has its own line — tls-ca-file in <smtp-listener>.
⇄

Related directives

1 relation

Works together with

smtp-server-tls-certificateGlobalThat certificate the node presents itself; this list is for verifying certificates presented to it. § 3.3.1.11

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/certchain.pem | openssl pkcs7 -print_certs -noout
The output lists the subjects of all certificates in the file. If there is no list or it is empty, mutual verification will not work — and the node will give no message about it.
◇

What else to read

3 articles

◇Submission over HTTPS on its own listener, modeled on SparkPostA separate entry point: its own listener with a certificate, its own keys and a reserved source name through which the usual submission settings apply to such mail.◇The receiver declares an encryption requirement on its websiteThe node fetches the recipient domain’s policy over HTTPS and, if it is in enforce mode, delivers only when the MX matches, the connection is encrypted and the certificate is verified.◇The receiver declares an encryption requirement in its DNS zoneThe node looks at the recipient domain’s DANE records and, if STARTTLS is required, sends only over an encrypted channel with a certificate verified by fingerprint.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Connection encryption
Neighboring settings of the block Global:smtp-server-tls-certificateopenssl-security-levelsmtp-server-tls-min-versionhttp-tls-min-versionsmtp-server-tls-cipher-server-preferenceAll 108 directives of the block →