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).
Well, turns out someone now reported that it indeed breaks #XMPP entirely: community.letsencrypt.org/t/do…
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.
① mine: toot.mirbsd.org/@mirabilos/sta…
② jwildeboer’s: social.wildeboer.net/@jwildebo…
Do *NOT* remove TLS Client Auth EKU!
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!Let's Encrypt Community Support
What the actual fuck, #LetsEncrypt‽Let’s Encrypt will no longer include the “TLS Client Authentication” Extended Key Usage (EKU) in our certificates beginning in 2026.
That makes them unusable for SMTP servers. Gah!Anyone got a usable alternative that doesn’t ruin financially?
Update: I’m in communication with them, let’s hope they recognise the usefulness.
Update 2: turns out it’s Google forcing this down the throat of all CAs that want to be recognised by Chrome as valid. I’m sure Google only accidentally decided on a new policy that breaks some SMTP and probably all XMPP use cases… 🤬
