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.
@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.
Let's #Encrypt rolls out free IP address #certificates • The Register
Let's Encrypt, a #CertificateAuthority (CA) known for its free TLS/SSL certificates, has begun issuing digital certificates for IP addresses.
It's not the first CA to do so. #PositiveSSL , #Sectigo, and #GeoTrust all offer TLS/SSL certificates for use with IP addresses, at prices ranging from $40 to $90 or so annually. But Let's Encrypt does so at no cost.
#security #tls #ssl #privacy
https://www.theregister.com/2025/07/03/lets_encrypt_rolls_out_free/
#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
Flight: #BGA113H
ICAO code: #395D67
Callsign: #BELOUGA
Operator: Airbus Transport International
Country: 
From: #TLS to #XFW
Speed: 777 kmh
Altitude: 9449 m
Distance: 2.7 km
Angle ∆: 73.9°
Direction ->: NE
Track:
https://tinyurl.com/23jhvspk
History:
https://www.radarbox.com/data/mode-s/395D67
Seen: 27x
#Airbus #BelugaXL #A330 #Transport #RadarMechelen
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.)
Flight: #BGA151J
Registration: F-GXLJ
ICAO code: #395D69
Callsign: #BELOUGA
Operator: Airbus Transport International
Type: A330 743L
Country:
From: #BRE to #TLS
Speed: 688 kmh
Altitude: 9144 m
Distance: 4.5 km
Angle ∆: 63.8°
Direction ->: SSW
Track:
https://tinyurl.com/235bgxzq
History:
https://www.radarbox.com/data/mode-s/395D69
https://www.flightradar24.com/data/aircraft/F-GXLJ
Photos:
https://jetphotos.com/photo/keyword/F-GXLJ
Seen: 23x
#Airbus #BelugaXL #A330 #Transport #RadarMechelen
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.
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
Flight: #BGA151G
ICAO code: #395D66
Callsign: #BELOUGA
Operator: Airbus Transport International
Country:
From: #BRE to #TLS
Speed: 753 kmh
Altitude: 8534 m
Distance: 1.3 km
Angle ∆: 81.4°
Direction ->: SSW
Track:
https://tinyurl.com/28dm659g
History:
https://www.radarbox.com/data/mode-s/395D66
Seen: 18x
#Airbus #BelugaXL #A330 #Transport #RadarMechelen
Running e-mail servers is always fun: as the time came to renew TLS certificate on one machine doing e-mail transmission (SMTP), came to know TLSA records are now supposed to be 3 1 1 (no more 3 0 1) 
There is an added benefit of 3 (DANE-EE) 1 (subject public key) 1 (SHA2-256 hash digest) - if you do not rotate your private key to issue TLS certificate, you don't need to update the TLSA record - signature can be squeezed from key and certificate is not necessary at that point. If you do rotate private keys, this enables you to pre-create DNS records even before certificate is issued (given that you already generated keys) - that is really nice 
Hello, I’m hosting a #Vaultwarden server behind #Caddy 2.10 and made the following test:
Tuning Caddy to allow only #PQC curves:
Flight Radar Mechelen 
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/
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
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. 
Come on SAP, it's 2025 - expired certificates in production should be a thing of the past! Let's not break trust with something so basic. #DevOps #TLS #SAP #Fieldglass
After having decided the #TLS certificate, I’m much more sure that ASN.1 is simply encoding / serializing pieces of information.
Similarly, DER, BER, etc specify what is encoded in what order and using what ASN.1 types for things.
Said another way, ASN.1 is how to do something and DER is what to do it to.
Sort of a policies vs procedure type thing.
