Re: Trusted CA config

Grant Taylor <gtaylor@tnetconsulting.net> writes:

Pre-script:  For some reason I don't see the post that Claus quoted,
so I'm replying to it here.
>
Bjørn Mork  wrote:

But how are we supposed to configure a sendmail server then?  MTA-STS
means that the trusted CA list must include every public CA.

>
I've been configuring Sendmail to use look in /etc/ssl/certs for
trusted CAs for years without any problem.
>

... then "AUTH EXTERNAL" is pretty much an open relay.

>
I think you're concerned about validated certs being the key to allow relay.
>
I have the following in my access(.db) file:
>
   # Allow REDACTED to relay based on client TLS certificate.
   CERTISSUER:/C=US/O=Let's+20Encrypt/CN=R3   SUBJECT
   CERTSUBJECT:/CN=REDACTED_CN1               RELAY
   CERTSUBJECT:/CN=REDACTED_CN2               RELAY
>
As the comment says and the `SUBJECT' value implies, certificates need
to be from the `CERTISSUER' *AND* have the proper `SUBJECT' listed on
in it's own `CERTSUBJECT' entry.
>
Only my servers are allowed to relay based on valid certificate *AND*
proper subject.

Yes, that works fine for relaying on an already authenticated session,
or a session where authentication is not required.  I used to do it like
that too.

But allowing relaying is not the same as "AUTH EXTERNAL".  The MSA
config will typically look like:

 DAEMON_OPTIONS(`Family=inet6, Name=MSA, Port=submission, M=Ea')

Which means that you need to authenticate before any of the access db
rules are evaluated.  And authenticated users are trusted and can relay
anyway.

Client certificate authentication is simple to configure.  Just add
EXTERNAL to your confAUTH_MECHANISMS and set TRUST_AUTH_MECH(`EXTERNAL')
But unfortunately there is no way to further limit the set of trusted
client CAs when you do this.

What am I missing?

>
I suspect that you want to look into `CERTISSUER' of `SUBJECT'
combined with `CERTSUBJECT' entries to have fine grained control over
who's allowed to relay based on certificates.

Does not replace "AUTH EXTERNAL"

I'm actually quite happy now with the separate ClientCACertFile and
ClientCACertPath. Those were the missing part. Just crossing may fingers
that _FFR_CLIENTCA and _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE are upgraded
to default soon (or at least that I can get Debian to build their
sendmail package with it).

BTW; how many versions are the _FFR build options supposed to stay before
either being deprecated or made default?

On 1/10/25 11:09, Claus Aßmann wrote:

MTA-STS has probably been "designed" by people who use http(s) for
everything - without considering the implications.

>
Where would you have had people publish MTA-STS information?  I would
have preferred DNS, but I don't think that HTTPS is the worst thing in
the world.

DANE is the DNS based solution and it works quite nicely.  We didn't
need MTA-STS.  We needed more push for DNSSEC everywhere.

There are a few things about MTA-STS which doesn't align very well with
traditional email configurations.  One thing is the "trust all public
CAs" requirement, which also implies that you have to use a certificate
from one of those for your own server.  Another annoyance is that you
must set up a https service with a specific well-known DNS name for each
email domain you want to host. The protocol trusts DNS anyway, so I see
no reason the policy URL couldn't be configured in DNS.


Bjørn