[lamps] Re: TLS Client Certificates; a survey

[Wei Chuang <[e-mail]>]

On Tue, Mar 24, 2026 at 7:20 PM Viktor Dukhovni <[e-mail]>
wrote:

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


We observed that for 38% of outbound messages, the server requests client
the certificates.


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

I would argue that the SMTP MTA-to-MTA traffic model differs from the
original WWW TLS client-server model envisioned in RFC 5280, Section
4.2.1.12 anyways.  Since clientAuth will soon be unavailable, serverAuth is
the closest fit for SMTP-OUT certificates.  Further, clientAuth
certificates for the most part lack governance behind their content
(besides closed ecosystems like X9), so beware.


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

I'm not part of those conversations.  Someone pointed out those discussions
to me, so I wanted to pass that along as I thought they would be relevant
and help inform the conversation here.
-Wei