Trust stores and certificate authorities

The last two lessons were about code you pull in. This one is about something you trust before any code runs: the list of organisations your computer believes when it connects to a website or an API. When one entry on that list goes wrong, every connection that relies on it goes wrong too.

A quick recap of the padlock

When your program connects over HTTPS, the server presents a certificate: a signed statement saying "this public key belongs to example.com". The signature is made by a certificate authority (CA), an organisation trusted to check that claim before signing.

Your device cannot meet every CA, so it ships with a list of ones it already trusts, called a trust store. A certificate is accepted if its signature leads back to something on that list.

The chain

Root CAs rarely sign website certificates directly. Their keys are precious, so they sign a few intermediate CAs, which do the daily signing. What your client checks is a certificate chain:

1. The website's certificate is signed by an intermediate.
2. The intermediate's certificate is signed by a root.
3. The root is already in your trust store, so the chain is accepted.

The security of the whole thing rests on one fact: only the CA can make those signatures, because only it holds the private keys. Everything depends on those keys being secret and, just as important, being unguessable.

When one key is weak: eMudhra, October 2026

On October 17, 2026, a researcher reported that eight intermediate certificates of the Indian CA eMudhra had private keys that could be computed from the public certificates. The details below come from Beam's write-up, eMudhra CA keys compromised, which cites Mozilla, Cloudflare, The Hacker News and others.

• Security researcher Scott Helme said he recovered all eight keys in under a second. One key was the number 4; the others were whole numbers below 256. A correctly generated key of that type is a random 384-bit number.
• Six of the intermediates were for TLS (websites) and two were for code signing.
• Cloudflare's plain summary: "an attacker can create a forged certificate for any domain."
• eMudhra says a flaw in the key wrap and unwrap step of an April 2025 key ceremony produced a second, weak key set next to the intended strong keys. It also says its infrastructure was not breached, its root keys were unaffected, and none of the eight issued an end-entity certificate. Google's view, per the post, is that the keys were generated with too little randomness, so they did not need to be stolen.
• No exploitation has been confirmed. No TLS certificate chaining to the six TLS intermediates appeared in Certificate Transparency logs before Chrome's block.

Notice the shape of this failure. Nobody broke encryption. Cloudflare notes it is a certificate authentication failure at one CA, not a weakness in TLS itself. The cryptography was fine; a key was not random.

The fix reached different software at different speeds

Here is the part with lasting lessons. The post's timeline: Chrome had a block live within two hours of the report, Firefox that evening, Apple on October 19 and Microsoft on October 20.

How can a browser react that fast? Through certificate revocation: a way of telling clients to stop trusting something before its expiry. Browsers receive these updates in the background, and many also use certificate transparency, public logs of issued certificates, so a certificate that was never logged is suspect.

Everything that is not a browser is the long tail. The same post lists software that needs an update because it bundles its own list and does not check revocation:

Why containers? An image carries the trust store from the day it was built. An old image keeps trusting the bad chain until someone rebuilds it. This is the previous lesson's idea again in a new place: the trust list is a dependency, and it needs pinning, updating and an owner like any other.

Browser fix in hours, everything else in weeks: the gap is the exposure. And note a related warning from the same post, from Filippo Valsorda: Linux root stores are too poorly maintained for revocation to reach applications.

Test, don't assume

You do not have to guess whether your runtime still trusts the bad certificates. Mozilla's Dennis Jackson published test hosts for exactly this. The post suggests a command that should fail with a certificate error:

curl https://dv-g3b-emudhra.we-have-a-problem.com/

A certificate error means your client rejects the compromised intermediate. A successful response means it still trusts it and needs updating. Run the test from the same runtime your service uses, since a language SDK may use a different trust path from your shell.

Never fix the error by turning verification off

When a program hits a certificate error during an incident like this, the quick "fix" is to turn verification off. The post quotes Cloudflare: "It's important to not resolve these errors by disabling verification." Search your code and config for the flags that do exactly that: verify=False, InsecureSkipVerify, rejectUnauthorized: false, and NODE_TLS_REJECT_UNAUTHORIZED. Each one turns a trusted connection back into one that anyone on the path can impersonate.

How AI changes this

Agents live where trust is stale. The post points out that most AI agent traffic is HTTPS from non-browser runtimes: Python SDKs, Node.js tools, Go binaries, sandboxes and MCP servers. Those are the clients that do not check revocation. An agent calling a model API through an old trust store could, in principle, be shown a forged certificate by anyone in the network path, and send prompts, files or credentials to the wrong server. There is no report of that happening; the point is where to look first when updating.

Agents suggest the wrong fix. A coding agent that meets a certificate error may propose switching verification off, because that makes the error go away. That is a plausible and harmful suggestion, so review it like any change that removes a safety check. Beam records the commands and file changes coding agents make and flags risky patterns, so a disabled-verification flag is visible in review. It does not inspect your trust stores or TLS traffic.

Long-lived sandboxes. Dev containers and agent sandboxes are often built once and reused for months, so their trust stores age silently.

New for defenders: nothing about trust changed in kind. The fast reaction in this incident was built from old machinery (revocation lists, transparency logs). What AI changes is how many non-browser clients are making calls on your behalf.

Try it

Everything here is on your own machine and only reads.

1. See where your tools keep their trust. For Python:

python3 -c "import certifi; print(certifi.where())"

If that fails, certifi is not installed, which is also a useful answer. On Linux, look at /etc/ssl/certs/ca-certificates.crt. On macOS, count the system roots:

security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain | grep -c "BEGIN CERTIFICATE"

2. Look at a real chain. This is an ordinary connection to a public site and changes nothing:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

Note the issuer. That is the intermediate that signed the site's certificate.

3. Run the curl test above and write down whether it failed. If you use Go, Node.js or containers, check their versions against the table, and note when each container image was last built.

4. Search a project of yours for verify=False, InsecureSkipVerify and rejectUnauthorized. Each hit needs an explanation.

Check yourself

Next

You now have four tools: knowing what you run, spotting hostile packages, protecting pipelines and keeping trust current. In the last lesson of the level, you use them on a real case file: October 2026's incidents.