Letsencrypt will kill SMTP server auth following Chrome CA policy change
social.wildeboer.net
social.wildeboer.net
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.
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.
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.
Do most SMTP server require, or even use, certs issued by a CA?
[1]: https://letsencrypt.org/2025/05/14/ending-tls-client-authent...
Which systems are these? Are they public email providers? Are they enterprises?
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
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.
> 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.
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.
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.
This is laughably and naively optimistic.
When my smtp server connects to, eg gmail's smtp server - I'd ordinarily consider my smtp server the client within the scope of that connection.
So am I supposed to present a tlsclient EKU within outbound connections and tlsserver to incoming connections?
(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.
It's not fine to force it. There's no logic behind it. Browser and OS updates can expire certificate authorities, and that's the only real reason people claim this is to be done.
And then if a certificate authority knows that it’s certificate root can be disabled quickly, it puts more pressure on them to follow the rules.
Of cause it means that those who still run setups where the certificate cannot be updated quickly will suffer. But then one still has option to run http.
For example, the more often you need to get a key, the more interactions you have where a leak may occur. If you get keys 36 times in 3 years, instead of once in 3 years, you're that many times more exposed.
Further, automation provides many edge cases for non-human monitored issues to occur. A process that requires human intervention at least requires someone to see the process. Automation can be setup years ago, and people may not even realise it is occurring. That doesn't help security. At all.
As I said, it's NIST forced password rotation all over again. Attempts to make things better, but the end result is worse.
And of course Google thinks this is all grant. After all, in their eyes small mail servers, hobby mail servers, small orgs doing it on their own are a hassle. Everyone should just use gmail, yes?
With automation LE style one typically creates an account with LE when one renews the key so there is no need to have an account password or similar which decreases the attack surface compared with any manual procedure.
So while I agree that Google and friends have too much power, in this case the decision was reasonable.
In other words, these idiots that got us into this mess didn't understand how anything works. These same idiots are now making decisions that only make sense if everyone operates like Google. The real world does not operate like Google.
Entertainment systems on aircraft and vessels, for example.
Other vessels too.
otherwise, for secure things you rotate secrets every time, like new encryption keys for every tls exchange, and a continuous cycling of keys for perfect forward secrecy in e2e messengers.
For instance, there were credible accusations that the NSA had a mole on the standardization committee back in the 90's. Their entire job was allegedly to promote things that increased implementation complexity and block things that simplified implementation.
SSL client certs (which this change is yanking) are great for convenience and security (assuming you trust the CA).
Frequently rotated certs lead to outages, and normalize needless credential rotations. If you believe your backend server is compromised, this is a good thing. However, in any scenario where you're achieving your security goals, that server isn't compromised (the data on it is probably more sensitive than the cert) and rotating the certificate frequently just makes it harder to detect a third party using a man-in-the-middle cert to transparently proxy it.
Speaking of which: If you can momentarily control a DNS record or if you are a cloud provider that controls all network paths to your customers, then you can use Lets Encrypt (or any of the ACME providers) to generate a MITM certificate + transparently proxy traffic.
For traffic I care about securing, I use things like wireguard or SSH trust on first use.
Does this break some custom setup?
They don't want your insecure mail server software to put your secure web server at risk.
mail servers will continue working along just fine.
the pki separation is good.
For a client cert issued by web pki, all you know is that they've somehow obtained a cert for some name, you don't know if it's legit or not, since it doesn't come from connecting to the name. So kind of useless for trust.
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.