That will be a no.
Which is a shame as I want to use SNI in the back end but also make use of AWS issued certificates and the NLB TLS integration since there is no easy way to get a cert from the AWS Certificate Manager to a EKS Secret
Testing a theory on AWS, does a NLB terminating TLS forward the SNI header if the backend is also TLS?
Will know once AWS has finished pulling my test container.
@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.
#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.)
Oh boy, I have a lead! And it's NOT related to #TLS. I finally noticed another pattern: #swad only #crashed when running as a #daemon. The daemonizing wasn't the problem, but the default logging configuration attached to it: "fake async", by letting a #threadpool job do the logging.
Forcing THAT even when running in foreground, I can finally reproduce a crash. And I wouldn't be surprised if that was actually the reason for crashing "pretty quickly" with #LibreSSL (and only rarely with #OpenSSL), I mean, something going rogue in your address space can have the weirdest effects.
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?
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/
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
Es gab doch mal diesen Vorstoß, daß Browser- unf Betriebssystemhersteller in der EU verpflichtet werden sollen, EU-CAs für #x509 als vetrauenswürdig aufzunehmen - was ja auch jeglicher #Chatkontrolle stark in die Hände spielte...
Gibt es dazu Neuerungen? Und wie hießen die nochmal? qwacs oder so?
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
Found and fixed two more bugs affecting only #TLS with #swad, so here's yet another "bugfix release":
https://github.com/Zirias/swad/releases/tag/v0.9
One of these bugs was always there and I never noticed (just ignoring intermediate certificates) because many clients cope well with this, but not all.
The other bug is yet another regression from earlier performance improvements. 
So, lots of releases these last days. I'll have to remember to do very thorough regression testing whenever "optimizing" things in existing code
In a nutshell: 0.8 was finally fine again without TLS, but if you need TLS, better use this new 0.9.
@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.
New #blog post!
Creating a personal #TLS certificate authority.
I talk about how I created my own trusted root certificate, so I can use services on my VPN via #https, without using self-signed certificates, and without exposing my internal domain's existence to the public internet.
https://adamu.jp/blog/personal_certificate_authority
Check out my new post about "Encryption In Authoritative DNS"
https://shrirangkahale.com/posts/encrypted-adns/
New Kitten Release
To OCSP¹ or not to OCSP…
• Turns on OCSP support in the server only if the site’s certificate has the OCSP stapling extension.
This is to support both servers that still have OCSP stapling in their certs as well as new ones that don’t. (Let’s Encrypt sunset OCSP support yesterday and there is a transitionary period where Kitten servers will have both types of certificates. This update is to ensure we support both without issues.)
Also updated, if you’re interested in playing lower in the stack:
• @small-tech/https: https://codeberg.org/small-tech/https
• @small-tech/auto-encrypt: https://codeberg.org/small-tech/auto-encrypt
Enjoy!
¹ Online Certificate Status Protocol (https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Yes, I hate abbreviations too :)
