Can I submit my "Tylenol & Rum" invoices directly to the CA/B Forum, or should I break it out for individual members?
Can I submit my "Tylenol & Rum" invoices directly to the CA/B Forum, or should I break it out for individual members?
#Heise:
"
"Passwort" Folge 40: Probleme mit Widerrufen, Verbindungsabbrüchen und anderem
Eine pickepackevolle Folge, gefüllt unter anderem mit kundigem Exploitbau unter Linux, einem HTTP2-DoS und millionenfachen Zertifikatsrückrufen von Microsoft.
"
https://www.heise.de/news/Passwort-Folge-40-Probleme-mit-Widerrufen-Verbindungsabbruechen-und-anderem-10632694.html
mp3: https://audio.podigee-cdn.net/2098722-m-7a844de5c304b67bf99d2ee327d88425.mp3
10.9.2025
Aaaa.. MS..
#CA #CertificateTransparency #Chrome #LetsEncrypt #Microsoft #MS #PKI #TLSZertifikat #WebPKI #Zertifikat
For anyone who is panicking over certificate misissuance for #cloudflare 1.1.1.1: such "incidents" happen on a regular basis. For example #letsencrypt once had to revoke ~3M certs because their #CAA validation algorithm was faulty:
https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
Name a #CA and you're definitely going to find cases of misissuance. The problem is the #WebPKI governance that's more than often just a paper tiger that doesn't impose any sanctions on the heavy weights.
On 2020-02-29 UTC, Let’s Encrypt found a bug in our CAA code. Our CA software, Boulder, checks for CAA records at the same time it validates a subscriber’s control of a domain name. Most subscribers issue a certificate immediately after domain control validation, but we consider a validation good for 30 days. That means in some cases we need to check CAA records a second time, just before issuance. Specifically, we have to check CAA within 8 hours prior to issuance (per BRs §3.2.2.8), so any do...
CRLite is a fascinating piece of technology by Mozilla to handle revocations on the WebPKI, in a privacy-friendly and bandwidth ~friendy approach: it uses a new compact data-structure called Clubcards (basically Ribbon filters (enhanced Bloom filters) with partitionning): https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/

Firefox is now the first and the only browser to deploy fast and comprehensive certificate revocation checking that does not reveal your browsing activity to anyone (not even to Mozilla). ...
Within the #WebPKI, the "common name" is widely irrelevant afaik:
https://infosec.exchange/@pft/114745413874521644
So the question is: what are the circumstances that can pose a security risk if IP addresses are included in the CN field.
Attached: 1 image @hrbrmstr@mastodon.social do they? There is even an ancient RFC that explicitly advises against considering CN in validation (I have to dig it up though...). CA/Browser Forum also mandates SAN in the baseline requirements (see image) and some CAs do not even fill CN in.
Firefox 136 looks poised to enforce Certificate Transparency.
It may be late, but combined with CRLite (and its other Web PKI progress), it may soon be the browser with the most robust Web PKI support.
While I would still say that Chromium generally wins on the security front, I’m happy to see the gap narrow with time and to see Firefox occasionally inch ahead in some areas.
Originally posted on seirdy.one: See Original (POSSE). #Firefox #WebPKI
Hmm. #CERTBUND had just revoked their main #WebPKI certificate:
https://crt.sh/?id=12765055285
It seems, some browsers actually get this information, mine don't.