Why is it Google that is making these rules? A company would not have this kind of power in a fair competition market.
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...
Does anyone's mail server accept (much less trust) publicly-trusted client certs anyway?
The headline is misleading. They're killing SMTP CLIENT authentication certificates, not SMTP SERVER authentication certificates.
This is precisely like NIST requirements to change your password frequently, which was well intended, but reduced security due to people not being able to recall their password.
(This is now reversed, of course)
Reducing certificate life to ridiculous time frames, making it difficult to obtain certificates, all for very dubious, extremely tiny and minor improvements in security. It's going to cause more harm than good, and in the end, will reduce not enhance security.
For example, many SMTP servers may revert to self-signed certs now.
I still don't understand what this breaks. I use a LE certificate for my smtp service, but as I understand it, other mail servers don't connect to it using a client cert, they just check that the cert deleivered is trusted. Or am I missing something?
Does this break some custom setup?
I assume the reasoning for the policy change is that allowing a single certificate to be used for many different uses puts a greater risk of the certificate private key being leaked.
They don't want your insecure mail server software to put your secure web server at risk.
smtp servers shouldn't have been doing this anyway...
the pki separation is good.
Let’s say I want to be in full control of my own email. I buy a domain, set things up securely, and use let’s encrypt to automate setting up a TLS cert.
Let’s say I’m not using something like Caddy which does all this for you, I’m using something like a systemd timer to get that new cert and reload nginx and my smtp server.
This ostensibly should still work next year like it does now, no?
FWIW, I’ve never even heard us using a tls client certificate for smtp connections.
Given that this is just due to a Chrome Root Store policy, it seems like a possible solution is to maintain two PKI root stores, one for browsers and one for servers. The server one can be a superset of the browser one, adding CAs that allow client auth. This way, you could request a client certificate from Let's Encrypt that works everywhere except a browser.
How would this affect s-mime, if anyone is still using that? If I want to send a really secure message that only the intended recipient can read, I’d use signal or sign and encrypt the message with GPG
I don't see why anyone wouldn't issue certificates from a private CA for this use case.
[dead]
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...