Mozilla, Google, Apple Block Eight Weak eMudhra CA Keys

Eight eMudhra CA intermediate keys were so weak they could be computed, so Mozilla, Google, Apple and Go blocked them and eMudhra revoked the certificates.
Table of Contents
    Add a header to begin generating the table of contents

    Mozilla, Google and Apple have blocked eight intermediate certificates issued by India-based certificate authority eMudhra after researchers found that the private keys behind them were so weak that anyone could compute them. The Go project followed with emergency releases on Tuesday, and eMudhra has revoked the certificates and halted issuance under its G3 root.

    How Eight eMudhra Intermediate Keys Were Recoverable by Simple Guessing

    Mozilla received a report at 20:06 UTC on Saturday that private keys for eight eMudhra intermediate certificates were compromised. Six of the intermediates issued TLS certificates and chain to the emSign Root TLS CA – G3. The other two are code-signing intermediates that chain to the emSign Root CS CA – G3. eMudhra operates under the emSign brand and claims to have issued more than 60 million certificates.

    The keys were not stolen. They were so weak that they could be derived by anyone. All eight used P-384 private keys generated in April 2025 whose values were smaller than 256, meaning an attacker could recover each key by testing 256 numbers. One published key, for the intermediate named “EM OV TLS CA – G3C,” had the value 4.

    Wayne’s Discovery and Mozilla’s Two-Hour Key Recovery

    A researcher known as Wayne found the weakness on Saturday while scanning public certificate data. Mozilla then recovered the keys within two hours, and researchers have since published them. Anyone holding the keys could forge certificates that chain to eMudhra’s roots for any website, in any software that has not yet blocked the intermediates.

    eMudhra’s Explanation: A Faulty Key Ceremony Script

    eMudhra blamed an error in a script used during the April 2025 key ceremony. The script produced a second, weaker set of keys, and those were mistakenly selected for signing. Some of the certificates were also submitted to Sectigo for cross-signing. The company said most of the affected intermediates were never used in production and that it found no evidence of end-user certificates issued with them. Whether anyone abused the keys between April 2025 and the discovery is not known. eMudhra published a statement on the root cause on Wednesday.

    The practical stakes are straightforward. Anyone who holds the published keys can sign a certificate for any website that software built on the affected roots would accept, until that software carries a block. eMudhra says it found no evidence of end-user certificates issued with the intermediates, but the company has not been able to say whether anyone abused the keys.

    Browser and Software Responses to the eMudhra Compromise

    Browsers and software vendors moved quickly to contain the compromised eMudhra keys. Mozilla, Google and Apple blocked the TLS intermediates, and the Go project shipped patched toolchain releases.

    Mozilla OneCRL, Chrome and Apple Distrust the TLS Intermediates

    Mozilla blocked the six TLS intermediates through its OneCRL mechanism on Saturday, so standard Firefox installations needed no browser update. Google Chrome also blocked the TLS intermediates and said none had been logged to Certificate Transparency, so none would be trusted by default. Apple blocked them as well. Firefox and Chrome applied their blocks within hours of the report.

    Go 1.27.3 and Go 1.26.10 Reject Chains Using the Eight Keys

    The Go project shipped Go 1.27.3 and Go 1.26.10 on Tuesday on its URGENT release track. The releases reject any certificate chain that uses the eight keys. Because the fix is built into the toolchain, applications written in Go must be rebuilt to receive it. Other free and open-source projects have issued their own updates.

    Why Software Without Blocklist Updates Remains Exposed

    The distrust actions protect browsers that receive blocklist updates, but software that ships its own certificate stores, or that has not been rebuilt or patched, can still accept chains built from the compromised intermediates. Clean-up across software ecosystems is ongoing.

    The case also puts the key ceremony itself under scrutiny. A script error in a procedure designed to produce high-assurance keys went unnoticed for roughly 18 months, from April 2025 until a public scan caught it. Certificate Transparency logging, which Chrome cited when it said none of the intermediates had been logged, gave browsers a quick way to judge exposure, but the weak keys were visible to outside researchers well before any CA-side control flagged them.

    Related Posts