Question about CA’s for the smtp client


I have a question regarding specifying where the list of trusted CA’s are in regards to the smtp client.

In man 5 postconf, I can see there are two configuration parameters regarding this:


The documentation (as I understand it), notes that:

1. smtp_tls_CAfile

— Specifies file that contains CA certs of root CA’s trusted to sign either remote SMTP server certificates or intermediate CA certificates

2. smtp_tls_CApath

— Specifies directory with PEM format CA certs that smtp client uses to verify remote SMTP server certificate
— Preferred over smtp_tls_CAfile when the number of trusted roots is large

On one of my installations of Postfix 3.1.0 on Ubuntu 16.04 LTS, I use CAfile to specify the file that stores all the CA certs:

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

My questions are:

1. Is that correct ?

2. Is there any other guidance on when to prefer smtp_tls_CApath over smtp_tls_CAfile ?


- J


Re: Question about CA’s for the smtp client

By Viktor Dukhovni at 12/11/2017 - 18:13

The recommended set of trusted CAs for the Postfix SMTP client is
*empty*. TLS in SMTP is opportunistic, and email sent whether or
not the peer appears to be authenticated. So any trusted CAs you
might configure are largely just wasted memory and CPU.

Generally avoid this entirely. It does however work "better"
with chroot jails, since the file is loaded into memory before

Let's say that "large" is 5 or more. By the time you have more
CAs than you've carefully curated after thinking about each one,
you're probably better off with CApath, to the extent that you
bother to configure either.

The recommended setting is empty.

What are you using the certificates for? Have you configured
any destinations with a "security level" of "verify" or "secure"?

Set both empty.

Re: Question about CA’s for the smtp client

By J Doe at 12/11/2017 - 20:55

Hi Victor,

Ok. If I am understanding you correctly, you are saying that if the SMTP client is configured to use opportunistic TLS, the mail will be delivered regardless of whether the remote peer is *authenticated* ?

In my case, I use opportunistic TLS for the SMTP client:

smtp_tls_security_level = may

I then had the CA list set up:

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

I did not have any per-destination rules set up - all mail via the SMTP client used these settings. When I send a test message in to my server and the SMTP client sends it out to my test Gmail address, I note that the TLS log line in mail.log is:

Dec 11 20:40:44 server postfix/smtp[2559]: Trusted TLS connection . . .

But when I remove the CA list the log line is:

Dec 11 20:40:44 server postfix/smtp[2559]: Untrusted TLS connection . . .

*HOWEVER* you are saying that the authentication status (“Trusted” / “Untrusted”), is actually irrelevant as the mail will still be delivered to Gmail regardless. The fact that I receive successful authentication (“trusted”), is irrelevant compared to no authentication (“untrusted”), because the mail goes through either way so in effect all I am doing is wasting compute resources ?

Apologies if this is a basic question - I do appreciate your help.

After Postfix configuration ins and outs, I have a book ready on cryptography that I am going to read to get a better handle on this.

- J

Re: Question about CA’s for the smtp client

By Viktor Dukhovni at 12/11/2017 - 21:17

Correct, and indeed with Opportunistic TLS Postfix does not attempt to
check the peer hostname against any names in the certificate. And so,
even if the certificate chain is issued by a trusted CA, it may well
be for some unrelated hostname.


Essentially, yes. Some might argue that there's forensic value in
the logs, and that this type of "tamper-evidence" might even deter
some kinds of attacks. I remain skeptical about that.

So for most users, an empty CA list works just fine, and you get
to STARTTLS to protect against passive monitoring, while remaining
vulnerable to active attacks.

See <a href="" title=""></a> for my views of opportunistic
security. See also:

<a href="" title=""></a>
<a href="" title=""></a>

A small, but growing fraction of SMTP domains (currently ~175k domains
out of ~5.1 million DNSSEC-signed domains I've been able to find) have
deployed DNSSEC and have TLSA records for their MX hosts. You can enable
DANE outbound in your SMTP client, and get authenticated email delivery
to these domains, with mail deferred when authentication fails (either
due to an actual MiTM attack, or operational error on the receiving side).
At present ~177 of the 175k domains are affected by what appear to be
operational issues, this number fluctuates as errors are fixed, with a
floor around ~130 domains that don't receive or ignore failure notices.

Deploying DANE inbound (publishing TLSA records for your own MX hosts)
requires some operational discipline. This coordinated changes in
the DNS and SMTP configurations when server keys and/or certificates

<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>

When updating the certificate chain you need to temporarily pre-publish
multiple TLSA records matching the current and future certificate:

<a href="" title=""></a>

However, with "3 1 1" + "2 1 1", the rollover process can be
substantially simplified:

<a href="" title=""></a>
<a href="" title=""></a>