Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?utf-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Mon, 11 Nov 2024 17:09:13 +0100
Organization: m
Lines: 40
Message-ID: <87wmh9u506.fsf@miraculix.mork.no>
References: <87a5enl3x6.fsf@miraculix.mork.no> <vfrdfo$1mfaa$3@dont-email.me>
	<vfsg90$odd$1@news.misty.com>
	<47f875facd6badf3579f93f3be2ee26c@www.novabbs.com>
	<vfv2bs$sd0$1@news.misty.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 11 Nov 2024 17:09:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3b01bd0aa1bc195254c03061af55912c";
	logging-data="1121815"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19CtMCB9kvfxaGLJGtyjZaT"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:Oa4q8YU7kMplUarWQ9DoKiG9iWE=
	sha1:taAG+fBUUM8paij4aAhnXQwH6A4=
Bytes: 2795

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