Hacker Remix

Letsencrypt will kill SMTP server auth following Chrome CA policy change

57 points by Aissen 15 hours ago | 57 comments

CaptainFever 10 hours ago

The link is to a random Mastodon post ranting about the change. I think it would be better if it linked to the actual blog post from Let's Encrypt: https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

nashashmi 9 hours ago

The mastadon post should have linked to that. But he wanted to rant about its practical effects on the system, namely smtp servers. LE did not really mention how this impacts developers

Aissen 9 hours ago

The letsencrypt article is iterally the first link in the mastodon post, and indeed the mastodon post gives more context than letsencrypt's blog on the impact. As well as a link down-thread on where the rationale is in the Chrome root program.

arccy 9 hours ago

not even most smtp servers, just his special setup

blueflow 10 hours ago

Why is it Google that is making these rules? A company would not have this kind of power in a fair competition market.

WorldPeas 10 hours ago

now I guess we understand why chrome is too dangerous for them to own from a monopolistic standpoint

DocTomoe 9 hours ago

You could say that about any large browser vendor, and I seem to remember there having been a 'free' CA (OpenCA? FreeCA?) in the late 2000s, early 2010s which lost Firefox support over something small as well.

The truth is - the whole infrastructure depends on trust. And of one vendor of a major browser decides to no longer trust a CA, for whatever reason, the CA becomes essentially worthless overnight.

Yes, people theoretically can install their own Root certificates. No, 99,99% of internet users won't.

WorldPeas 9 hours ago

The problem here is conflict of interest, Google is very interested in maintaining the GMail monopoly, that is likely the #1 reason people have google accounts. Correct me if I'm wrong but no other vendors save for edge(MS) and safari(Apple) own a mail service, a browser should be an impartial connection to an open ecosystem, and especially in Apple or MSIE's case we can see how this can be severely abused.

DocTomoe 6 hours ago

No, I'm with you. this clearly is just another sneaky move by one of the big guys. Browsers should be impartial. And, - personally - I think CA management should be OS-level, not browser-level, though that only moves the problem to another potential abuser.

In the end, the whole trust-based encryption of http concept is inheriently faulty and abusable.

Doesn't mean there is not the problem of 'trust' not being enforceable.

aaomidi 7 hours ago

Google is making these rules for it's own root program. There are multiple root programs out there.

Also, root programs have their own requirements, and then the general baseline requirements discussed in the CA/B forum.

The industry self-regulates pretty darn well.

jaoane 10 hours ago

Isn’t Let’s Encrypt basically Google? Google pushed it by punishing the ranking of search results that didn’t use ssl.

toomuchtodo 10 hours ago

No, Let's Encrypt is an independent entity.

https://www.abetterinternet.org/about/

> ISRG is a California public benefit corporation, and is recognized by the IRS as a tax-exempt organization under Section 501(c)(3) of the Internal Revenue Code.

bityard 9 hours ago

But Google is one of their top sponsors: https://www.abetterinternet.org/sponsors/

toomuchtodo 9 hours ago

