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 · 8h 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 · 8h ago
not even most smtp servers, just his special setup
blueflow · 9h 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 · 9h ago
now I guess we understand why chrome is too dangerous for them to own from a monopolistic standpoint
DocTomoe · 8h 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 · 8h 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 · 5h 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 · 5h 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 · 8h ago
Isn’t Let’s Encrypt basically Google? Google pushed it by punishing the ranking of search results that didn’t use ssl.
> 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.
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 · 9h 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?
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 · 8h 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.
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 · 8h 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- · 7h 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 · 8h 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 · 7h ago
> Most SMTP traffic is encrypted nowadays
This is laughably and naively optimistic.
scandox · 9h 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 · 8h 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 · 8h 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 · 1h 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 · 8h ago
I wonder how many side gmail accounts their employees have to use
arccy · 8h ago
but delivery to means the receiving end is a server, so they just need server auth TLS certs, not client auth.
scandox · 8h 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 · 9h ago
Does anyone's mail server accept (much less trust) publicly-trusted client certs anyway?
anonymousiam · 8h ago
The headline is misleading. They're killing SMTP CLIENT authentication certificates, not SMTP SERVER authentication certificates.
soneil · 6h ago
I have to go figure out exactly how this works now, as I'm likely affected.
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?
deepersprout · 8h ago
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?
londons_explore · 10h ago
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.
its-summertime · 7h ago
That's not whats happening, its the root certificates that the change applies to, e.g. lets encrypt, regardless of their views, can no longer use the same infrastructure to sign certs for anything other than TLS Server Authentication, lest they wish to see google's ire.
dandanio · 9h ago
If you can't secure your mail server, you certainly can't secure your web server. Letsencrypt, please rethink your decision!
arccy · 8h ago
most smtp servers don't use client certs, there's almost nothing that requires their clients to use client cert auth.
mail servers will continue working along just fine.
dlgeek · 8h ago
They don't have a choice - the decision comes from Chrome's root program and if they don't comply, LetsEncrypt would be distrusted by Chrome.
Attrecomet · 8h ago
Is it really that clear that Google has more power here? Whom would users blame if suddenly half their pages are falsely accused of being "untrusted"? Probably the browser, not LE, right?
phasmantistes · 7h ago
That's not leverage that a CA can use. If half the internet suddenly displays TLS warning interstitials, it doesn't make people mad at the CA, and it doesn't make people mad at their browser: it just _trains them to ignore such warnings_. That's a bad outcome all around, and one that a CA whose core purpose is improving security for end-users cannot condone.
samgranieri · 7h ago
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.
kbolino · 8h ago
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.
bigbuppo · 8h ago
Specifically this... the members of the CA/Browser Forum cartel have no idea how certificates are actually used in the real world, and even admit that when they all agreed to lower the maximum duration for certificates to 47 days.
arccy · 9h ago
smtp servers shouldn't have been doing this anyway...
the pki separation is good.
devrandoom · 9h ago
Why?
arccy · 8h ago
For a server auth cert, you validate that the thing you connect to has a cert for the same name.
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.
samgranieri · 7h ago
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
jamespo · 8h ago
I don't see why anyone wouldn't issue certificates from a private CA for this use case.
bbarnett · 9h ago
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.
hedora · 8h ago
I completely agree. For many years, I've gotten the impression the SSL ecosystem is designed to undermine endpoint security.
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.
Hilift · 8h ago
47 days isn't ridiculous if it is automated.
bbarnett · 8h ago
It's fine to allow short time frames, so those that can and will automate are able.
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.
fpoling · 8h ago
The automated setup makes it less likely that the private key leaks. That alones makes it a reasonable justification to shorten the validity timeframe to force automation.
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.
bbarnett · 7h ago
We have a single body deciding this, non-democratically. This isn't how RFCs used to work, how html used to be decided, how standards are crafted. The "big boys" aren't the standard setters of the older internet.
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?
fpoling · 4h ago
The web server needs access to the key to sign the reply so the key is accessed all the time.
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.
bigbuppo · 8h ago
Well, the one good excuse for the short durations is that the two main mechanisms for certificate revocation don't actually work very well.
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.
devmor · 8h ago
The logic behind it is to make the internet more onerous and annoying for individuals to have control over. The more active responsibility you must have in taking part in the internet, the more of that responsibility you will relinquish to the corporations that wish to control it.
arccy · 8h ago
password expiry was bad only because humans were in the loop.
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.
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.
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.
Do most SMTP server require, or even use, certs issued by a CA?
[1]: https://letsencrypt.org/2025/05/14/ending-tls-client-authent...
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.
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.
> 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.
This is laughably and naively optimistic.
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
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?
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.
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.
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.
(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.
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.
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.
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.