New (long and nerdy) blog post: "Be the LetsEncrypt in your homelab with step-ca" at https://jan.wildeboer.net/2025/07/letsencrypt-homelab-stepca/ where I explain my homelab setup with its own CA (Certificate Authority) on RHEL 10 (Red Hat Enterprise Linux) machines.
Replies to this toot will show up as comments on the blog post.
New (long and nerdy) blog post: "Be the LetsEncrypt in your homelab with step-ca" at https://jan.wildeboer.net/2025/07/letsencrypt-homelab-stepca/ where I explain my homelab setup with its own CA (Certificate Authority) on RHEL 10 (Red Hat Enterprise Linux) machines.
Replies to this toot will show up as comments on the blog post.
🔐 Let’s Encrypt Begins Supporting IP Address Certificates • Linuxiac
https://linuxiac.com/lets-encrypt-begins-supporting-ip-address-certificates/
We see that #LetsEncrypt is now experimentally issuing IPv4 and IPv6 certs! (https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate/).
This is fantastic news for people who want to set up their own #DOH or #DOT servers that support automatic encryption upgrade (DDR - https://datatracker.ietf.org/doc/rfc9462/).
We look forward to this being put into production. We wish the expiry time was a bit longer - maybe a new profile with 30 day validity? But in any case - great to see this happening. 👏
We see that #LetsEncrypt is now experimentally issuing IPv4 and IPv6 certs! (https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate/).
This is fantastic news for people who want to set up their own #DOH or #DOT servers that support automatic encryption upgrade (DDR - https://datatracker.ietf.org/doc/rfc9462/).
We look forward to this being put into production. We wish the expiry time was a bit longer - maybe a new profile with 30 day validity? But in any case - great to see this happening. 👏
Introducing Web Numbers
Domains? Where we’re going, we don’t need domains!
Get ready for an exciting new (old?) way to address (small) web sites in 2026.
https://ar.al/2025/06/25/web-numbers/
💕
(Thanks to @letsencrypt.)
#WebNumbers #SmallWeb#domainNames #IPAddresses#TLS#HTTPS#LetsEncrypt #web #decentralisation#SmallTech
Phishing means that an adversary *claiming to be* someone you know (including friends and family) convinces you to click on a link.
The purpose of a certificate, telling a receiver *WHO* (human readable) owns the associated private key (the last resort to distinguish between fake and authentic), now has completely vanished.
As if phishing is not already the nr. 1 problem on the internet.
Note: I'm fine with the idea provided that browsers clearly inform users about the reliability of authenticity (I've read your article, did you read https://infosec.exchange/@ErikvanStraten/113079966331873386 ?)
#Phishing#LetsEncrypt#DNS#DomainNames#Identification#Authentication
Thanking the @letsencrypt folks for the excellent work they do, and especially for their upcoming support for security certificates for IP addresses which is nothing short of revolutionary for the future of the (Small) Web.
https://community.letsencrypt.org/t/getting-ready-to-issue-ip-address-certificates/238777/22
#SmallWeb #security #IPAddresses#WebNumbers#LetsEncrypt#SmallTech #decentralisation#peerToPeerWeb #findability
Introducing Web Numbers
Domains? Where we’re going, we don’t need domains!
Get ready for an exciting new (old?) way to address (small) web sites in 2026.
https://ar.al/2025/06/25/web-numbers/
💕
(Thanks to @letsencrypt.)
#WebNumbers #SmallWeb#domainNames #IPAddresses#TLS#HTTPS#LetsEncrypt #web #decentralisation#SmallTech
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: https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427/66
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 https://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: https://toot.mirbsd.org/@mirabilos/statuses/01JV8MDA4P895KK6F91SV7WET8
② jwildeboer’s: /@jwildeboer%40social.wildeboer.net/114516238307785904
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… 🤬
Update 3: not only are people on the Let’s Encrypt side obnoxious in trying to discuss away the problem, and saying hundreds of affected users is of no importance (what a privilegued thing to say…) and that LE is only a web CA… but they now also say that, if someone has a certificate and key for hostname.example.com and has reverse and reverse-forward DNS for their IP addresses matching that, that that should not mean that they are allowed to send out mail as hostname.example.com (?!?!?! I cannot even begin to understand the sick “reasoning” that has to be behind such a statement). They also say they think the removal of the TLS client key usage from server certs to be “years overdue”. This deliberate working against actual users’ needs is… just wrong (I have much stronger words but will refrain, for now).
Time to hope for @jwildeboer ’s https://nerdcert.eu/ to lift off and be included in the usual Root CA bundles (except Google Chrome’s, I suppose).
A space for Bonfire maintainers and contributors to communicate
