Hey there all,

It seems in sendmail if you configure:

define(`confCACERT_PATH', `CERT_DIR')
define(`confCACERT', `CERT_DIR/cacert.pem')

(Where cacert.pem is the big long list of trusted roots, in a single file)...

Then sendmail will, by default, request a client certificate signed by any of those CA's. Either can be used to validate connections as a client, but only the monolithic list can be sent when running as a server.

Postfix seems to instruct that asking for a client cert is only something you want to do in rare circumstances (like, for relaying), and typically only want to specify something like an internal CA.

Is this still a best practice?

The most recent doc I can find on sendmail.org is from several versions ago (and that had to be found with an external google search) https://www.sendmail.org/~ca/email/doc8.12/cf/m4/starttls.html

Am 26.09.2022 um 14:06:44 Uhr schrieb Gushi:

> The most recent doc I can find on sendmail.org is from several
> versions ago (and that had to be found with an external google
> search) https://www.sendmail.org/~ca/email/doc8.12/cf/m4/starttls.html

A documentation for the current version is included in the tarball.

ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.17.1.tar.gz
https://ftp.sendmail.org/sendmail.8.17.1.tar.gz

Go to the subfolder cf an read README.

Gushi <gushimailtest@gmail.com> wrote:
> Hey there all,

Hi stranger.

> It seems in sendmail if you configure:
> [... CACERT_DIR vs. CACERT ...]
> Then sendmail will, by default, request a client certificate signed by any
> of those CA's. Either can be used to validate connections as a client, but
> only the monolithic list can be sent when running as a server.

at least what you express by the combination of words you use in this
posting you heavily misunderstand what is used for which purpose.

For shure there is nothing sent in the TLS handshake that specifies a
list of root certificates with which a possibly exepted client
certificate has to be signed.

As far as I know CACERT_DIR and CACERT are kind of mutually exclusive.
So either you specify a directory which contains accepted root
certificates and theire hashes as links to them or you specify a single
file which contains all accepted root certificates.

Neither is sent to the other side!

It also depends on the TLS library used which of both is actually working.
I remember that at least in the past GNUtls was just supporting the single
file solution.
Using a single file with just a few root certs also makes it easier to
maintain a subset of generally excepted root certs just for the use for
secured mail exchange.

What is actually crucial is that your "SERVER_CERT" file also contains
possible intermediate CA certs so that your server cert can be verified
even if - what is very likely the case - the remote system doesn't know
these intermediate ca certs. And if you run you own CA you should also
put this cert into the file so that the remote admins have the chance to
extract your CA cert and put it into the trusted certs store or better:
you should maintain approprate informations in your certs and offer the
CA cert publicly somewhere (at the location specified in the certs).

> [...]

Best regards,
Henning
--
"nobody is perfect."
-- Nobody ;)

Gushi wrote:

> define(`confCACERT_PATH', `CERT_DIR')
> define(`confCACERT', `CERT_DIR/cacert.pem')

> Then sendmail will, by default, request a client certificate signed by any
> of those CA's. Either can be used to validate connections as a client, but

But the client can ignore that...

> Postfix seems to instruct that asking for a client cert is only something
> you want to do in rare circumstances (like, for relaying), and typically
> only want to specify something like an internal CA.

> Is this still a best practice?

doc/op.*
6.6.1. Certificates for STARTTLS

When acting as a server, sendmail requires
X.509 certificates to support STARTTLS: one as cer-
tificate for the server (ServerCertFile and corre-
sponding private ServerKeyFile) at least one root
CA (CACertFile), i.e., a certificate that is used
to sign other certificates, and a path to a direc-
tory which contains (zero or more) other CAs (CAC-
ertPath). The file specified via CACertFile can
contain several certificates of CAs. The DNs of
these certificates are sent to the client during
the TLS handshake (as part of the Certifi-
cateRequest) as the list of acceptable CAs. How-
ever, do not list too many root CAs in that file,
otherwise the TLS handshake may fail; e.g.,

error:14094417:SSL routines:SSL3_READ_BYTES:
sslv3 alert illegal parameter:s3_pkt.c:964:SSL alert number 47

You should probably put only the CA cert into that
file that signed your own cert(s), or at least only
those you trust.

> The most recent doc I can find on sendmail.org is from several versions ago

As someone already mentioned: use the docs which come with your
version of sendmail

--
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.

Henning Hucke wrote:
> Gushi <gushimailtest@gmail.com> wrote:

> > Then sendmail will, by default, request a client certificate signed by any
> > of those CA's.

> For shure there is nothing sent in the TLS handshake that specifies a
> list of root certificates with which a possibly exepted client
> certificate has to be signed.

Hmm, where did you get that info?

> As far as I know CACERT_DIR and CACERT are kind of mutually exclusive.

That's incorrect.

> Neither is sent to the other side!

See the fine documentation (doc/op.*):
The file specified via CACertFile can
contain several certificates of CAs. The DNs of
these certificates are sent to the client during
the TLS handshake (as part of the Certifi-
cateRequest) as the list of acceptable CAs. How-
ever, do not list too many root CAs in that file,
otherwise the TLS handshake may fail; e.g.,

--
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.

Am 27.09.2022 um 05:00:57 Uhr schrieb Claus Aßmann:

> As someone already mentioned: use the docs which come with your
> version of sendmail

It would be very helpful to update the documentation that is on the
website because that is what people find when they use a search engine
to find stuff.

Marco Moock wrote:

> It would be very helpful to update the documentation that is on the

I can either remove it or leave it... In the former case people
will probably find other outdated info "on the web".

--
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.

Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org> wrote:
> [...]
>> Neither is sent to the other side!
>
> See the fine documentation (doc/op.*):
> The file specified via CACertFile can
> contain several certificates of CAs. The DNs of
> these certificates are sent to the client during
> the TLS handshake (as part of the Certifi-
> cateRequest) as the list of acceptable CAs. How-
> ever, do not list too many root CAs in that file,
> otherwise the TLS handshake may fail; e.g.,

Hi all.

I freely admit that I was wrong.

There is a german saying "Man wird alt wie 'ne Kuh und lernt immer noch
dazu" which is in english more or less "You grow old like a cow and
still learn something new".

I'm no SSL/TLS expert at all, possibly a little less less a X.509
expert but I already digged into some depth of the SSL/TLS protocol.
Nonetheless I did not yet know this detail of the certificate request
phase. Or to be more precise: I'm quite shure that I already knew it
but so far it was obviously too seldom a relevant aspect of the
investigations I did.

Good to know.

Best regards
Henning
--
How many bits would a BitBlit blit if a BitBlit could blit bits?
-- macanespie@waves.pas.ti.com in <1993Nov16.130625.1@waves.pas.ti.com>

On Monday, September 26, 2022 at 10:41:58 PM UTC-7, Marco Moock wrote:
> Am 26.09.2022 um 14:06:44 Uhr schrieb Gushi:
>
> > The most recent doc I can find on sendmail.org is from several
> > versions ago (and that had to be found with an external google
> > search) https://www.sendmail.org/~ca/email/doc8.12/cf/m4/starttls.html
> A documentation for the current version is included in the tarball.
>
> ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.17.1.tar.gz
> https://ftp.sendmail.org/sendmail.8.17.1.tar.gz
>
> Go to the subfolder cf an read README.

cf/README specifies some options I need to set, but then says:

"See doc/op/op.{me,ps,txt} for more information about these options,
especially the sections ``Certificates for STARTTLS'' and ``PRNG for
STARTTLS''."

doc/op/op.txt doesn't exist, and if we're at the point where I need to load a postscript file to read my documentation, we've lost. (Happily, Preview on my mac will at least convert it).

This is why people are searching google, and finding something (even something outdated) on Sendmail.org is going to be what people read and follow.

Apache and BIND also embed their documentation, but they have readable web versions as well.

-Dan

On Tuesday, September 27, 2022 at 2:00:59 AM UTC-7, Claus Aßmann wrote:
> Gushi wrote:
>
> > define(`confCACERT_PATH', `CERT_DIR')
> > define(`confCACERT', `CERT_DIR/cacert.pem')
> > Then sendmail will, by default, request a client certificate signed by any
> > of those CA's. Either can be used to validate connections as a client, but
> But the client can ignore that...
> > Postfix seems to instruct that asking for a client cert is only something
> > you want to do in rare circumstances (like, for relaying), and typically
> > only want to specify something like an internal CA.
>
> > Is this still a best practice?
> doc/op.*
> 6.6.1. Certificates for STARTTLS
>
> When acting as a server, sendmail requires
> X.509 certificates to support STARTTLS: one as cer-
> tificate for the server (ServerCertFile and corre-
> sponding private ServerKeyFile) at least one root
> CA (CACertFile), i.e., a certificate that is used
> to sign other certificates, and a path to a direc-
> tory which contains (zero or more) other CAs (CAC-
> ertPath). The file specified via CACertFile can
> contain several certificates of CAs. The DNs of
> these certificates are sent to the client during
> the TLS handshake (as part of the Certifi-
> cateRequest) as the list of acceptable CAs. How-
> ever, do not list too many root CAs in that file,
> otherwise the TLS handshake may fail; e.g.,
>
> error:14094417:SSL routines:SSL3_READ_BYTES:
> sslv3 alert illegal parameter:s3_pkt.c:964:SSL alert number 47
>
> You should probably put only the CA cert into that
> file that signed your own cert(s), or at least only
> those you trust.

Follow on question(s) then, since it's a bit unusual in open source software to have to attach the root cert: How does Sendmail use confCACERT, when acting only as a server? Does it validate its own cert at startup time? Does it auto-attach the CA cert to the server chain when doing the SSL handshake?

Put another way -- if I put a totally different CA cert than what signed my cert and key, would sendmail refuse to speak SSL or would handshakes fail in some way?

Is this option still required if I have set srv_features v?

Am 27.09.2022 um 06:14:30 Uhr schrieb Claus Aßmann:

> I can either remove it or leave it... In the former case people
> will probably find other outdated info "on the web".

We should update the web documentation.
Is it possible to include the content of the doc in the tarball on the
sendmail website, so people can find documentation that applies to the
current sendmail version?

It should be enough to provide just the text in an HTML file that is on
the web server. In my opinion there is no need for a design.

Gushi wrote:

> doc/op/op.txt doesn't exist, and if we're at the point where I need to load

cd doc/op && make op.txt

--
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.

Marco Moock wrote:

> We should update the web documentation.

Who is "We"?

> Is it possible to include the content of the doc in the tarball on the

Did you check "the tarball"?

....
sendmail-8.17.1.22/doc/op/op.ps
sendmail-8.17.1.22/doc/op/op.me
sendmail-8.17.1.22/doc/op/Makefile
sendmail-8.17.1.22/doc/op/README

--
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.

Gushi wrote:

[please trim your quoting!]

> Follow on question(s) then, since it's a bit unusual in open source software
> to have to attach the root cert: How does Sendmail use confCACERT, when

It is? AFAICT other MTAs using OpenSSL do the same...
because they use the same code base for the OpenSSL integration.

> acting only as a server? Does it validate its own cert at startup time?

sendmail uses OpenSSL - I doubt OpenSSL has this behaviour.

> Does it auto-attach the CA cert to the server chain when doing the SSL
> handshake?

Whatever OpenSSL does...

> Put another way -- if I put a totally different CA cert than what signed my
> cert and key, would sendmail refuse to speak SSL or would handshakes fail in
> some way?

Have you tried it?
I doubt it will fail.

> Is this option still required if I have set srv_features v?

Whatever OpenSSL requires to initialize...

--
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.

Am 29.09.2022 um 02:07:18 Uhr schrieb Claus Aßmann:

> Did you check "the tarball"?

Yes, I did, but the reason for my suggestion is that it makes it easier
to find the information for people who don't know that it is included
in the tarball.

Marco Moock wrote:

> Yes, I did, but the reason for my suggestion is that it makes it easier
> to find the information for people who don't know that it is included
> in the tarball.

If you have an idea how to do that, please implement it.

--
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.

Am 29.09.2022 um 06:11:09 Uhr schrieb Claus Aßmann:

> Marco Moock wrote:
>
> > Yes, I did, but the reason for my suggestion is that it makes it
> > easier to find the information for people who don't know that it is
> > included in the tarball.
>
> If you have an idea how to do that, please implement it.

Is there something against just providing the text from the doc in the
tarball in HTML files on the web server?

This should be rather easy to do.

Marco Moock wrote:

> Is there something against just providing the text from the doc in the
> tarball in HTML files on the web server?

Which web server?
www.sendmail.org?
Take a look -- maybe you can figure out who maintains it?

> This should be rather easy to do.

Says the person who doesn't do it...
Do you run a web server?
If so, why don't you "just do it"?
If it's "good", search engine will index it, right?

--
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.

Am 29.09.2022 um 06:37:39 Uhr schrieb Claus Aßmann:

> Marco Moock wrote:
>
> > Is there something against just providing the text from the doc in
> > the tarball in HTML files on the web server?
>
> Which web server?
> www.sendmail.org?
> Take a look -- maybe you can figure out who maintains it?

ok, I assume that you don't have control over the server at all
(proofpoint does), but you have control to your user directory on /~ca,
or is that guess wrong?

> > This should be rather easy to do.
>
> Says the person who doesn't do it...
> Do you run a web server?

Not at this time.

Marco Moock wrote:

> but you have control to your user directory on /~ca,

Of course I do.
So you want something and you want someone else to do it...

Here's how you get something done:
- you do it yourself.
- you pay someone to do it.
- you forbid your kids to do it.

Anyway: IMNSHO people should read the documentation which comes
with the software. Unfortunately there is too much software with
useless/incorrect documentation hence now people try to find stuff
"online" -- most of which is outdated or often just plain wrong.

--
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.

Am 29.09.2022 um 12:36:17 Uhr schrieb Claus Aßmann:

> - you do it yourself.

If I prepare such an HTML document with the doc of 8.17.1, would you
upload it?
Then I would give it a try and you can use it.

Marco Moock wrote:
> Am 29.09.2022 um 12:36:17 Uhr schrieb Claus Aßmann:

> > - you do it yourself.
^^^^^^^^^^^^^^^^^^

> If I prepare such an HTML document with the doc of 8.17.1, would you
> upload it?

No -- see above.

That's just extra work for each release - if I would do this
at all I would automated it and not use something from
someone else...

Bye.

--
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.

Gushi <gushimailtest@gmail.com> wrote:
> [...]
>
> Follow on question(s) then, since it's a bit unusual in open source
> software to have to attach the root cert: How does Sendmail use
> confCACERT, when acting only as a server? Does it validate its own
> cert at startup time? Does it auto-attach the CA cert to the server
> chain when doing the SSL handshake?
>
> Put another way -- if I put a totally different CA cert than what
> signed my cert and key, would sendmail refuse to speak SSL or would
> handshakes fail in some way?
>
> Is this option still required if I have set srv_features v?

I don't know how attaching "the root certificate" relates to "open
source software" and it's actually a not so bad idea to include all
certificates into the certificate chain including the root certificate
(especially if you can't be shure that the remote side already knows it).

Could you please first make yourself a little more familiar with X.509
certificates, SSL/TLS and please just actually *read* the documentation
you have directly at the tip of your fingers!?

Usually it makes no sense to try to verify your own certificates. Might
it simply be because it always can be a "simple" self signed certificate
which might be totally ok for certain purposes.

Second there are no actual certificates transfered (in the request phase!)
- and this time I hopefully understood correctly what I actually read in
the meantime about the TLS handshake dialogue - but simply the
distinguished names (DNs) of the certificates included in the file
specified via "confCACERT"
(Also see "https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2").

And third: exactly the lowercase "v" requests client certificates
("Request a client certificate (default)").

The file specified by "confCACERT" is - as far as I know and as far as I
realised it in my 25 years of sendmail usage, gosh am I old :-) - just
used as a source of DNs sent in the client certificate request. Though I
didn't read the source for you (which I possibly did in the past but didn't
keep this specific information in my mind for this long).

Regards
Henning
--
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Marco Moock <mo01@posteo.de> wrote:
> Is there something against just providing the text from the doc in the
> tarball in HTML files on the web server?
> This should be rather easy to do.

Hi there,

converted the sendmail 8.17.1 documentation as html. Think I might update
it after every (non-beta) release. Maybe some search engine will
pick it up: https://help.idkom.de/sendmail/op.html

Am 30.09.2022 um 07:51:41 Uhr schrieb Andreas S. Kerber:

> converted the sendmail 8.17.1 documentation as html. Think I might
> update it after every (non-beta) release. Maybe some search engine
> will pick it up: https://help.idkom.de/sendmail/op.html

Great. If you like, you can also specify the headlines as html
headlines, so it is possible to link certain parts directly.