Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.108.13

smtp-client-certificate

<domain>

Your own certificate presented to the receiver
in the configuration this is a linesmtp-client-certificateinside the block <domain>
When the receiver wants to know who has come to it

Usually verification is one-way: the node looks at the receiver’s certificate and presents nothing itself. This line enables the reverse direction — the node shows its own certificate.

It is rarely needed and only by agreement. Public receivers do not ask for client certificates; they occur at corporate gateways and partner channels where the parties have agreed on exactly that.

The password is the second word and is optional: if the key in the file is not encrypted, there will be no such word.

This line does not enable verification of the receiver. It is about what we present; what we trust is the job of smtp-tls-ca-file.

The main trap is a file with a private key next to the configuration. Its password, if there is one, sits in the same line in plain text. Permissions on the file and on the configuration must be equally narrow, and both end up in backups.
What the Hub does. It does not write it: client certificates are needed only by agreement with a specific receiver, while the fleet sends to public ones. If such an agreement appears, the line goes into that receiver’s block — and along with it you need to decide where the key is stored and who replaces it when it expires.
Recommended values

The value is a path to the file and, if needed, a password:

Form When
a path to the file the key in the file is not encrypted
a path and a password as the second word the key is encrypted — the password will sit in the configuration in plain text

What to plan for before enabling it: the certificate’s validity period and who renews it. The receiver will reject an expired client certificate, and it will look like a delivery refusal with no clear reason.

The entry format and the optional password come from the manual (§ 3.3.10.108.13). The remarks about key storage and the validity period are ours.
Example configuration
# a partner gateway requires mutual verification
<domain partner-gw.example.net>
    use-starttls yes
    require-starttls yes
    smtp-client-certificate /etc/pmta/client.pem</domain>
No password is given here — which means the key in the file is not encrypted, and the permissions on it must be as narrow as on the configuration.
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▶

Putting a client certificate into the general recipient block

our experience

What it costsThe node starts presenting its certificate to every receiver. There is no benefit, and extra information about our infrastructure goes out with every connection.
How to spot itThe line is in <domain *>.
How to do it rightSet it only for the receivers you have an agreement with.

Not watching the expiration date

our experience

What it costsThe receiver will reject an expired certificate. Delivery will stop, and the refusal will name the reason in general terms — finding it will take a long time.
How to spot itDelivery to one receiver stops on a particular day with no changes in the configuration.
How to do it rightSet a reminder by the date from notAfter and check it with the command from the reference at every review.
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-client-certificate <path>
Values
a path to the certificate file, a password as the second word if needed
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and merges by the usual recipient block rule: the most precise match on the receiver’s name wins. The same three levels apply by sending address — node, <virtual-mta-pool>, <virtual-mta>. The line is not put in <domain *>: there is no reason to present your certificate to everyone.
⇄

Related directives

1 relation

Does not work without

use-starttls<domain>The client certificate is presented during the encrypted negotiation and plays no part without it. § 3.3.10.108.13

How to check on the node
That the certificate is readable and has not expired is checked before enabling it:
openssl x509 -in /etc/pmta/client.pem -noout -subject -enddate
The date in notAfter is what you will have to keep an eye on. The receiver will reject an expired client certificate, and the refusal will state the reason vaguely.
◇

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
reversible: harms only while it is set
Scenarios
Connection encryption
Neighboring settings of the block <domain>:use-starttlssmtp-tls-min-versionuse-daneuse-mta-stsrequire-starttlsAll 135 directives of the block →