Not everyone can or should self-host, but there is a lot of middle ground between self-hosting and putting everything on #AWS.

Federated protocols like #XMPP, #ActivityPub, and #SMTP give you choice.

#Fediverse #Jabber

🧵 1/5 @padraig @thunderbird Took a little searching but I am working again! Yay. The complexity is that which setup to use with Exchange can be legacy (POP3, IMAP+SMTP, EAS, EWS/OWA) or current Graph API. Thunderbird 140 supports all of the legacy API but not yet Graph API.

#thunderbird #tb140 #TbSync #EAS4TbSync #exchange #ews #owa #eas #imap #pop3 #smtp #GraphAPI #WhyIsMicrosoftSoHard

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}

Jan Wildeboer 😷

2025-05-16 07:05:24

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.

1/5

Ending TLS Client Authentication Certificate Support in 2026

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.

^{letsencrypt.org}