Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects

Claus Aßmann
<INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>
writes:

There is only one other fix in the current code, hence we haven't
released a new version (yet).

If you're looking for another quick fix to justify a new version, then
may I suggest making _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE default?

The Debian sendmail package is still built without this (I will open a
bug now).  Googling a bit I see that Redhat hit the problem a few years
ago: https://bugzilla.redhat.com/show_bug.cgi?id=1565341

There are probably many other distros, or end users building their own
binary, doing the same because they are unaware of the setting.

A binary built without that flag can only use server certificates
directly signed by a CA known to the client.  A well known workaround is
to add intermediate CAs to the CACertFile.  The simplest method is by
using the server certificate chain for both ServerCertFile and
CACertFile.

A side effect of this workaround is that intermediate CAs are also
trusted to sign client certificates. Which will cause policy conflicts.

If the server certificate is signed by a public CA using an intermediate
CA, which I will claim is an extremely common use case nowadays, then
client certificates are useless unless _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE
is set.

Yes, I know I still can configure client trust by DN using the access
db.  But AUTH EXTERNAL is not possible in a secure way AFAICS.

Even worse, users may be tempted to ignore the security implications and
trust client certificates even if they depend onq the CACertFile workaround.



Bjørn