So... it's here, right? After I waited almost 7 years... And it hopefully wouldn't turn into other "after 9 months pay us 10$/month" scam like ZeroSSL...
And... I will finally have federation in my Matrix server I guess :blobcatjoy:
It was funny to try to set it up. I don't understand how these automation scripts work - all I know was how to do things manually with simple bash scripts and openssl config files.
Last night it finally worked with acme.sh, so maybe it would just keep working itself from now...
These releases bring short-lived certificates, IP Address (IPv4 and IPv6) support, and ACME Renewal Information (ARI) support to Auto Encrypt and @small-tech/https, implement a consistent asynchronous API across all three packages, and include loads of little fixes and code quality improvements.
This brings us very close to getting Web Numbers¹ support implemented natively in Kitten².
OCSP support is removed from Auto Encrypt and Windows support is dropped from all three packages as Microsoft is complicit in Israel’s genocide of the Palestinian people³ and Small Technology Foundation⁴ stands in solidarity with the Boycott, Divestment, and Sanctions (BDS) movement. Furthermore, Windows is an ad-infested and surveillance-ridden dumpster fire of an operating system and, alongside supporting genocide, you are putting both yourself and others at risk by using it.
🥳 @small-tech/auto-encrypt-localhost version 9.0.1 released
Automatically provisions and installs locally-trusted TLS certificates for Node.js https servers (including Polka, Express.js, etc.) Unlike mkcert, 100% written in JavaScript with no external/binary dependencies. As used in Kitten¹
• Windows is no longer supported as Microsoft is complicit in Israel’s genocide of the Palestinian people¹ and Small Technology Foundation² stands in solidarity with the Boycott, Divestment, and Sanctions (BDS) movement³. Windows is an ad-infested and surveillance-ridden dumpster fire of an operating system and, alongside supporting genocide, you are putting both yourself and others at risk by using it.
Auto Encrypt Localhost is similar to the Go utility mkcert but with the following important differences:
It’s written in pure JavaScript for Node.js.
It does not require certutil to be installed.
It uses a different technique to install its certificate authority in the system trust store of macOS.
It uses enterprise policies on all platforms to get Firefox to include its certificate authority from the system trust store.
In addition to its Command-Line Interface, it can be used programmatically to automatically handle local development certificate provisioning while creating your server.
Auto-Encrypt Localhost is licensed under AGPL version 3.0.
Reaching out to anyone who configured their DNS transport protocol. If you intentionally configured your home router's or your devices DNS service, what did you pick, and why?
While I do maintain that "it's coming from the LAN" is not a good #security boundary, there are services where it is practical (eg. media center volume control), but also fault prone (oups my phone just switched to LTE for power saving – a generally justified thing).
Before I start formalizing how "a device can retain permissions it gets from being local for a few days" could work with EST/#TLS/#EDHOC: Does this model have a name, and/or have you ever seen it discussed or deployed anywhere?
@aral Great point — and I agree that most users would be suspicious if they saw an IP address like 89.72.4.2 instead of a familiar domain like mybank.com. The concern raised in the article, though, was more about scenarios where users don’t see the link clearly — such as in emails, PDFs, or messaging apps where URLs may be masked behind anchor text or shortened links. For example, a phishing email might show a link that says “View Invoice” but actually points to https://203.0.113.10/login.
Experienced users like you and I know to hover over links, check certificate info, or inspect the address bar. But many users don’t do that — or worse, they click links without verifying anything. According to the Verizon DBIR and other phishing studies, this is still one of the top attack vectors today.
Also, I don’t think the article was arguing against IP certs outright — just highlighting that, like with any new capability, there's potential for abuse that the broader public (and infosec community) should be aware of.
Eev (and lisp secret alien technology) made it /really/ easy and convenient to generate a kitten matching
@aral's Tutorial 2: dynamic pages, https://kitten.small-web.org/tutorials/dynamic-pages/ serve it and visit it inside emacs (just press F8 over and over again and it happens on its own).
I guess you can do it too...? What do you think? How much of a Hurkle itch is this giving you Aral ;p. It seems /really/ easy to get a fancy! #tls site up like this.
An emacs eww browser window visiting https://localhost which is announcing
Kitten count
and two smiling kitten emojis
On the right is the kitten expert shell, which was automatically initiated by emacs as well.
In the next minor version release of Auto Encrypt¹, we’ll be moving from a hard-coded date-based certificate renewal check to using ACME Renewal Information (ARI)².
The change³ should be seamless.
If you have any concerns, now is the time to raise them :)
As Site.js reached an evolutionary dead-end, and as I learned from my experiements with replicated data types that replicated data types are not a prerequisite for a decentralised web (actual topological decentralisation and ease of use are), I started writing a new server/platform called Kitten from scratch while still making use of the tried and tested modules listed above.
Last week, I switched over our last site using Site.js to Kitten and, with that, today I’ve sunset³ Site.js:
Email is the cockroach of the internet - it outlives every wave trying to kill it. Forget Slack, forget Discord, forget chat apps. Email is universal, decentralized, and asynchronous. It's not sexy, but it's the ultimate survivor.
@Daojoan It is well developed with technologies such as DANE and TLS-receiving guarantee. #DANE#TLS The standard user only has to choose the right provider.
@Daojoan#Email is well developed with technologies such as DANE and TLS-receiving guarantee. #DANE#TLS The standard user only has to choose the right provider.
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… 🤬