24 results for “mnordhoff”
I was grumpy about AAA Certificate Services being phased out a few months ago, but today I'm like "oh thank goodness, I don't have to worry about that, I got my worrying done already".
https://infosec.exchange/@mnordhoff/116353473819516279
https://infosec.exchange/@mnordhoff/116530408462132294
I was grumpy about AAA Certificate Services being phased out a few months ago but today I'm like "oh thank goodness, I don't have to worry about that, I got my worrying done already".
The snap also contains uv for some reason.
The problem with eMudhra stating that they will exit the TLS business, whatever precisely that means, is that it would give them even less incentive to operate compliantly. I'm not saying they'll act that way, but it's a bad sign.
Zillions of devices will still trust their root CAs forever even if the company checks out.
Are they going to keep operating CRLs to current standards until all their certificates expire, for example?
Will subscribers still have full access to revocation over the coming months or will they unplug the management portal immediately?
/snap/[redacted]$ find -name '*.pem' -size +20 -ls
910 235 -rw-r--r-- 1 root root 240216 Sep 1 17:57 ./lib/python3.12/site-packages/certifi/cacert.pem
1860 229 -rw-r--r-- 1 root root 234354 Sep 1 17:56 ./lib/python3.12/site-packages/pip/_vendor/certifi/cacert.pem
5676 276 -rw-r--r-- 1 root root 281617 Sep 22 2025 ./usr/lib/python3/dist-packages/pip/_vendor/certifi/cacert.pem
*runs screaming into woods*
I read the PR for one Big Tech Python program to remove AAA Certificate Services from the unnecessary certificate bundle.
The contributor said they used an LLM.
It's a patch to delete two dozen lines from a text file.
???
Meanwhile I'm just replacing CA bundles in /usr/ with symlinks because fuck Python and fuck my life.
Did you know the AWS API Python bindings used to contain two, slightly different versions (and use the system version instead sometimes).
Not that I can fix unpatchable snaps or Python snaps myself at all.
Some good news for .com.au and .net.au domain registrants: auDA proposes grandfathering existing registrations that don't meet the new restrictions.
Bad news for .qa domain registrants:
https://domainnamewire.com/2026/10/21/qa-domains-get-new-restrictions-change-your-nameservers-now/
It's DNS. :-(
I ought to buy something online today but maybe I should... not...
Me yesterday: "Oh good, I've updated almost everything."
GitHub notifications today: "Bump certifi" (open)
Fffu--
I have a device that did receive a software update a month or two after DST Root CA X3 expired and some of its programs broke.
Here's hoping they will rise from the crypt and patch this one too (even though it doesn't actively break anything).
Over on the hecksite/heck-ecosystem (heckosystem?), Bluesky set up a test account using an eMudhra certificate so that people can test whether their ATProto software can interact with the account and needs to be patched. Neat!
https://bsky.app/profile/did:plc:ewvi7nxzyoun6zhxrhs64oiz/post/3mye7adjcu223
Oh neat, Debian(/Ubuntu) ca-certificates distrusted AAA Certificate Services in version 20260223.
P.S. I criticize Sectigo at times, but I am not doing so in this case. Apple, Google, Microsoft, Mozilla and your Linux distro all trust eMudhra. Sectigo did as well.
ALSO "some person has a CA's private keys" is the most wild effing thing.
HSMs have one job! Just the one!
CAs have slightly more than one job, but not misplacing their private keys is the most critical one.
How did this happen and where are their vendors and auditors and labs?!
I'm a bit sad that this eMudhra situation also apparently sticks a knife in Sectigo's AAA Certificate Services, one of the oldest valid root CAs, which reportedly cross-signed these intermediates.
The intermediate certificates may have all been revoked,, but it's prudent to distrust the (apparently) 2 roots that they chain to in order to protect crappy software that doesn't support revocation (i.e. almost all software).
This is not a problem for Sectigo, which already has 2 newer generations of roots: the USERTrust ones from 2010 that are widely trusted, and the Sectigo ones from 2021 that are not yet.
I think Sectigo recently stopped even using AAA Certificate Services in their default certificate chains (though you still can if you want to), and Google and/or Mozilla removed it from their trust stores because it's no longer necessary.
Could be an issue if there are any other CAs relying on cross-signs, idk. (They ought to stop relying on it soon, anyway.)
Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
Validity
Not Before: Jan 1 00:00:00 2004 GMT
Not After : Dec 31 23:59:59 2028 GMT
Subject: C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
(It's known as Comodo_AAA_Services_root.crt in Debian because it's so old they weren't as rigorous about file names.)
The Chrome Root Program posted as well:
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/VAgSvefvAAAJ
Good thing recompiling all Go and Rust binaries with updated toolchains and dependencies is a thing that Linux distros do daily and not once two months before a new major release.
For software that doesn't support automatic certificate revocation checking, how many years until 1% of it has manually blocklisted this batch of mysteriously revoked intermediates?