Re: Massive change in Public Cert behaviour coming soon

[brent saner via NANOG <nanog () lists nanog org>]

On Mon, May 19, 2025, 05:44 Christian de Larrinaga via NANOG <
nanog () lists nanog org> wrote:

> Chris Adams via NANOG <nanog () lists nanog org> writes:
>
> > Once upon a time, William Herrin <bill () herrin us> said:
> > > On Sat, May 17, 2025 at 4:23 PM Colin Constable via NANOG
> > > <nanog () lists nanog org> wrote:
> > > > Is anyone else worried about this? We use public certs for client
> auth in a
> > > > number of cases.
> > > >
> > > >  https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
> > >
> > > Does seem like it might have an impact on SMTP...
> >
> > Who is using Let's Encrypt web server certs for SMTP client
> > authentication?
>
> I am quite extensively - I should note that several hosting scripts that
> deploy web/email/mysql etc services LAMP stacks etc use the tls cert
> provided to the domain hosted on a "server" also for smtp servers with a
> dotted line to mailman where that is also installed. Those certs aren
> these days almost always going to be Lets Encrypt

Your users send mail with a Let's Encrypt *client certificate*? Meaning
they log into the SMTP server to gain the ability to send *originating
mail* with an LE cert? (MUA -> MTA)
I'd recommend they not do that. Use a private CA for clients if you're
doing mTLS auth.

If they are simply using TLS to connect to the mail server and logging in
with a username/password instead of/and don't need a *client certificate*,
they *aren't* using LE certs for authentication and are wholly unaffected
by this change.

This is wholly different from delivering mail to other domains (MTA -> MTA).

That doesn't use id-kp-clientAuth at all whatsoever either, and has been
pointed out, most CAs never even issued certs with it set.

You'll be fine.


> DKIM, SPF, DMARC are already very fussy and can be fiddly as it is.

True, but a welcome change IMHO. They really do cut down on spam and rogue
SMTP.


> I don't see the benefit in having separate certs for each application on
> a domain/zone beyond having yet another "vital" thing to be broken and
> so having to keep an eye on with all the hassle and cost that can imply.

You don't need to, you can reuse certs for multiple services if you have
multiple running within the same identity (typically FQDN).
This change literally only affects *mTLS*, which very few implementations
use. If you were using it, you'd know you were using it.


> Also I am not entirely clear what the implications of this change means
> as it is not spelt out.  Will we have to setup a private PKI for each
> smtp / domain instance once LE bows to the will of the great google
> thought policeman in its cloud?

Nope. You'll be fine using LE certs for SMTP. You're only affected if doing
mTLS for SMTP, and if you are you'd know you are.


If so are there any tooling / scripts / I can add to keep continuity?
> e.g., acme equivalent to self generate a cert and will this be
> recognised as a valid cert rather than fall into the self signed ghetto
> that the web browser CA lists like to shove the rest of us into?

"Valid" and "verified" are kind of tricky in TLS/X.509. The reason LE certs
are valid in browsers, mail client software, etc. is because their
intermediate is signed as an issuer by the ISRG root. The ISRG root is
recognized as a trusted authority by most/all devices' trust stores. (This
is why you need to include the intermediate cert AND the leaf or "server"
certificate -- so the remote end has a complete "chain" to verify.)

In other words, device A has ISRG root certificate installed and trusted.

ISRG signs LE's certificate and grants it issuer.
LE's certificate then sign your server's certificate (the leaf).

For a private CA to be trusted, you'd need to petition each and every trust
store distributor to include your root as something called a trust anchor.
Mozilla, Google, Apple, and Microsoft are generally the ones that'd get you
the most coverage (Linux distros usually use Mozilla's, etc. for their
system trust store).

This is...a process. A long, arduous process and each trust store
distributor has their own rigorous set of rules (like Google now requiring
that issued leaf certs not have id-kp-clientAuth set).

The alternative is to explicitly add your root as a trusted anchor to *each
device*. This is easy in a corporate environment through config management,
GPOs, etc. but good luck with the public at-large. (Sidenote, you should
only install and trust roots you are confident are safe. Private CAs are
what make transparent proxies able to decrypt HTTPS traffic to domains the
org does not own, for instance.)

So TL;DR: no. There's not just some script or tool you can run to get your
private CA added as a "wide-trust"/"widely-trusted" anchor.


> It also begs a question. If running one's own certs authority pki for
> email, apps, messaging, tunnels and so on are so great why not great for
> my websites and web apps as well?

It's great for *intranet*, which is where you'd typically find mTLS/mTLS
auth.

For public-facing, you want a cert from a wide-trust (or one of its
intermediates- like Let's Encrypt) because you do not have the ability to
install an anchor on foreign/general public devices. (For good reason.)
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/KTI7IBTK75HX2DASOCWEZPTNDL4X3UK4/