1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • Does sendmail still request a client cert by default?

    From Gushi@21:1/5 to All on Mon Sep 26 14:06:44 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Tue Sep 27 07:41:55 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to Gushi on Tue Sep 27 05:42:33 2022
    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 ;)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Henning Hucke on Tue Sep 27 05:06:07 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Gushi on Tue Sep 27 05:00:57 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Tue Sep 27 11:18:48 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to @esmtp.org on Wed Sep 28 05:33:43 2022
    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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gushi@21:1/5 to Marco Moock on Wed Sep 28 10:13:16 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gushi@21:1/5 to All on Wed Sep 28 10:36:04 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Gushi on Thu Sep 29 02:04:58 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Gushi on Thu Sep 29 02:22:51 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to Gushi on Fri Sep 30 06:14:30 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)