[lamps] Re: TLS Client Certificates; a survey

[Nico Williams <[e-mail]>]

On Tue, Mar 24, 2026 at 06:36:16PM -0700, Wei Chuang wrote:
> On Mon, Mar 23, 2026 at 6:18 PM Seo Suchan <[e-mail]> 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.
> 
> Due to the policy change noted in this thread, we will move to serverAuth
> only EKU for both SMTP-IN and OUT.   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.

They will almost certainly not be able to change their configuration.
The spec says your certificates need clientAuth, so why would an
implementor add a configuration parameter to allow clients that present
serverAuth certificates as client certs?

> [...]
> Furthermore, it sounds like some of the CAs in the CABF are thinking about
> a WG for Client Authentication.

Not much time before remaining extant clientAuth certificates expire.
You're racing against time.

Either you will a) ask people (and their MTA vendors) to patch to break
rules that -presumably- the Chrome Root Program wants enforced, b) have
to stop supporting client certs, or c) have to get the Chrome Root
Program to reconsider and/or revise their no-client-certs rule.

We really should have had many more EKUs long ago, so that the Chrome
Root Program could have allowed just client certs for MTAs, but that's
not possible now.

Confessing to being quite amused by all of this,

Nico
--