Does anyone know of a table of data which shows PKI CA root certs and which devices/clients they are compatible with? (i.e. which devices/clients include each root cert in their default trust store)
I think I have asked about this in the past. It'd be incredibly useful.
@farshidhakimy @aral Absolutely — you're right, this isn’t a brand-new concept. Cloudflare's cert on https://1.1.1.1 is a great example of a legitimate use case for IP-based certificates, especially in infrastructure-focused services like public DNS.
And yes, other CAs have issued certs for IP addresses before Let's Encrypt started doing it — so it’s not unprecedented. The shift here is more about accessibility and scale. Let’s Encrypt offering free certs for public IPs means this capability is now much more widely available, even to actors who previously didn’t have the budget or motivation to go through commercial CAs.
That’s where the risk discussion comes in — not that certs for IPs are inherently bad, but that easier issuance could lower the barrier for phishing kits, command-and-control servers, or shady hosts to appear more “legitimate” with a valid HTTPS padlock, especially in contexts where URLs are masked or shortened.
So yeah, not panic-worthy — just something worth watching as it scales.
@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.
Big news from Let's Encrypt! Since 2015, there have been requests for certificates for IP addresses—a rare offering among certificate authorities. Today, they've issued their first certificate for an IP address! As announced earlier this year, this feature is now being rolled out gradually to subscribers.
https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate/
#Development #Announcements
Our first IP address certificate · Let’s Encrypt starts rolling out the new option https://ilo.im/16530s
_____
#LetsEncrypt #CA #IpAddress #Certificate #SSL #TLS #HTTPS #WebDev #Frontend #Backend
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.)
At Akamai, we're launching a blog post series on various topics relating to post-quantum cryptography. The first post is by @rsalz, discussing some related IETF initiatives, including the two #TLS drafts he co-authored:
https://www.akamai.com/blog/trends/building-quantum-safe-internet-ietf-plan-tls
Hello, I’m hosting a #Vaultwarden server behind #Caddy 2.10 and made the following test:
Tuning Caddy to allow only #PQC curves:
tls {
curves x25519mlkem768
}
Trying to connect with #Firefox Mac -> OK
Trying to connect with #Bitwarden #android client -> Fail
Without the #TLS tuning, the Bitwarden Android client will happily connect to the server.
Is it a problem with the Bitwarden Android client or with Android, or both?
Why SSL was renamed to TLS in late 90s (2014)
https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html
A recent research has exposed more than 40 * 10³ IoT cameras happily showing their feed _and_ location to anyone who can browse and use search engines specialized in the indexing of the misconfigured devices.
More than 14 * 10³ are localised in the USA.
Read more here.
Note:
I know that there are more than a million of these cameras world wide misconfigured an open on just port 80 http not even TLS 443, with admin / admin as credentials 
https://www.theregister.com/2025/06/10/40000_iot_cameras_exposed/
Nutzt du Client Authentication mit TLS-Zertifikaten?
More interesting progress trying to make #swad suitable for very busy sites!
I realized that #TLS (both with #OpenSSL and #LibreSSL) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a #lockfree queue as opposed to one protected by a #mutex. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed. 
So I read some scientific papers 
... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. 
Maybe it could do even more, didn't try yet.
Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...
(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: https://dl.acm.org/doi/10.1145/248052.248106
1/3
This afternoon I enjoyed browsing through the printed edition of a recent TLS. One is so much more likely to happen upon the unexpected, and I was not disappointed today.
For example, Notre Dame historian Felipe Fernández-Armesto takes the Yale Latin Americanist Greg Grandin to task in an uncompromising review of "America, América: A New History of the New World":
>>I opened the book expecting instruction and entertainment. I closed it in despair. How can such a shoddy piece, so self-indulgent, so partisan, so ignorant, so poorly written and so carelessly checked, appear over the name of a well-qualified professor and the imprint of a respected publisher? <<
Fernández-Armesto is particularly critical of what he sees as Grandin's recycling of the "black legend" of Spanish colonialism. He concludes his review
>>To "American identity of the future", wrote Walt Whitman in 1883, "Spanish character will supply some of the most needed parts . It is time to realize --for it is certainly true--that there will not be found any more cruelty, tyranny, superstition, etc., in the resume of past Spanish history than in the corresponding resume of Anglo-Norman history". Some people have not realized it yet.<<
https://link.gale.com/apps/doc/A839229765/AONE?u=txshrpub100020&sid=bookmark-AONE&xid=99da47a6
Solved! 
This was a pretty "interesting" bug. Remember when I invented a way to implement #async / #await in #C, for jobs running on a threadpool. Back then I said it only works when completion of the task resumes execution on the *same* pool thread.
Trying to improve overall performance, I found the complex logic to identify the thread job to put on a pool thread a real deal-breaker. Just having one single MPMC queue with a single semaphore for all pool threads to wait on is a lot more efficient. But then, a job continued after an awaited task will resume on a "random" thread.
It theoretically works by making sure to restore the CORRECT context (the original one of the pool thread) every time after executing a job, whether partially (up to the next await) or completely.
Only it didn't, at least here on #FreeBSD, and I finally understood the reason for this was that I was using #TLS (thread-local storage) to find the context to restore.
Well, most architectures store a pointer to the current thread metadata in a register. #POSIX user #context #switching saves and restores registers. I found a source claiming that the #Linux (#glibc) implementation explicitly does NOT include the register holding a thread pointer. Obviously, #FreeBSD's implementation DOES include it. POSIX doesn't have to say anything about that.
In short, avoiding TLS accesses when running with a custom context solved the crash. 
#commonLisp #emacs #smallweb #kitten https://screwlisp.small-web.org/kitten/clkitten-parenscript-kitten-2/ #webdev
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.
Auto Encrypt – heads up!
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 :)
#AutoEncrypt #TLS #LetsEncrypt #SmallTech #SmallWeb
¹ Drop-in Node.js https server replacement that automatically provisions and renews Let’s Encrypt certificates for you. (https://codeberg.org/small-tech/auto-encrypt#auto-encrypt)
² https://datatracker.ietf.org/doc/draft-ietf-acme-ari/
³ https://codeberg.org/small-tech/auto-encrypt/src/branch/main/CHANGELOG.md#4-4-0-2025
Goodbye Site.js, Hello Kitten!
I started working on creating a Small Web¹ server (a peer-to-peer Web server) six years ago² with Site.js.
Building Site.js was my first attempt. And it resulted in:
• Auto Encrypt (automatic Let’s Encrypt certificates): https://codeberg.org/small-tech/auto-encrypt
• Auto Encrypt Localhost (automatic localhost TLS certificates): https://codeberg.org/small-tech/auto-encrypt-localhost
• @small-tech/https (drop-in Node.js https module replacement with automatic TLS certs everywhere): https://codeberg.org/small-tech/https
• JSDB: In-process, in-memory JavaScript database that persists to append-only JavaScript logs: https://codeberg.org/small-tech/jsdb
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:
For its successor, please see Kitten:
If you want to support our work at the Small Technology Foundation, please consider becoming a patron:
https://small-tech.org/fund-us
¹ https://ar.al/2024/06/24/small-web-computer-science-colloquium-at-university-of-groningen/
² https://ar.al/2019/08/26/introducing-small-technology-foundation/
³ Using our instance of Look Over There!: https://look-over-there.small-web.org
Il y a des experts en cryptograhie ici ?
Un certificat avec des SANs mais sans Common Name / Subject ; c'est possible ?
https://crt.sh/?id=18519921301
#tls #pki #https
@rl_dane @ShinjiLE if you or someone else wants to help argue, the thread is at https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427 (Discourse, so JS webbrowser), I’m exhausted.
