Remember the threads¹² about #LetsEncrypt removing a crucial key usage from certificates issued by them in predictive obedience to their premium sponsor Google?
We were at first concerned about #SMTP. While I had lived through this problem with #StartSSL by #StartCom back in 2011, I only had a vague recollection of Jabber but recalled in detail that it broke server-to-server SMTP verification (whether the receiving server acted on it or just documented it).
This means that it will soon no longer be possible at all to operate Jabber (XMPP) servers because the servers use the operating system’s CA certificate bundle for verification, which generally follows the major browsers’ root stores, which has requirements from the CA/Browser forum who apparently don’t care about anything else than the webbrowser, and so no CA whose root certificate is in that store will be allowed to issue certificates suitable for Jabber/XMPP server-to-server communication while these CAs are the only ones trusted by those servers.
So, yes, Google’s requirement change is after all breaking Jabber entirely. Ein Schelm, wer Böses dabei denkt.
Update: it also breaks the connections between domain registrars and registries, with most being unaware that there even is a problem at this time, let alone the crazily short timeframe. See the thread linked to in a self-reply, which also confirms that the CA/Browser forum is supporting Google in this (possibly by means of Google paying, my interpretation).
While nerdcert.eu/ by @jwildeboer would in theory help, it’s not existent yet, and there’s not just the question of when it will be included in operating systems’ root CA stores but whether it will be included in them at all.
Google’s policy has no listed contact point, and the CA/B forum isn’t something mere mortals can complain to, so I’d appreciate if someone who can, and who has significant skills to argument this in English and is willing to, to bring it to them.
I was also bit by this. I switched to tlsserver profile, and when my XMPP certificate got renewed today, it failed to make any S2S connections :(. I'd to revert to classic profile. Could we please keep TLS client auth EKU ? Thanks!
Dear #Letsencrypt, you helped secure millions and millions of servers, not just web servers. But your announcement at letsencrypt.org/2025/05/14/end… about ending Ending TLS Client Authentication Certificate Support in 2026 because Google changes their requirements would result in your certificates becoming a possible risk for ensuring SMTP traffic. Please think again. Please.
Let’s Encrypt will no longer include the “TLS Client Authentication” Extended Key Usage (EKU) in our certificates beginning in 2026. Most users who use Let’s Encrypt to secure websites won’t be affected and won’t need to take any action.
Dear #Letsencrypt, you helped secure millions and millions of servers, not just web servers. But your announcement at letsencrypt.org/2025/05/14/end… about ending Ending TLS Client Authentication Certificate Support in 2026 because Google changes their requirements would result in your certificates becoming a possible risk for ensuring SMTP traffic. Please think again. Please.
Let’s Encrypt will no longer include the “TLS Client Authentication” Extended Key Usage (EKU) in our certificates beginning in 2026. Most users who use Let’s Encrypt to secure websites won’t be affected and won’t need to take any action.
With OCSP in all forms going away, I decided to look at the history and possible futures of certificate revocation in the Web PKI. I also threw in some of my own proposals to work alongside existing ones.
I think this is the most comprehensive current look at certificate revocation right now.
In case anyone is wondering about how to "update" a valid certificate from #letsencrypt that for some reason #prosody states is already expired, just run:
Make sure your LE cert deployment logic includes serving the right intermediates that ACME should hand you, not just that same old LE intermediate you got years ago. Otherwise, there'll be breakage...
Looks like a transparent bridge was deployed in front of the actual server, obtained dedicated certificates from #LetsEncrypt and MitMed all incoming client connections since July. It was discovered because the LE certificate expired 🤦
Folks, if you’re using @small-tech/auto-encrypt in your projects, please make sure you’re running the latest version of the package (3.1.0) or certificate provisioning/renewal will fail due to the latest Let’s Encrypt protocol update.
