Built a journalism ethics framework because no one else would
1 points by azaazal 21m ago 1 comments
Two black holes are eating away at a galaxy (news.berkeley.edu)
1 points by gmays 27m ago 0 comments
Letsencrypt will kill SMTP server auth following Chrome CA policy change
49 Aissen 47 5/16/2025, 9:24:37 AM social.wildeboer.net ↗
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.
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
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.
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.
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.
(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.
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.
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.
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.