eMudhra Trust Checks Must Reach Beyond the Browser
Updating a browser is only one part of the response to eMudhra’s compromised certificate-authority keys. Applications using Mozilla’s certificate list, services built with Go and organisations replacing certificates have separate delivery paths. One older Firefox branch also has a newly documented startup problem: a fixed test build is not the same as an update already available to every user.
The distinction matters as the certificate authority’s investigation continues. In its 30 October statement, eMudhra announced KPMG as its independent external reviewer. Its 28 October update describes a transition through its G1 RSA hierarchy while customers move away from publicly trusted eMudhra TLS services. Neither announcement establishes that every relying application has stopped trusting the compromised certificates.
Eight weak issuing keys, a wider trust problem
Mozilla’s primary incident record distinguishes eight intermediate certificates from the roots above them. Six were for TLS and two for code signing. Mozilla independently confirmed that the keys were recoverable because their generation was defective. This was not a demonstrated break of the P-384 cryptographic algorithm.
Mozilla received the forwarded report at 20:06 UTC on 17 October. By 22:59 UTC, its OneCRL block had reached normally configured Firefox installations. eMudhra recorded revocation of the eight certificates on 18 October. Those are different events: publishing a revocation does not prove that every application has obtained and applied it, or that it checks every issuing certificate in a chain.
eMudhra says it did not issue customer end-entity certificates from the eight weak intermediates and has found no evidence of their exploitation before disclosure. That is the company’s stated investigation finding, not an independent all-clear. The public incident discussion also records certificates created by other people after disclosure. Key recovery and publicly demonstrated certificate issuance do not, by themselves, prove interception of someone’s traffic.
Firefox ESR 115 needs a separate check
Mozilla’s 20 October response and 21 October follow-up cover the bundled blocklist delivered to clients that missed the dynamic update, plus an Android startup correction in 158.0.2. These changes are tracked under CVE-2026-113470. The older release numbers in that announcement are historical fix baselines, not today’s routine update targets.
A later Mozilla ESR 115 bug reports that OneCRL initialisation could wait for 20 seconds without user input. The record reproduces the problem in a clean 115.44.0esr profile. Continuous activity could delay the initialisation rather than guarantee that the blocklist had loaded soon after startup.
The bug is marked verified fixed, with Mozilla’s quality-assurance comment identifying a 115.45.0 ESR Treeherder build tested on Windows, macOS and Ubuntu. However, the official version feed checked on 1 November still lists 115.44.0esr, alongside regular Firefox 159.0 and ESR 153.6.0esr. Do not describe that test-build verification as proof that a public 115.45 update has already reached users. Keep the ESR 115 exception visible, follow Mozilla’s release guidance and plan a move from older systems where practicable.
NSS and Go have their own delivery paths
For applications using Network Security Services, Mozilla’s 20 October NSS 3.131.1 announcement removes trust in emSign ECC Root CA – G3. This helps consumers that use Mozilla’s trust list without receiving Firefox’s intermediate-certificate blocks. The same release removes C1 and C3 roots too; eMudhra says those removals were planned separately. They should not be described as three compromised root keys.
The operator’s question is which NSS library and trust database the deployed application actually uses. A desktop browser update supplies no evidence that a separately packaged service, container or appliance has changed. Use the application or distributor’s supported update route, then verify its deployed library and trust data. Do not restore a distrusted root or disable certificate validation to make a failing connection succeed.
Go’s official advisory describes a narrower defence in the standard library’s certificate verifier, tracked as CVE-2026-111943. Most platforms use system roots, but some cases need further action for trust changes to take effect. The added denylist makes crypto/x509.Certificate.Verify reject the known untrustworthy intermediates.
The 19 October releases delivered that fix in Go 1.27.3 and 1.26.10. For an affected application built with an older toolchain, establish whether its maintainer has rebuilt and redeployed it with the correction. Changing a compiler on a build host does not update a binary already running elsewhere. Distribution package revisions and vendor appliances need their own verified remediation evidence.
Replace the chain and verify the result
The migration population is broader than the eight weak keys. eMudhra’s 28 October update puts roughly 30,800 certificates under the affected G3 hierarchies in a US customer ecosystem. That is not a count of certificates known to have been issued using the weak keys, or of intercepted connections. The company says that ecosystem is using a G1 RSA issuance pathway during its transition and that G1 TLS issuance will end once that transition finishes. The statement does not supply a universal completion date or guarantee acceptance by every client.
For each affected service, identify the certificate chain actually served and the clients that depend on it. Obtain the provider’s replacement instructions, deploy the intended replacement and verify the complete chain from representative clients without weakening trust checks. Our separate Webex SIP review covers Cisco’s specific 2 November change; its deadline should not be generalised to every application in this incident.
Record the application owner, installed build, trust-store delivery path, replacement chain and verification time. Keep any unsupported client or unresolved ESR 115 deployment visible until its own correction is available and verified. Browser containment, service rebuilds and certificate replacement are separate pieces of evidence. Closing one does not close the others.
