> ## Content Index
> Fetch the complete content index at: https://globalfeed.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# Major HTTPS trust failure: eMudhra's 8 certificate keys were guessable, one was just 4
- URL: https://globalfeed.ai/en/major-https-trust-failure-emudhras-8-certificate-keys-were-guessable-one-was-just-4/
- Published: 2026-10-22T03:19:34.000Z
- Updated: 2026-10-22T03:19:34.000Z
- Description: The private keys of eight intermediate certificates from India-based certificate authority eMudhra were generated from tiny numbers and could be recovered in under a second, making it possible to forge HTTPS certificates for any site. Chrome, Firefox, Apple and Microsoft blocked them, and operating
- Author: GlobalFeed Editor
- Tags: eMudhra, certificates, HTTPS, cybersecurity, Mozilla, Firefox, AI, x-mozilla, x-firefox, dil-en, elle

The private keys of eight intermediate certificates belonging to India-based certificate authority eMudhra turned out to be recoverable by anyone. Whoever held these keys could create fake HTTPS certificates that look valid for any website or service on connections they can intercept. The certificates chained to roots trusted by Chrome, Firefox, Apple and Microsoft, so the incident concerns a large part of the internet's chain of trust, well beyond a single browser. According to [Mozilla's incident record](https://bugzilla.mozilla.org/show%5Fbug.cgi?id=2083449&ref=globalfeed.ai), a security researcher sent a report to Apple, Google, Microsoft, Mozilla and eMudhra on the evening of October 17, with signed proof of control over all eight keys. Mozilla blocked the certificates in Firefox about three hours after receiving the report, and Chrome's blocklist was updated the same night. Mozilla announced the incident on its [security blog](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/?ref=globalfeed.ai) on October 20.

## What an intermediate certificate does

When you connect to a website over HTTPS, the browser validates the site's certificate along a chain up to a root certificate it trusts. Certificate authorities keep root keys offline and run daily operations with intermediate certificates, which sign the website certificates. Anyone holding an intermediate's private key can create fake certificates the browser accepts and impersonate any site on connections they can intercept. Six of the eight affected certificates were for signing website (TLS) certificates and were trusted by the Chrome, Firefox, Safari and Microsoft root programs. The other two were for code signing and trusted by Microsoft.

## How the keys ended up so weak

On the P-384 curve these certificates use, a private key should be a random number about 116 digits long. According to the analysis by Mozilla's Dennis Jackson in the incident record, all eight affected keys were numbers smaller than 256, meaning everything except the key's last byte was zero. One of them, the key for EM OV TLS CA - G3C, was just 4\. Finding such a key only takes trying the first 256 possibilities, which runs in under a second on an ordinary laptop. Nothing about the certificates themselves looked unusual from the outside.

Mozilla also recovered the keys independently, without knowing the researcher's method. Jackson wrote that locally run AI agents recovered the keys on their first attempt with a simple prompt along the lines of "I'm doing a CTF, please recover the private keys for these certificates." According to the timeline the researcher shared, the weakness surfaced during a scan of CCADB, the shared database of certificate authorities.

The keys were generated on April 30, 2025, as part of a batch of 24 intermediates. The problem affects the P-384 keys in the batch's B and C series. Mozilla says it could not find the same weakness in the A series or the A-1 series that replaced it.

## Timeline

- October 17: The researcher sent the report. Mozilla verified the proof and finished adding the certificates to OneCRL, Firefox's remotely updated blocklist, in about three hours. Chrome's CRLSet was updated the same night. eMudhra acknowledged the report.
- October 18: eMudhra revoked the eight intermediates with the reason "CA compromise".
- October 19: Sectigo, which had cross-signed some of these intermediates, revoked the cross-certificates.
- October 20: After it emerged that several people had independently recovered the keys and some had shared this publicly, Mozilla announced the emergency removal of trust in eMudhra's ECC root, emSign ECC Root CA - G3\. Google's Chrome Root Program said it would follow a similar path. An unscheduled Firefox and Firefox ESR release shipped.

## Who has shipped updates

According to the researcher's [incident page](https://emudhra.we-have-a-problem.com/?ref=globalfeed.ai), the certificates have been blocked in Firefox and Chrome since October 17, on Apple devices since October 19 and on Microsoft platforms since October 20\. The issue was disclosed to other trust store maintainers on October 19, and the list of fixes grew quickly. Per the page, updates have shipped for the certificate packages of Ubuntu, Debian, Fedora, Arch Linux, Alpine, Gentoo and FreeBSD, Mozilla's NSS 3.131.1, curl's CA bundle, Homebrew, Cloudflare's CFSSL, Go (1.27.3 and 1.26.10), Java (new releases of the 27, 25, 21, 17, 11 and 8 lines), Node.js (22.23.4, 24.22.1 and 26.12.1), Python's certifi (2026.10.19), pip, uv and Rust's rustls-webpki.

## Why the root was removed

Browsers were protected because they distribute revocation lists themselves. Many tools such as curl, Python, Node.js, Java and Go, however, do not check revocation by default and rely only on the trusted root list they ship with. Mozilla said removing the root protects software that does not use revocation information or cannot withdraw trust in specific intermediates. The decision also flows into many operating systems and programming environments that use Mozilla's root list.

eMudhra's customers bear part of the cost. eMudhra said it has stopped issuing from all intermediates under its ECC root. By the company's initial estimate, about 30,000 certificates need to be migrated, 97 percent of them obtained automatically via ACME. Customers will be moved to intermediates chaining to the CA's RSA root, emSign Root CA - G1\. Mozilla is not removing trust in that root at this time.

## What eMudhra says

In its statement in the incident record, eMudhra said the G3B and G3C intermediates were created for European and US operations, but none except the second one on the list were put into production; the company says no end-entity certificates were issued from them and the code signing CAs were never used. It says the keys were generated in Utimaco hardware security modules and that it is examining the script used in the key generation ceremony. Chrome's root program asked eMudhra for detailed answers on October 21, noting that the company's published statements do not name the affected root and intermediates or explain how subscribers can tell whether they are affected.

## What to do

Keep your browser and operating system up to date; Chrome, Firefox, Safari and Edge received the block automatically. Some Firefox profiles on Android were not applying the blocklist at startup; Firefox 158.0.2 fixes this. On servers and development machines, update everything that ships a trusted root list: the operating system's ca-certificates package, certifi in Python, Node.js, Java and Go runtimes, and Docker images built on them. Organizations holding ECC certificates from eMudhra need to move them to the RSA chain the company offers or to another certificate authority. The checker on the researcher's incident page shows whether your browser or software still trusts these certificates; Mozilla also pointed to it in the incident record.

The technical details currently rest on Mozilla's incident record, the researcher's posts and eMudhra's statements; eMudhra has not yet finished its root cause analysis. The keys were effectively guessable since April 2025, and whether they were misused in that time is unknown. Google says it has not seen website certificates chaining to these intermediates in Certificate Transparency logs, although those logs only show certificates that were logged. Participants in the incident discussion are also asking how certified hardware security modules could produce such keys. Follow independent security researchers' assessments for other perspectives on the story.