I'm sorry for just asking instead of using the source (luke). This is
another of very few times I did it this way.

Which name exactly is checked if sendmail uses the SSL library to verify
a client certificate - or is the whole channel estabishing done by the
library in which case I will ask in another (more appropriate) place?

Is it the HELO/EHLO name, the dns reverse lookup name or something else?

Best regards,
Henning
--
In the first place, God made idiots;
this was for practice; then he made school boards.
-- Mark Twain

Henning Hucke wrote:

> Which name exactly is checked if sendmail uses the SSL library to verify
> a client certificate

None - certificates are verified against the list of CAs
which you specified.

However, sendmail allows you do any kind of check you want to perform
via its rulesets and some builtin features. See cf/README, section
"Allowing Connections" for the available features (and doc/op/op.*
for the rulesets)

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

On 2021-12-24, Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail@esmtp.org> wrote:

Hi Claus,

> Henning Hucke wrote:
>
>> Which name exactly is checked if sendmail uses the SSL library to verify
>> a client certificate
>
> None - certificates are verified against the list of CAs
> which you specified.

just to verify that I understand this correct: Beside checking the
validity of a client certificate with its issuing certification authority no
further checks are processed by default? So for instance a client cloud
present a certificate for "www.google.com" even if its HELO/EHLO name is
"smtp.example.com" and its reverse lookup
"ip-65-23-15.broadband-provider.com" as long as this certificate gets
verified by one of the CA certs in the specified or default storage place?

> However, sendmail allows you do any kind of check you want to perform
> via its rulesets and some builtin features. See cf/README, section
> "Allowing Connections" for the available features (and doc/op/op.*
> for the rulesets)

Uh! I think I'll write an appropriate rule set in the next few weeks to
verify more than that! :-)

Best regards
Henning
--
Honesty is for the most part less profitable than dishonesty.
-- Plato

Henning Hucke wrote:

> just to verify that I understand this correct: Beside checking the
> validity of a client certificate with its issuing certification authority no
> further checks are processed by default?

Correct. And even if the cert cannot be verified the TLS handshake
is NOT aborted.

> Uh! I think I'll write an appropriate rule set in the next few weeks to
> verify more than that! :-)

What requirements do you want to enforce?
And if you enforce them for TLS what happens when the client tries
again without a cert?
AFAICT many (most?) systems do not even present a client cert.
It doesn't seem to make much sense to penalize those which do...

IMHO it only makes sense to check certain conditions so allow a
client to do more things, e.g., get around certain other (anti-spam)
requirements or allow relaying.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.