This only reduces their independence if they are making decisions based on that specific sponsorship. AWS and the German government (https://www.sovereign.tech/) are also sponsors at that level, for example. Maybe the US government should kick in some change?

rnhmjoj 10 hours ago

I've read the announcement[1] and I don't see how this deprecation has anything to do with SMTP. Is it because the sending MTA will present its own server certificate as a client certificate to the receiving MTA? I thought most of this traffic was outright unencrypted or opportunistically encrypted with self-signed certs.

Do most SMTP server require, or even use, certs issued by a CA?

[1]: https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

mjl- 9 hours ago

Most SMTP traffic is encrypted nowadays, at least "opportunistically", without verification.

Only with MTA-STS enabled for the server will an SMTP client (that's delivering to an SMTP server) verify the TLS certificate against PKI (with DANE, it's verified against "self-signed" or CA certs in DNS). (I'm the developer of a mail server that sets up TLS for SMTP with MTA-STS and DANE using Let's Encrypt certificates by default).

I have never heard of any SMTP server doing TLS client certificate authentication. I'm pretty sure there's no standard for that, so it can't be a requirement for all incoming email. It could be a requirement between parties that have made agreements about that explicitly. And theoretically, some mail servers could use it as a signal of authenticity of the sender. But email has other, standardized mechanisms for that. And I suspect you might see delivery failures if you start requesting TLS client cert authentication from all SMTP clients.

btown 9 hours ago

I imagine it's not used as an MTA-to-MTA signal, but rather for organizations where outbound messages, received by the org's SMTP server, should only be accepted when the internal sending device has a client certificate.

See, for instance: https://learn.microsoft.com/en-us/sharepoint/administration/...

Is it possible that orgs have been using Let's Encrypt to issue client certificates for devices on their network to be able to send internal emails over SMTP - to the devices of the old-school partner-level employees who won't use webmail, and to various physical devices on premises? Possibly.

The interesting thing to me is that LE wouldn't know whether this is happening, because they had been issuing combo server+client certificates with the "classic" profile, and wouldn't know which are being used for which purpose. And sure, it makes sense to separate out "tlsserver" and "tlsclient" - but why also add the punitive step of having tlsclient be a new but temporary thing that will go away in May 2026? I don't see any technical reason why they can't support tlsclient, on the new dedicated Google PKI for it, into the future.

phasmantistes 9 hours ago

The "tlsclient" profile will not be TLSClientAuth-only: it will have both the TLSServerAuth and TLSClientAuth profiles, like the default profile does today. It will exist solely for the purpose of helping people transition off of using Let's Encrypt certificates for mTLS. If they've been unaware of these conversations, their systems will break when the TLSClientAuth EKU is removed from the default profile. That will be their wake-up call, and then they can temporarily select the "tlsclient" profile to get a brief grace period to migrate their systems before the TLSClientAuth EKU is removed entirely.

mjl- 9 hours ago

Using tls client auth certificates for submission would make slightly more sense indeed. But who would request LE certificates to install them on desktops/phones of individuals? That sounds more complicated than managing your own client certificates.

In my mail server, accounts can use TLS client authentication with submission and imap. But only the public key in the certificate is used, to identify the account. No verification of name or before/after time. You just save the public key with an account, or remove it when you no longer want to allow it. No external CA to trust, or internal CA to run, and no automatic expiration of your connectivity.

As for LE: I think they want to keep things simple. AFAIK they are a relatively small organization. Every task they take on weighs on them. They also don't sign certificates for use with S/MIME.

rnhmjoj 9 hours ago

> I have never heard of any SMTP server doing TLS client certificate authentication. I'm pretty sure there's no standard for that, so it can't be a requirement for all incoming email.

> I suspect you might see delivery failures if you start requesting TLS client cert authentication from all SMTP clients.

Thanks, this aligns with my understanding of things. So, this issue is probably a big nothingburger.

KennyBlanken 8 hours ago

> Most SMTP traffic is encrypted nowadays

This is laughably and naively optimistic.

scandox 10 hours ago

Many systems will not deliver where encryption is not present. Some systems won't deliver without a certificate issued by a public CA. And some systems won't accept an LE cert but require something called OV(organizational validation).

gruez 10 hours ago

>Some systems won't deliver without a certificate issued by a public CA. And some systems won't accept an LE cert but require something called OV(organizational validation).

Which systems are these? Are they public email providers? Are they enterprises?

scandox 10 hours ago

Enterprises. Porsche.com corporate email for example won't deliver without an OV.

So once you're in the business of providing any kind of general email service you eventually have to deal with it.

Edit: Porsche corporate

TheNewsIsHere 3 hours ago

Volkswagen has similar policies regarding partners and vendors. If you want into that ecosystem they require that you setup specific mail routing policies and mutually authenticated CAs to exchange email.

jamespo 9 hours ago

I wonder how many side gmail accounts their employees have to use

arccy 9 hours ago

but delivery to means the receiving end is a server, so they just need server auth TLS certs, not client auth.

scandox 9 hours ago

That is true. I interpreted your last remarks as meaning you thought that most normal SMTP was outright unencrypted or opportunistically encrypted with self-signed certs.

andrewaylett 10 hours ago

Does anyone's mail server accept (much less trust) publicly-trusted client certs anyway?