A fake website does not always have to look suspicious. If a browser trusts the wrong digital certificate, even a fraudulent site could potentially appear to have a legitimate HTTPS connection.
That is what made a security flaw involving eight eMudhra intermediate certificate authorities a concern. The weakness affected private keys that help establish trust in website certificates. An attacker who obtained a compromised key could potentially use it to create a fraudulent certificate and impersonate a legitimate website, if the software connecting to it still trusted the affected authority.
Browser companies moved to block the affected certificates, but the response was not necessarily the same for every application or device. Some applications rely on their own certificate stores and may require separate fixes, leaving developers with additional work beyond updating a browser or operating system.
There is an important distinction between the risk and what has actually been confirmed. The incident does not mean HTTPS was broadly compromised, that legitimate websites were taken over, or that users’ passwords were stolen. eMudhra said the affected intermediate authorities had not issued end-entity certificates and that it had found no evidence of an infrastructure compromise or data breach. Its investigation was still ongoing in its latest statement available at the time of writing.
So what went wrong, how can a certificate flaw undermine trust in a website, and why might updating your browser not be enough to protect every application? Here is what the evidence shows and what users and developers need to know.
What happened in the eMudhra certificate incident?
On 17 October 2026, a security researcher reported that the private keys associated with eight eMudhra intermediate certificate authorities had been compromised. The keys had been generated with insufficient cryptographic randomness, making them recoverable.
A private key is a secret used in cryptographic operations. When a certificate authority’s private key is compromised, someone else may be able to misuse it to create certificates that appear to come from that authority.
The issue was not evidence that the P-384 cryptographic algorithm itself had been broken. Rather, the problem was with the generation of particular keys.
On 18 October, eMudhra revoked all eight affected intermediate certificates. In its public statement, the company said that none of the affected intermediates had issued end-entity certificates. It also said that only one of the eight had been deployed in production, that its infrastructure had not been compromised, and that no data had been breached. Those are the company’s reported findings; the investigation was still ongoing.
The incident concerned eMudhra’s global TLS certificate business, which supplies certificates used to secure website connections. India’s CERT-In advisory explicitly distinguished this incident from eMudhra’s regulated domestic digital-signature certificate and eSign services, which it said were unaffected. <Cite refs={[“turn914864search3″,”turn914864search4”]}/>
On 22 October, eMudhra also announced that it would voluntarily withdraw from the global SSL/TLS certificate business. The company described that decision in a separate announcement following the incident. <Cite refs={[“turn914864search9”]}/>
SECURITY INCIDENT · OCTOBER 2026
The eMudhra certificate incident
Four key developments. One important distinction.
Weak key generation
Eight intermediate CA keys were recoverable.
Certificates revoked
eMudhra revoked the affected certificates on 18 October.
Browser protections
Google and Mozilla blocked affected certificates.
Business exit announced
eMudhra announced its global SSL/TLS exit on 22 October.
Potential risk
Fraudulent certificates could be possible if compromised keys were misused and remained trusted.
What eMudhra reported
No end-entity certificates issued by the affected intermediates; no data breach identified in its statement.
Company-reported findings; the investigation was ongoing at the time of writing.
The key distinction is that the compromised keys created the possibility of fraudulent certificates being used against software that still trusted them. That risk was serious, but it is not the same as evidence that attackers used them to steal users’ information.
Sources: eMudhra’s incident statement, CERT-In’s advisory and eMudhra’s announcement about leaving the global SSL/TLS certificate business.
How could the flaw make a fake website appear genuine?
Imagine visiting your bank’s website. You want to be sure that you are communicating with your real bank, not an impostor.
HTTPS encrypts the connection between your device and a website. It also relies on digital certificates to help your browser verify the website’s identity.
A certificate authority (CA) is an organisation trusted to issue digital certificates. An intermediate CA sits between a trusted root certificate and the certificates issued to websites or services.
If someone obtains an intermediate CA’s compromised private key, they may be able to create fraudulent certificates that appear to identify legitimate websites.
For that fraud to affect a user, the relevant software would also need to accept the fraudulent certificate, and the attacker would generally need a way to intercept or redirect the connection. Under those conditions, the attacker could potentially impersonate a website and read or alter communications.
That is why certificate security matters: encryption alone is not enough if the software cannot reliably verify whom it is communicating with.
HOW CERTIFICATE TRUST WORKS
One trust chain. Two possible outcomes.
A compromised key matters only if the relevant trust checks can still be passed.
However, a possible attack is not a confirmed attack. The official statements available for this article do not establish that ordinary users’ passwords or personal information were stolen through this incident.
How Google and Mozilla responded
How browsers blocked the certificate risk
Two browser ecosystems. Different mechanisms to limit trust in affected certificates.
Chrome
Blocked public-key information linked to six affected TLS intermediate authorities.
Protection reached Chrome users without a browser update or restart.
Removal of emSign ECC Root CA – G3 was announced, with rollout expected on 27 October.
Firefox
Blocked affected certificates through Firefox’s centralised revocation list.
Standard Firefox configurations received protection in under three hours, without a restart.
Mozilla also updated its Network Security Services trusted certificate list.
17 October: Chrome blocked the affected TLS certificate keys
Google’s Chrome Root Program received the report on 17 October. After corroborating the findings, Chrome deployed a certificate blocklist update that blocked the public-key information associated with the six affected TLS intermediate authorities.
Google said this protection reached Chrome users without requiring a browser update or restart. <Cite refs={[“turn914864search0”]}/>
Google also reported that no TLS certificates chaining to those six affected intermediates had appeared in Certificate Transparency logs before its blocking action.
Certificate Transparency is a public logging system for website certificates. Google’s finding is important because it provides evidence about certificates visible in those logs. It should not be stretched into a claim that every possible form of misuse across every application or device was ruled out.
Google also announced that it would remove the emSign ECC Root CA – G3 from the Chrome Root Store. This broader measure was intended to protect users of software that relies on that root store but does not receive Chrome’s certificate blocklist updates.
In its 20 October announcement, Google said the wider change was expected to roll out on 27 October 2026, Pacific Daylight Time. Removing trust in a root can also affect legitimate websites that still rely on it. Google advised affected website operators to move to replacement certificates issued under another trusted certificate hierarchy. <Cite refs={[“turn914864search0”]}/>
Source: Google’s official security announcement.
17–21 October: Firefox added protection
Mozilla received its report on 17 October and blocked the affected certificates in Firefox through OneCRL, its centralised list of revoked certificates.
Mozilla said the update reached Firefox users with standard configurations in less than three hours, without requiring them to download a new browser version or restart Firefox. It also released software updates for users whose custom settings might have prevented them from receiving the automatic protection. <Cite refs={[“turn914864search1”]}/>
Mozilla also updated its Network Security Services (NSS) trusted certificate list. This matters because other applications may use Mozilla’s trust store, or a version derived from it, without receiving Firefox’s separate OneCRL updates.
The distinction is important: the browser’s emergency blocklist and an update to a shared trust store are different mechanisms. A fix in one place does not automatically mean that every application on a device has received the same protection.
Source: Mozilla’s official security announcement.
Why a browser update may not protect every app
Some applications use the certificate store provided by an operating system. Others bundle certificate information or their own certificate-validation components inside the application.
An app that uses its own certificate bundle may not automatically receive the same blocklist update as a browser. It may need a separate update from its developer.
Google’s Firebase team published remediation guidance for specific products affected by this issue. The list included Flutter apps, certain Apple-platform apps using Cloud Firestore, some Unity and C++ apps using Cloud Firestore, and the Firebase App Distribution Gradle plugin. Google provided product-specific fixes and instructions for developers. <Cite refs={[“turn914864search5”]}/>
Google also clarified that the Cloud Firestore backend itself was not affected. The remediation concerned specified client-side software and its certificate validation—not a compromise of the Cloud Firestore service itself. <Cite refs={[“turn914864search5”]}/>
This does not mean that every app built with Flutter, or every app on an iPhone, is vulnerable. Whether a fix is needed depends on the product, SDK, version and configuration.
For everyday users, the takeaway is straightforward: updating your browser does not guarantee that every separately installed app has received the same certificate protection.
Source: Google Firebase’s official remediation guide.
What did authorities and other platform providers say?
On 21 October, CERT-In published an advisory explaining that the incident affected eMudhra’s global TLS certificate business, not its regulated Indian digital-signature certificate and eSign services. It also described the weakness in the affected keys and the steps taken by browser and trust-store operators. <Cite refs={[“turn914864search4”]}/>
On 23 October, NHS England Digital issued a medium-severity advisory. It reported that six affected intermediate certificates were used for TLS, while the remaining two were associated with code-signing. It also said that browser and platform vendors, including Chrome, Mozilla, Apple and Microsoft, had taken steps to block the compromised certificates. <Cite refs={[“turn914864search2”]}/>
The distinction between TLS and code-signing matters. TLS certificates help software verify a website or server. Code-signing certificates help verify the publisher associated with software. The risks and technical protections are therefore not identical.
The NHS advisory warned that some software, firmware and devices could still need attention if they had not removed trust in the affected certificates. This is especially relevant to products that do not receive trust-store updates in the same way as mainstream browsers.
Sources: CERT-In’s advisory and NHS England Digital’s advisory.
What should users do now?
The official responses reduced the risk for users of the products covered by the relevant protections. The best next step is to keep software updated and respond carefully to security warnings—not to assume that your device has been compromised.
If you use Chrome or Firefox
Keep your browser updated. Google and Mozilla reported that their emergency certificate protections did not require most users to install a new browser version or restart it. Regular updates are still important, particularly for users with automatic updates disabled.
If you use an Android phone
Google said Android received an equivalent certificate protection through Google Play Services and that most devices had received it by the time of its 20 October announcement. Google also said restarting a device could trigger an update.
Keep Android, Google Play Services and your apps updated. A restart is a reasonable precaution based on Google’s guidance, but it is not evidence that your phone was compromised.
If you use an iPhone, iPad or Mac
Apple was among the platform providers identified in the public advisories as having taken action against the affected certificates. Keep your device and apps updated, and follow official Apple or app-developer guidance if a specific update is required.
Do not manually remove trusted certificates or change advanced security settings unless an official instruction tells you to do so.
If a website or app displays a certificate warning
Do not dismiss the warning simply to make the service work.
Check that your device’s date and time are correct, install available official updates, and contact the service through its official support channel if the warning persists. A failed connection does not automatically mean an attacker is present; it can also occur when a legitimate certificate has been revoked or a service needs to update its certificate configuration.
If an unexplained warning appears while you are using a banking, work or other sensitive service, avoid entering sensitive information until the problem has been resolved.
Do you need to change your passwords?
Not solely because this incident occurred.
The official statements available for this article do not establish widespread password theft or a confirmed data breach resulting from the incident. eMudhra said no data had been breached, while Google reported that no TLS certificates chaining to the six affected TLS intermediates had appeared in Certificate Transparency logs before its blocking action. These findings reduce the grounds for assuming widespread misuse, but they do not prove that every possible attack scenario was impossible. <Cite refs={[“turn914864search0″,”turn914864search3”]}/>
If you notice unfamiliar sign-ins, unexpected password-reset messages or transactions you did not authorise, secure the affected account and contact the service through its official channels. Otherwise, focus on keeping your software updated, taking certificate warnings seriously and following relevant vendor guidance.
What this incident reveals about online security
The eMudhra incident shows that protecting an online connection involves more than encrypting data. Software must also verify that it is communicating with the right website or service.
A weakness in the generation of particular certificate keys can undermine that trust even when the underlying cryptographic algorithm has not been broken. At the same time, the compromise of some intermediate certificate authorities does not mean every website using HTTPS has been hacked.
The response also highlights a less visible challenge: browser protections, operating-system updates and app-specific fixes are not interchangeable. Some applications may continue to rely on outdated certificate information until their developers provide an appropriate update.
For users, the advice is simple: keep your software updated, do not bypass unexplained certificate warnings, and follow official guidance if an app requires attention. There is no reason to assume that your personal information has been stolen without evidence.
For developers and organisations, the priority is to identify which certificate stores their systems use, check whether the affected certificates are still trusted, and apply the relevant vendor fixes.
Online trust depends on the whole system working together not just the padlock displayed in a browser.
TRANSPARENCY & VERIFICATION
Official sources
Primary advisories and statements used to inform this report.
- 01 Google Security Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
- 02 Mozilla Security Blog Protecting Firefox users following the compromise of eMudhra intermediate certificates
- 03 NHS England Digital eMudhra intermediate certificates compromised
- 04 CERT-In Compromise of eMudhra intermediate CA certificates
- 05 Google Firebase Updates required to remediate the eMudhra certificate compromise
- 06 eMudhra Statement on the certificate security incident
- 07 eMudhra · Press release Announcement about withdrawing from the global SSL/TLS certificate business
Community discussion
Join the conversation
0 comments
Be the first to join in
There are no comments yet. Sign in to start a thoughtful discussion.
Sign in to comment
Join the conversation with your Secritic account. Comments are available to signed-in readers.