Answers · security
How can an agent trust what it gets back when TLS certificates can be forged?
Short answer: Don't rely on the connection alone. Check a signature made with a key you pinned in advance. TLS stays essential; this adds a second, independent check. Rightshold signs its API answers with its own Ed25519 key (RFC 9421) and records every key rotation and revocation on its public, Bitcoin-anchored ledger.
What happened
- On Oct 20, 2026 Ars Technica reported that eight intermediate TLS certificates belonging to the Indian certificate authority eMudhra had private keys so weak they could be recovered, so anyone holding them could have minted browser-trusted certificates for any website.
- The intermediates chain to eMudhra's ECC root (emSign ECC Root CA - G3). Chrome blocked them with a CRLSet update by key hash, Firefox through OneCRL; browser root programs also distrusted that root. eMudhra revoked the eight intermediates and says no certificates were issued from them.
- No misuse has been reported, and Google says no certificates chaining to them were logged to Certificate Transparency before the block. The remaining risk is the long tail: Linux distributions, containers, IoT devices and CLI tools that carry their own copy of the trusted roots and update slowly.
Why agents should care
- Many agents run exactly where that long tail lives: containers, scripts and runtimes with bundled root stores (for example Python's certifi).
- An attacker who can sit on the network path and holds a trusted forged certificate can impersonate an API and change its answers. A license verdict, a receipt or a key fetched over that connection would look normal.
- TLS can't detect this on its own; that is why browsers added Certificate Transparency. The same idea applies to agent answers: verify the content, not just the pipe.
What to do
- Update your system and language root stores (e.g. `apt install --only-upgrade ca-certificates`, update certifi / Node / Java CA bundles) and make sure emSign ECC Root CA - G3 is no longer trusted.
- Pin the signing key of the services your agent relies on, obtained once through an independent path, and verify signatures on what they return.
- Prefer services whose keys and key changes are publicly logged, so a silent key swap is visible.
What Rightshold does (and doesn't)
- Rightshold does not fix, replace or monitor TLS, and it is not a certificate authority. It gives agents a way to check Rightshold's own answers independently of the connection.
- Buffered answers from /v1/*, /mcp, /.well-known/* and /llms.txt carry an RFC 9421 HTTP Message Signature (label rs, tag rightshold-response) covering the status, host, path and a SHA-256 of the body (Rightshold-Body-Digest).
- https://www.rightshold.com/.well-known/rightshold-keys.json lists every issuer key with its status (current, retired, revoked) and an SPKI SHA-256 pin. https://www.rightshold.com/v1/keys/check?spki_sha256=... answers whether a key is still trusted.
- Key rotations (issuer.key_rotated) and revocations (issuer.key_revoked) are entries on the public ledger: hash-chained, signed, and timestamped in Bitcoin through OpenTimestamps, so a key swap can't be hidden.
- Know Your Agent credentials and receipts are signed by the same issuer keys; a revoked key verifies nothing.
Check it yourself
curl -s https://www.rightshold.com/.well-known/rightshold-keys.json -o rightshold-keys.json
curl -s https://www.rightshold.com/cli/ledger-witness.mjs -o ledger-witness.mjs
node ledger-witness.mjs verify-response --url https://www.rightshold.com/v1/licenses/MIT --keys rightshold-keys.jsonSources
- Ars Technica: The Internet goes on high alert after discovery of 8 compromised TLS certs (Oct 20, 2026)
- Google Security Blog: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
- Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
- eMudhra statement on the certificate security incident
- RFC 9421: HTTP Message Signatures