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

  • Client Auth certificates, threat or menace?

    From John Levine@21:1/5 to All on Tue May 20 16:35:01 2025
    Let's Encrypt issues the vast majority of signed TLS certificates these days. They rececently said they will end the option to sign Client Authentication certificates, and only do the more common Server Authentication.

    By my understanding, the only place that a mail system uses Client Authentication certs is that a submission client can present a cert
    for SMTP AUTH rather than a username and a password. It's a niche
    feature and the normal way to do it is for the mail system to set up
    its own private CA and sign the users' certs, so it can just check
    that it sees its signature.
    encrypt.

    This thread at Let's Encrypt claims that this will break sendmail because it checks for the Client bit when it's sending mail. That seems wrong but I figure it wouldn't hurt to ask.

    https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427

    --
    Regards,
    John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to John Levine on Tue May 20 14:48:01 2025
    John Levine wrote:

    By my understanding, the only place that a mail system uses Client Authentication certs is that a submission client can present a cert
    for SMTP AUTH rather than a username and a password. It's a niche

    There is more, see cf/README: Relaying.

    This thread at Let's Encrypt claims that this will break sendmail because it checks for the Client bit when it's sending mail. That seems wrong but I

    sendmail doesn't care about "EKU":

    sendmail.org.cert.pem
    Certificate:
    Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Organization Validation Secure Server CA
    X509v3 extensions:
    X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
    X509v3 Basic Constraints: critical
    CA:FALSE
    X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

    that cert is used for the sendmail.org SMTP server and client
    and my host verifies it just fine:
    client_ip=50.19.116.123, client_name=mc.sendmail.org., starttls=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, cipher_bits=256, verify=OK, cert_subject=/C=US/ST=California/O=Proofpoint,+20Inc./CN=sendmail.org, cert_issuer=/C=GB/ST=Greater+20Manchester/L=Salford/
    O=Sectigo+20Limited/CN=Sectigo+20RSA+20Organization+20Validation+20Secure+20Server+20CA

    --
    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 John Levine@21:1/5 to All on Tue May 20 20:18:26 2025
    According to Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>:
    John Levine wrote:

    By my understanding, the only place that a mail system uses Client
    Authentication certs is that a submission client can present a cert
    for SMTP AUTH rather than a username and a password. It's a niche

    There is more, see cf/README: Relaying.

    Well, OK, but in practice that's a special case of submission.

    sendmail doesn't care about "EKU":

    sendmail.org.cert.pem
    Certificate:
    Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Organization Validation Secure Server CA
    X509v3 extensions:
    X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
    X509v3 Basic Constraints: critical
    CA:FALSE
    X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

    That's not very helpful since that cert has both key usages.

    The claim, which I'm not sure I believe, is that the calls to openssl have default values
    that want the client flag.
    --
    Regards,
    John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to John Levine on Wed May 21 01:33:02 2025
    John Levine wrote:

    The claim, which I'm not sure I believe, is that the calls to openssl
    have default values
    that want the client flag.

    Maybe you can give it a try? Or those who make the claim can show
    the problem?

    It seems to be real based on the openssl doc:

    CERTIFICATE EXTENSIONS
    The -purpose option checks the certificate extensions and
    determines what the certificate can be used for. The actual
    checks done are rather complex and include various hacks and
    workarounds to handle broken certificates and software.
    ...
    ! The extended key usage extension places additional restrictions
    ! on the certificate uses. If this extension is present (whether
    ! critical or not) the key can only be used for the purposes
    ! specified.

    A complete description of each test is given below. The
    comments about basicConstraints and keyUsage and V1 certificates
    above apply to all CA certificates.

    SSL Client
    The extended key usage extension must be absent or include
    the "web client authentication" OID. keyUsage must be
    absent or it must have the digitalSignature bit set.
    Netscape certificate type must be absent or it must have
    the SSL client bit set.

    --
    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 All on Thu May 22 03:07:27 2025
    Certificate:
    X509v3 extensions:
    X509v3 Extended Key Usage:
    TLS Web Server Authentication

    Used by client: no error in client, but the server shows
    status=unsupported certificate purpose
    hence the cert is basically unusable for a client -
    as some people claimed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to @esmtp.org on Thu May 22 20:08:09 2025
    It appears that Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org> said:
    John Levine wrote:

    The claim, which I'm not sure I believe, is that the calls to openssl
    have default values that want the client flag.

    Maybe you can give it a try? Or those who make the claim can show
    the problem?

    I was hoping you or someone were familiar enough with the code that we didn't have to do experiments.

    It seems to be real based on the openssl doc:

    CERTIFICATE EXTENSIONS
    The -purpose option checks the certificate extensions and
    determines what the certificate can be used for. The actual
    checks done are rather complex and include various hacks and
    workarounds to handle broken certificates and software.
    ...
    ! The extended key usage extension places additional restrictions
    ! on the certificate uses. If this extension is present (whether
    ! critical or not) the key can only be used for the purposes
    ! specified.

    A complete description of each test is given below. The
    comments about basicConstraints and keyUsage and V1 certificates
    above apply to all CA certificates.

    SSL Client
    The extended key usage extension must be absent or include
    the "web client authentication" OID. keyUsage must be
    absent or it must have the digitalSignature bit set.
    Netscape certificate type must be absent or it must have
    the SSL client bit set.

    Right. It would make sense to look for the client extension when checking a cert
    presented for SMTP AUTH, otherwise not. Any idea whether the code does that?

    --
    Regards,
    John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to All on Thu May 22 20:09:25 2025
    According to Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>:
    Certificate:
    X509v3 extensions:
    X509v3 Extended Key Usage:
    TLS Web Server Authentication

    Used by client: no error in client, but the server shows
    status=unsupported certificate purpose
    hence the cert is basically unusable for a client -
    as some people claimed.

    I'm not worried about that since basically nobody uses client certs signed by a public CA.

    I was worried that some bug would look for it in server certs. That seems OK.

    --
    Regards,
    John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to John Levine on Fri May 23 03:44:06 2025
    John Levine wrote:

    Right. It would make sense to look for the client extension when
    checking a cert
    presented for SMTP AUTH, otherwise not. Any idea whether the code does that?

    What do you mean by "a cert presented for SMTP AUTH"?
    Certs are handled during the TLS handshake.

    AuthMechanisms
    List of authentication mechanisms for AUTH
    (separated by spaces). The advertised list
    of authentication mechanisms will be the in-
    tersection of this list and the list of
    available mechanisms as determined by the
    Cyrus SASL library. If STARTTLS is active,
    EXTERNAL will be added to this list. In
    that case, the value of {cert_subject} is
    used as authentication id.

    If the server cannot "verify" the client cert, then obviously it
    won't be used - and as explained elsewhere openssl does not allow
    to verify a cert which is just for a "server".

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