curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
Worth noting that people on RedHat still haven't received proper updates, only a workaround that disables two Comodo root certificates that were used to sign the emudhra certificates.
I chose AlmaLinux last time I needed to, and it's been a great way to access the ecosystem — I heartily recommend it as a free RHEL! — but these past few days have me looking in envy at Debian. Corporate stability hasn't been what I expected.
Commercial support in Linux seems to be loosing its advantage over Debian.
Ubuntu (including Ubuntu Pro) still doesn't have a CVE-2026-99999 patch while Debian does have it. For commercial operators a KVM guest escape vulnerability is quite important.
I honestly think you're better off with RHEL. They might have been slow to act in this situation, but do one scan on a Debian vs a RHEL system container image and I'm confident Debian's will show a lot more red than RHEL (even with the fedora)
This is such a clusterfuck. I use so many containers in my home lab and various local installations and stuff. Honestly, I have no idea what I'm even supposed to do at this point because I'm not a full time developer.
Well, that is what people who have been around the block a few times have been saying about containers since just about forever. "I don't want to be an admin for my n software packages, I'll use containers!" - now you are the admin of n containers, except with worse tools than your distro and no upstream support.
I use some rules and a few generated scripts and have a LLM handle the management of the containers. Security through a ssh gateway, allows them to deploy/remove containers and then the rule is to stay at least two weeks behind on releases, unless the latest release is security related, which it figures out by reading the release notes.
I ran watchtowerr before, but I think this is a smarter way to do it.
And since before that, when we started turning to additional packages managers installed with package managers. Pip etc. mean that an “apt upgrade” isn’t enough, when it really “should” be (used to be) in a well managed system.
Then we layered _another_ level of package management on top with Flatpak etc.
I don’t think anyone has _really_ been - in practice - able to understand how many versions of Python (or shells or ruby or Perl etc…) are installed on any system for a decade or two now.
[Edit to add: and I forgot entirely about venvs (and other language’s equivalents). We put package managers into packages! Now there can be a different version of every package for every script on your system. In every container. And Python even has more than one venv system to choose from!]
[Yes, I use all these things - it’s so hard _not_ to and still use modern software or participate in modern software development…]
It's funny that no one seems to even consider using the distro package manager when it's time to complain about Python package management again. The deployment environment is usually well-known thus scriptable, and developers can be expected to know how to install packages on their own distros. And, of course, if the package is deployed as part of a distro, everything is taken care of by the distro people.
Flatpak is somewhere in the middle because it can and does centrally update dependencies, though they are packaged in larger boxes and it's tempting to include more exotic stuff in the app package instead of creating and maintaining a separate Flatpak shared with other dependees.
Nobody seriously considers it because usually, especially in enterprise distros, the major versions are years out of date and missing many features. And many smaller packages just won't be available. Even for something as major as Django it just wasn't viable to use the OS package manager when I tried it in the Debian 8 and then 9 days.
Only one company I've worked at maintained their own distro packages for deploying services. That was 13+ years ago. Every company since then had a containerized deployment strategy, some better than others. My most recent employer went through a massive effort to implement "golden base images" and tooling to ensure when the base image is updated all the dependents are rebuilt and redeployed. Most don't do that.
For me, this comment actually bolsters the argument for containers imo. It's a lot easier to rebuild a system image and redeploy it out across a bunch of apps than it is to update a bunch of VMs (maybe ansible/puppet makes it moot). Idk
Python environment was so brittle, that a solution was found: pack dependencies into "envs" of various kinds. Disk space is cheap, after all (ahem). Now it's time to pay the bill for that approach...
don't worry. if you're in this situation with this attitude, you're likely running out of date container base images and whatnot.
i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.
Yeah, at some point I gave up and asked AI to do patching for me. It was a good call because it found affected certificates in places where I wouldn't look (e.g. aws-cli or Libre Office).
cool cool cool. Don't understand what you're doing, and keep not understanding what you're doing. the agents are infallible after all, and who cares about properly verifying certs anyway? that's nerd shit.
Countless and countless, no, millions of male developers felt discriminated against whenever someone called it Man-in-the-middle. This went on unaccounted for for decades! Finally we’re being seen!
Not to mention all the women who were misogynisticly attacked by assuming women can’t be hackers.
Finally justice. It’s very important that we’re getting our priorities right when talking about security vulnerabilities!
As a sentient cephalopod who has enjoyed hacking staff computers when I slip out of my tank at the National Aquarium every night, I can only say it feels good to be seen. We're finally making progress on de-centering hominid perspectives in favor of a more diverse range of natural intelligences!
That's not the case, Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
> Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
Reminder: Neither the CVE nor the linked go alert seem to say that you have to recompile and redeploy your application with the new go version in order to take advantage of this change. Just updating the tool chain and go stdlib isn't enough, because this stuff gets baked into the resultant binary. This is unlike, say, python, Ruby, or java where updating the runtime may be sufficient, depending on your development and deployment model.
Go is not vulnerable in the same way software using webpki is, because it generally uses the system trust store. However, this change is about golang proactively blocking the certs, so that even if your OS doesn't update, it still won't trust them.
Certificate authority (eMudhra) generated eight of its intermediate signing keys so badly that anyone can recover the private keys from the public certificates. That means anyone can mint a "valid" HTTPS certificate for any site, such as your bank, GitHub, or PyPI, and impersonate it.
For desktop/most server software, they usually defer what to trust to the operating system, so if you've updated your OS' cacerts package they would likely have been revoked.
The really fun stuff are stuff like:
1. embedded and IOT stuff that doesn't ever get OS updates or even have an OS. People are using this to MITM stuff like smart TVs and household appliances and then pwn them.
2. In some cases a Linux container is run in a context where the OS is hidden from it (think serverless/container as a service type platforms). It might not have access to the OS trust store and have to fall back on the one built into the stdlib.
A lot of software is going to be forced to update or retire soon, all unpatched software should be retired off the internet immediately because AI agents are in waiting.
Great. The technology has progressed enough to kill the existing technologies. It's like the fish in a pool creating a shark that eats away all the fish while the fish proudly announce that their great creation (shark) as the frontier progress for their fish race.
Agents have dramatically increased the ability to poke at every single surface out there. I would be surprised if the researcher who found this wasn't assisted by a llm.
The researcher in question has publicly stated[0] that he wanted to try Google's paranoid_crypto tool[1], so he ran it on some roots as a quick proof-of-concept, and the first thing that happened was that it detected these intermediates. He also states he's been running a lot of certificate linters so this was just the next logical step I guess.
That was an enlightening read. I find it incredible that apparently Google themselves don't use the existing corpus of certificates as a test for paranoid_crypto.
My biggest worry now is what's going to happen with the amount of unemployed software developers seeing these vulnerabilities and not able to bring money to pay the bills.
No it affects everybody, but most browsers/OSs etc have updated already. This is just a workaround Go put in case the underlying OS has not been updated. Not sure why this link is on the front page as it duplicates previous posts and confuses people, I think it should be merged.
I've had since Debian 8 (2015) few helper scripts to make me remember better how to manage approved CA's. There are three of those, which have been working all Debian versions since 8 to current 13.
# cat /usr/local/sbin/ca-certificates-list-active
#!/usr/bin/env bash
#
# BFMI tool to list Debian CA certificates active - mesrik, 2015
#
CA_CONFIG=/etc/ca-certificates.conf
CA_REPO_DEBIAN=/usr/share/ca-certificates
if [ -f $CA_CONFIG ]; then
# study any ca-certificates which have been configured active
for i in $(egrep -v '^[#!]' /etc/ca-certificates.conf) ; do
cert_source=$(dirname $i)
cert_file=$(basename $i)
openssl x509 -in $CA_REPO_DEBIAN/$cert_source/$cert_file -noout -subject |\
sed 's/^subject=//'
done
else
echo "$(basename $0): Ooops, was not able to access $CA_CONFIG"
fi
# eof
#!/usr/bin/env bash
#
# BFMI tool to invalidate all CA certificates in Debian Jessie - mesrik, 2015
#
CA_CONFIG=/etc/ca-certificates.conf
prog=$(basename $0)
usage="Usage: $prog { -commit }"
if [ $# -lt 1 ]; then
echo $usage
exit 1
fi
if [ "$1" = "-commit" ]; then
if [ -f $CA_CONFIG ]; then
backup_ext=$(date -r $CA_CONFIG +".%FT%T%z")
perl -wpi$backup_ext -e 's/^([^!#].*)$/!$1/;' $CA_CONFIG
if [ $? -eq 0 ]; then
echo "$prog: backup $CA_CONFIG$backup_ext was made."
/usr/sbin/update-ca-certificates
fi
else
echo "$prog: Ooops, was not able to access $CA_CONFIG"
fi
else
echo "$prog: Need -commit to actually invalidate all CA's"
fi
# eof
ps. I did bit of editing, I didn't expect Tab to be ignored when pasting here.
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
* GLSA 202610-01: https://security.gentoo.org/glsa/202610-01
* https://emudhra.we-have-a-problem.com/
https://access.redhat.com/security/vulnerabilities/RHSB-2026... - "Ongoing"
I chose AlmaLinux last time I needed to, and it's been a great way to access the ecosystem — I heartily recommend it as a free RHEL! — but these past few days have me looking in envy at Debian. Corporate stability hasn't been what I expected.
Ubuntu (including Ubuntu Pro) still doesn't have a CVE-2026-99999 patch while Debian does have it. For commercial operators a KVM guest escape vulnerability is quite important.
https://discuss.python.org/t/information-for-python-users-re...
I ran watchtowerr before, but I think this is a smarter way to do it.
Then we layered _another_ level of package management on top with Flatpak etc.
I don’t think anyone has _really_ been - in practice - able to understand how many versions of Python (or shells or ruby or Perl etc…) are installed on any system for a decade or two now.
[Edit to add: and I forgot entirely about venvs (and other language’s equivalents). We put package managers into packages! Now there can be a different version of every package for every script on your system. In every container. And Python even has more than one venv system to choose from!]
[Yes, I use all these things - it’s so hard _not_ to and still use modern software or participate in modern software development…]
Flatpak is somewhere in the middle because it can and does centrally update dependencies, though they are packaged in larger boxes and it's tempting to include more exotic stuff in the app package instead of creating and maintaining a separate Flatpak shared with other dependees.
i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.
Takes about 20 seconds. Depending if you need to hit enter.
Monster?
(Mallory-in-the-middle is OK too.)
Countless and countless, no, millions of male developers felt discriminated against whenever someone called it Man-in-the-middle. This went on unaccounted for for decades! Finally we’re being seen!
Not to mention all the women who were misogynisticly attacked by assuming women can’t be hackers.
Finally justice. It’s very important that we’re getting our priorities right when talking about security vulnerabilities!
Eve would like to have a word with you. I haven't heard of Heidi before... but she's apparently one of the cast.
https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...
The problem is Golang has it's own trust store. So you don't benefit from OS patching.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
It's an or situation, not and.
Reminder: Neither the CVE nor the linked go alert seem to say that you have to recompile and redeploy your application with the new go version in order to take advantage of this change. Just updating the tool chain and go stdlib isn't enough, because this stuff gets baked into the resultant binary. This is unlike, say, python, Ruby, or java where updating the runtime may be sufficient, depending on your development and deployment model.
https://github.com/golang/go/issues/82345
Certificate authority (eMudhra) generated eight of its intermediate signing keys so badly that anyone can recover the private keys from the public certificates. That means anyone can mint a "valid" HTTPS certificate for any site, such as your bank, GitHub, or PyPI, and impersonate it.
Much better explanation here
https://cycle.io/blog/2026-intermediate-ca-compromise
This is the Go version of the initial HN post https://news.ycombinator.com/item?id=50166579
As in - could I connect to a site signed with those certificates and see that my browser/client accepted that certificate?
I assume these certificates have been pulled from most browsers - but - an un-updated curl or wget would still accept these, right?
EDIT: found https://emudhra.we-have-a-problem.com/ , scroll down to 'Does your client still trust the compromised intermediates?'
The really fun stuff are stuff like:
1. embedded and IOT stuff that doesn't ever get OS updates or even have an OS. People are using this to MITM stuff like smart TVs and household appliances and then pwn them.
2. In some cases a Linux container is run in a context where the OS is hidden from it (think serverless/container as a service type platforms). It might not have access to the OS trust store and have to fall back on the one built into the stdlib.
If you think "that's weird to see such a small number in key generation" than you're one step ahead of whoever generated that key.
Unfortunately, unlike with RSA, small primes are not apparent in elliptic cryptography.
https://xkcd.com/221/
[0]: https://groups.google.com/a/mozilla.org/g/dev-security-polic...
[1]: https://github.com/google/paranoid_crypto
What a weird comparison...
https://ftp.osuosl.org/pub/slackware/slackware64-15.0/Change...
To check, from keks24:
Here is the original story: https://news.ycombinator.com/item?id=50166579
https://news.ycombinator.com/item?id=50166579
# cat /usr/local/sbin/ca-certificates-list-active
# cat /usr/local/sbin/ca-certificates-reconfigure # cat /usr/local/sbin/ca-certificates-invalidate-all ps. I did bit of editing, I didn't expect Tab to be ignored when pasting here.The very urgent uv/certifi/etc releases (and yet-to-be-done bun release) are about removing the compromised CAs as described here:
https://emudhra.we-have-a-problem.com/
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
edit: forgot I can't use code blocks on HN