Google and Mozilla have introduced emergency security protections after private keys associated with eight intermediate digital certificates issued by eMudhra were reportedly compromised. The incident has raised concerns about the security of the certificate infrastructure that helps browsers verify website identities and establish encrypted HTTPS connections.
According to the report published by The420.in on October 21, 2026, the affected keys were generated with insufficient cryptographic randomness, potentially making them vulnerable to compromise. If an attacker obtains the private key associated with a trusted certificate authority, they may be able to create fraudulent certificates and make an unauthorised website appear to be legitimate.
Both browser providers moved to block the affected certificates. Their response highlights the importance of rapid security updates when a weakness threatens the systems that underpin online trust.
What Happened in the eMudhra Certificate Incident?
The reported incident came to light on October 17, 2026, when Google and Mozilla received information about compromised private keys linked to eight eMudhra intermediate certification authority certificates.
Digital certificates play an important role in online security. They help browsers verify that a website is associated with the domain it claims to represent. When a browser establishes an HTTPS connection, certificate validation helps protect users against impersonation and certain types of interception.
The concern in this case was not simply that individual websites might have outdated certificates. Compromised certificate authority keys can potentially undermine trust in a much broader range of online connections.
If misused, the affected keys could allow an attacker to issue fraudulent certificates for domains they do not control. Depending on the circumstances and the security controls in place, those certificates could support website impersonation or attempts to intercept communications.
However, the supplied report does not establish that the compromised keys were used in a successful attack against individual users. A key compromise creates a security risk, but it does not by itself prove that fraudulent certificates were issued or that user communications were intercepted.
How Google Protected Chrome and Android Users
Google responded through its Chrome Root Program, which received the security report at 18:05 UTC on October 17. According to the source, the company completed its initial protective action by 19:45 UTC.
Google deployed an update to Chrome's Certificate Revocation List Set, commonly known as CRLSet. This mechanism enables Chrome to block certain certificates without requiring users to download and install a complete browser update.
The protection was designed to reach Chrome users without requiring a manual update or browser restart. Google also applied equivalent protections to Android devices and its applications through Google Play services at approximately 22:00 UTC, according to the report.
Google said most Android devices had already received the protection. Restarting a device could prompt the relevant update to take effect sooner in some circumstances.
The report also noted that no certificates issued through six of the affected intermediate authorities had appeared in Certificate Transparency logs before Google blocked them. These logs help make certificate issuance publicly auditable. The absence of logged certificates was relevant to clients that require Certificate Transparency compliance, but it should not be interpreted as proof that every possible misuse was ruled out.
What Action Did Mozilla Take?
Mozilla also moved quickly to protect Firefox users after receiving its report at 20:06 UTC on October 17.
The company used its OneCRL system to block the affected certificates. According to The420.in, distribution of the updated blocklist to Firefox users with standard configurations was completed by 22:59 UTC, less than three hours after the report was received.
Mozilla also announced browser releases intended to extend protection to users whose customised settings might prevent them from receiving the standard OneCRL update. The versions identified in the report were Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1, and Firefox ESR 153.5.1.
These measures illustrate why browser security depends on more than the software installed on a user's device. Browsers must also maintain current information about which certificates can be trusted and which should be rejected.
Will eMudhra Certificates Remain Trusted?
Google has reportedly removed the eSign ECC Root CA – G3 certificate, which signed the compromised intermediate certificates, from the Chrome Root Store. This action may affect legitimate websites that depend on the affected certificate chain.
For website operators, the practical concern is whether browsers will continue to accept their existing TLS certificates. If a site's certificate depends on a distrusted chain, visitors could encounter browser security warnings or connection failures.
Google advised affected website operators to obtain replacement TLS certificates from another trusted certificate hierarchy. Website administrators should assess their certificate chains and follow instructions from their certificate provider and the relevant browser root programs.
Mozilla is also updating its Network Security Services (NSS) trusted certificate list through NSS 3.131.1, according to the report. Google is reportedly investigating whether eMudhra's remaining certificates should continue to be trusted.
The distinction is important: blocking specific compromised keys and reconsidering trust in a wider certificate chain are related but separate security decisions. Any further action may depend on the investigation's findings and the providers' root-program policies.
What Should Website Owners and Internet Users Do?
Although browser vendors have taken protective measures, organisations should verify that their systems are using current security updates and that their certificates remain valid and trusted.
Website owners and IT administrators should:
Review TLS certificates: Check whether any website or service relies on an affected eMudhra certificate chain.
Contact the certificate provider: Obtain authoritative guidance on replacement certificates and any required migration steps.
Monitor browser compatibility: Test websites across supported browsers and devices for certificate warnings or connection failures.
Keep systems updated: Apply browser, operating-system and relevant security-service updates through official channels.
Investigate unusual alerts: Treat unexpected certificate warnings seriously rather than advising users to bypass them.
For businesses, the incident is a reminder that online security also depends on maintaining reliable technical controls and clear incident-response procedures. Organisations reviewing their broader operational risks may find it useful to explore Shunyatax's Other Services for information about its wider business support offerings.
Individual users should keep their browsers and devices updated and avoid proceeding through certificate warnings on unfamiliar or sensitive websites. If a warning appears on a trusted service, they should contact the website's official support channel instead of ignoring the alert.
Why the Incident Matters for Digital Trust
The security of HTTPS relies on a chain of trust involving certificate authorities, browser vendors, software updates and website operators. A weakness in one part of this system can require coordinated action across multiple products and platforms.
The reported eMudhra incident demonstrates how quickly browser providers may need to respond when certificate keys are considered unsafe. Blocking affected certificates can reduce the risk of fraudulent certificates being accepted, while replacement certificates and trust-store changes help restore confidence in the affected infrastructure.
The longer-term lesson is that strong cryptographic key generation, careful certificate management, transparent reporting and independent security checks are essential to protecting digital services.
Conclusion
Google and Mozilla have reportedly taken emergency steps to block compromised eMudhra certificate keys and reduce the risk of fraudulent website certificates being trusted by their users. The response included browser-level protections, Android safeguards and changes to certificate trust arrangements.
The supplied report does not confirm that the compromised keys were used in a successful attack on users. Nevertheless, the incident highlights the potential consequences of weaknesses in digital certificate infrastructure and the need for prompt, coordinated security action.
Website operators should verify their certificate dependencies and follow official replacement guidance, while users should keep their software updated and pay attention to browser security warnings.