Notes on coding agents and the pages they leave behind, on moving between notes apps, and on the plain mechanics of keeping what you think. Written and published from a Sumibako vault.
eMudhra's compromised certificates: a private key that was the number 4, and what to check before 27 October
Eight eMudhra keys were integers under 256, one of them 4. Why browsers blocked them in hours, why your Docker image did not, and what to check by 27 October.
Prashant Shaw
Founder, Sumibako
10 min read
Every secure website rests on a short chain of trust. Your browser trusts a few dozen certificate authorities. Those authorities sign certificates for websites, and the signing is done with private keys that are supposed to be enormous random numbers, unguessable by anyone with every computer on Earth and the lifetime of the universe.
On 17 October a researcher found that eight of those keys, belonging to the Indian certificate authority eMudhra, were small integers. One of them was 4. I have had longer codes on a gym locker, and the gym locker only guarded a towel.
I have spent a week reading the incident record, which Mozilla keeps in public, and it is the most interesting security story of the month precisely because nobody attacked anyone. This is what happened, why your browser was never in danger, why your Docker image might be, and what a site owner should check before 27 October.
🎲 A private key is a very large random number. Eight of these were not.
Dennis Jackson of Mozilla explained the failure in the incident bug in terms a child could follow: "P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte." Recovering such a key is a loop that runs 255 times. Someone published the key for one of the intermediates in a gist with the line "If anyone wonders how to reconstruct the private key from 4".
The finder is a researcher called Wayne, who ran Google's open source paranoid_crypto checks over the public corpus of certificate authority keys and reported to Apple, Chrome, Microsoft, Mozilla and eMudhra at 18:05 UTC with signed proof that he held the keys. On the public mailing list he was asked how, and answered: "I've had more than a few emails asking on how this was discovered. The simple answer is:
". Mozilla did not take his word for it. From the bug: "Mozilla was able to recover the private keys for the impacted certificates independently @ 21:48 UTC and without any knowledge of the method the original reporter used, confirming the key generation process was flawed and is trivial to exploit."
What a 384-bit key looks like when it is the number 4.
Jackson's assessment: "As this incident enables even technically unsophisticated individuals to easily recover the private keys for these intermediates, the impact of this incident could not be higher."
🏭 How a hardware security module produces the number 4
The eight keys came from a key generation ceremony on 30 April 2025 that produced 24 intermediate certificates. eMudhra's account is that "During the ceremony, a key wrap/unwrap step produced a second, weak set of keys alongside the original strong keys. The weak keys were the ones published to the browser root stores. The issue went undetected for about 18 months, through two independent audit cycles." In the bug, eMudhra is more specific about how the wrong set got picked: "these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root".
There was a warning, and it was read as a nuisance. In May 2025 the revocation lists for these intermediates were signed with the wrong keys, which produced invalid signatures. eMudhra's explanation: "The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys." Two key pairs where there should have been one, and the response was to use the one that made the error go away.
eMudhra insists the hardware was proper: "The keys were generated on FIPS 140-2 Level 3 certified Hardware Security Modules (HSMs). Suggestions that HSMs were not used are incorrect." It also says "We have not yet confirmed the exact root cause." Several people in the bug thread argue that a certified module cannot produce a 384-bit key under 256 on its own, which would mean the key material came from outside it. As of 24 October, Mozilla's written questions from 20 October are unanswered.
🛡️ Why your browser was fine
This is the part of the story the headlines skipped. The eight intermediates had issued no certificates to anyone before they were blocked. eMudhra: "none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates." And browsers now require every certificate to be published in Certificate Transparency logs before they will trust it. Chrome's statement: "Because no TLS certificates chaining to these six intermediate CAs were logged to CT prior to our CRLSet block on October 17, no fraudulent certificates issued by these CAs could have been trusted by default in Chrome or other CT-enforcing browsers."
The blocks were fast. Chrome: "At 19:45 UTC, Chrome completed corroborating the findings and landed a CRLSet update blocking the Subject Public Key Info (SPKI) hashes of all six affected TLS-issuing intermediate CAs." Mozilla: "By 22:59 UTC that same day, in less than 3 hours after we received the report, the updated OneCRL distribution was complete for all Firefox users with standard configurations." Apple began blocking on 19 October, Android the same evening, Microsoft on the 20th. Neither Chrome nor Firefox needed you to update anything; the blocklists travel on their own.
Who
When (UTC)
What
The researcher
17 Oct 18:05
Reports to Apple, Chrome, Microsoft, Mozilla and eMudhra with proof of key control
Chrome
17 Oct 19:45
Blocklist update covering the six TLS intermediates by key hash
Mozilla
17 Oct 21:48
Recovers the keys independently; Firefox block complete at 22:59
eMudhra
18 Oct 09:24 to 09:38
Revokes all eight certificates, reason cACompromise
Apple
19 Oct
Begins blocking the TLS intermediates; the root follows on 23 Oct
Android
19 Oct, about 22:00
Block delivered through Google Play Services
Microsoft
20 Oct
Block
Mozilla
20 Oct
Removes emSign ECC Root CA - G3 from its trust store
Chrome
27 Oct
Chrome Root Store without the root reaches all devices
After disclosure, people proved the point the loud way. From the ctlogs.dev timeline: "certificates for google.com signed with these keys are already public (over 100,000 of them, listed below), so intercepting their traffic needs nothing more." Scott Helme's summary is the one I would put on a slide: "Here, nobody had to steal anything. The key was effectively public from the day the certificate existed,"
🐳 Why your Docker image was not
Browsers check transparency logs and revocation lists. Almost nothing else does. A Go binary, a Python script with its own certificate bundle, a container image built last month, an Electron app, the curl on a Mac: each carries a list of trusted authorities and believes it until someone rebuilds it. Jackson's tracker says so plainly: "However, many clients outside of the browser ecosystem do not enforce Certificate Transparency. We do not know if attackers exploited the flawed key generation to target these clients." The keys were weak from April 2025, so that question covers eighteen months.
The fixes arrive as ordinary updates, which is the quiet lesson. BleepingComputer: "The Go development team released versions 1.27.3 and 1.26.10 to address the issue, tracked as CVE-2026-111943." Node.js's 21 October security release lists a trust store update for the eMudhra compromise among its dependency changes, which I only noticed because I was patching Node for other reasons. Apple's support note has a paragraph for developers: "some command-line tools included with macOS or the Xcode Command Line Tools (including curl, git, python3, ruby, perl, and openssl) check certificates against /etc/ssl/cert.pem." and those ignore Apple's block until a future update, so Apple publishes the commands to edit the file by hand.
If you build software: rebuild your images, update Go, update ca-certificates and certifi, and test against the hosts on the tracker page. A curl that succeeds there still trusts the keys.
🏫 30,000 certificates and a deadline of 27 October
Blocking the eight intermediates was the easy part. On 20 October Mozilla removed the root above them, emSign ECC Root CA - G3, from its trust store, Apple followed on the 23rd, and Chrome's announcement sets the date everyone is now working to: "This root removal is expected to be released for all devices relying on the Chrome Root Store Tuesday morning, October 27, 2026 PDT". Every certificate that chains to that root stops working in Chrome that morning.
How many is that? eMudhra in the bug: "As per initial estimates there are about 30,000 certs that require migration and about 97% came via ACME." Chrome counted 30,800 and added the detail no news report has: 30,791 of them, 99.9%, were issued by two InCommon intermediates. InCommon serves American universities and research networks. The organisations scrambling this week are not eMudhra's customers in any ordinary sense; they are universities whose certificate provider happened to chain through an Indian root, and most of them will learn this from a browser warning.
If a site is yours, check the chain now, with the padlock in a browser or from a terminal, and look for emSign ECC Root CA - G3, emSign Root TLS CA - G3 or an InCommon intermediate ending in G3B or G3C.
A key committed in May became a credential stealer on PyPI in October; five OVHcloud CLI releases were swapped for 94 minutes. What to do if you got either.
10 min read
shellscript
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | grep -i issuer# issuer=C = US, O = Let's Encrypt, CN = YR2 <- what Sumibako's own check printed``` If you find one, get a replacement from another hierarchy today. Automated renewal will not save you: ACME clients renew on schedule, not on news, unless they support renewal information or someone runs them by hand. Certificates under eMudhra's older RSA hierarchy are not affected; Mozilla kept that root.## 🚪 Five days from report to quittingThe incident record also shows how root programs police a certificate authority in public, and it is not gentle. eMudhra's [press release](https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca) on 21 October noted that the business "accounts for around 1% of the company's revenue." On the 22nd it announced it had "decided to voluntarily withdraw from the global SSL/TLS certificate business". On the 23rd its representative wrote in the bug that "we have been subject to intense social media scrutiny and analysis by investors/customers over the last few days and it has made doing any meaningful analysis of the event pretty much impossible." Chrome's reply was that scrutiny and investor analysis "are not acceptable explanations for delayed responses here."For scale: DigiNotar was [hacked in 2011](https://en.wikipedia.org/wiki/DigiNotar), issued hundreds of fraudulent certificates that were used against Iranian Gmail users, and was bankrupt within three months. Symantec's certificates were [distrusted in 2017](https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html) over a pattern of misissuance, with a year of runway. Entrust was [distrusted in 2024](https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html) for conduct. eMudhra is the odd one out: no attacker, no known misuse, blocks within hours, and out of the business in five days. The system worked. It worked because the system no longer trusts anyone, including the authorities, which is the correct amount.## ✅ What to do, by who you are1️⃣ If you just use the web: update your browser and your phone, and you are done. If a university site shows a certificate warning in late October, that is why.2️⃣ If you build software: rebuild container images, update Go to 1.27.3 or 1.26.10, update your certificate bundles, patch Node, and test against the tracker's hosts. Then ask what else in your stack trusts a list nobody refreshes.3️⃣ If you run a site: check the chain for the names above before 27 October. If your host issues your certificate, ask them which root it chains to. Most small sites are on Let's Encrypt or their host's issuer and are fine; the ones that are not will not be told in advance.The wider week is in [the state of the internet this month](https://sumibako.com/blog/cybersecurity-october-2026), and the habit of knowing who vouches for you is one line of [the checklist for the next one](https://sumibako.com/blog/developer-security-checklist-2026). I checked Sumibako's chain while writing this. It is not eMudhra. It took forty seconds, which is about the time it takes to count to 255.## 📚 Sources and credits- [Bug 2083449: eMudhra weak intermediate keys](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449), the Mozilla CA Program's public incident record, with comments by Dennis Jackson (Mozilla), the Chrome Root Program and eMudhra.- [The dev-security-policy thread](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE), including the researcher Wayne's note on how it was found.- [Protecting Firefox users following the compromise of eMudhra intermediate certificates](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/), Mozilla Security Blog, 20 October 2026.- [Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/), Google.- [Apple support note 149555](https://support.apple.com/en-us/149555), including the command line tools caveat.- eMudhra's [incident page](https://emudhra.com/en/post/certificate-security-incident) and [press release](https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca).- [emudhra.we-have-a-problem.com](https://emudhra.we-have-a-problem.com/), Dennis Jackson's tracker and test hosts; [the gist publishing the key](https://gist.github.com/Fluepke/9a103c7f990c3cc2fb5002f7476f2f48); [ctlogs.dev timeline](https://ctlogs.dev/blog/emudhra-ca-compromise).- [Mozilla, Google, Apple block compromised eMudhra CA certificates](https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/), BleepingComputer; [eMudhra certificates' private keys compromised](https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/), Help Net Security, with Scott Helme's comment.- For the comparisons: [DigiNotar](https://en.wikipedia.org/wiki/DigiNotar) on Wikipedia, and Google's posts on [Symantec, 2017](https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html) and [Entrust, 2024](https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html).
