On Thu, Feb 11, 2021 at 02:51:02PM +0000, bitozoid wrote:
> As of today, doc says for 'smtp_tls_CAfile':
>
> "A file containing CA certificates of root CAs trusted to sign either
> remote SMTP server certificates or intermediate CA certificates."
It can also contain intermediate CA certificates. Storing non-root CAs
carries a risk that they may expire before you remove them, and then
they may take precedence over non-expired intermediate CA certs that the
remote peer provides in the TLS handshake.
TLS servers or clients that fail to send the required list of
intermediate certificates are in violation of various RFCs, and poor
interoperability is to be expected. Perhaps a better fix is to request
that the problem be fixed on the remote end.
> and for 'smtp_tls_CApath':
>
> "Directory with PEM format Certification Authority certificates that
> the Postfix SMTP client uses to verify a remote SMTP server
> certificate."
They're basically the same, with the key difference that CAfile is
preloaded into memory in its entirety, while CApath is demand loaded,
one certificate at a time.
You can also use the "tafile" option in the TLS policy table to specify
explicit per-destination trust-anchors that override CAfile and CApath.
The trust-anchors in the "tafile" can even be bare public keys (e.g.
output of "openssl x509 -in cert.pem -pubkey -noout"), rather than
certificates, and thus never explicitly "expire", it is then up to you
to remove them as/when you see fit.
> On one hand, it looks that a remote server intermediate CA certificate
> (think about a remote server that does not send its intermediate CA
> certificate) does not fit in 'smtp_tls_CAfile' but in
> 'smtp_tls_CApath'.
both support the same types of certificates.
> Am I misunderstanding the documentation? Is there a right place to
> drop the intermediate CA certificate?
With an empty CAfile, and just CApath, you reduce startup overhead,
by delaying certificate loading until they're needed. When running
the SMTP client chrooted, the CApath needs to be *inside* the chroot
jail. If the CAfile is large enough, CApath is the better option.
If preloading the CAfile is sufficiently cheap (a few dozen
certificates), it may be simpler w.r.t. to chroot etc., than CApath.
On a busy server, the cost of loading the file is paid every $max_use
deliveries (i.e. once per smtp(8) process), and the content is in memory
up to as many times as the sum of the various smtp delivery agent
process limits in master.cf (perhaps $default_process_limit * 2, once
for "smtp/unix" and once for "relay/unix").
--
Viktor.
