[lamps] Re: TLS Client Certificates; a survey

[Viktor Dukhovni <[e-mail]>]

On Tue, Mar 24, 2026 at 06:36:16PM -0700, Wei Chuang wrote:

> > what's gmail currently doing? I don't run mail server so I don't know
> > what cert it sends for smtp
> 
> Currently for SMTP-IN TLS, Gmail publishes an entity TLS certificate
> w/ serverAuth only EKU, and for SMTP-OUT, publishes serverAuth and
> clientAuth EKUs.

I am very surprised to hear that Gmail presents client credentials in
the SMTP-OUT direction?  Why is this done?  Postfix SMTP-IN servers
do not request client credentials (certificates and/or raw public keys),
and by default and in the majority of configurations Postfix SMTP-OUT
servers do not present clientcrdentials, even if the server happens to
ask.  I expect the same is true in Exim.

> Due to the policy change noted in this thread, we will move to serverAuth
> only EKU for both SMTP-IN and OUT.

Well, that policy change rules out use of WebPKI certificates (perhaps
more precisely those issued by CAs in the Chrome root programme) in the
SMTP-OUT direction.  Any "serverAuth"-only certificate presented by an
SMTP client (SMTP-OUT MTA), violates the express key purpose of the
certificate, and should (barring optional work-arounds along the lines
of the patch I posted) result in the certificate failing validation.

I don't see why one might expect just sending "serverAuth" certificates
as a TLS client would be expected to work, except by prior arrangement
with specific servers known to tolerate this, or those that do not
actually validate CA trust in any presented client credentials.

> FWIW we've started a small pilot deployment of serverAuth only for
> SMTP-OUT and saw a few domains that returned a SMTP 5xx error.  We're
> trying to reach out to them to understand what in their configuration
> is causing this.

Well, if they:

    1. Only accept traffic from Gmail when the SMTP client presents
       a "valid" (chaining to a trusted CA) certificate.
    2. Use a typical TLS software stack that checks at least the EE
       EKU extension.

then of course they'll refuse to accept the presented credentials.

> I also wanted to note a closely related CABF [e-mail]
> thread "Client Authentication - Initial investigation
> <https://groups.google.com/a/groups.cabforum.org/g/public/c/Kna_osq-6F8?e=48417069>"
> as I think several of the CAs are asking very similar questions
> concurrently.  In particular Ryan Hurst noted in that thread that there is
> a very important distinction for client certificates between "human
> identity" and "machine/service identity" uses, which may simplify or
> descope some of the problematic aspects of client certificates.
> Furthermore, it sounds like some of the CAs in the CABF are thinking about
> a WG for Client Authentication.

If possible, please keep us (or at least just me) apprised of any
substantive changes that come out of these conversations.

-- 
    Viktor.  🇺🇦 Слава Україні!