BT BIG STORY: What happens when the keys to internet security are no longer secret

On a daily basis, we often interact with banks, shopping, and news websites, while also providing our personal information. But how do you know they are secure? Well, most of the time we rely on a “digital certificate” system that helps verify that the site is genuine. However, a security incident involving Indian digital trust company eMudhra exposed a weakness in this process after the private keys associated with eight intermediate certificate authorities (CAs) were found to be recoverable.

These digital certificates work as credentials that help establish which websites can be trusted. The certificates also come with a private key, which plays a crucial role. When this key goes into the wrong hands, they could potentially create fake certificates to impersonate legitimate websites. However, this does not mean that users' data or accounts are compromised.

Well, the incident prompted responses from Google, Mozilla, Apple, Cloudflare, and India's cybersecurity agency CERT-In. Although browser makers have blocked the affected website certificates, the episode has also raised concerns about server-side applications that maintain their own certificate trust stores and may not receive the same security updates.

Must read: From compromised certificates to malicious software: Inside October’s cybersecurity alerts

This has raised a key question: could websites and businesses that have not updated their security systems still trust a compromised certificate? Well, it solely depends on how they verify website identities and whether their systems continue to trust the affected certificates.

What happened to eMudhra's eight certificates?

On October 17, 2026, Google's Chrome Root Program received a report from a security researcher about compromised private keys linked to eight eMudhra intermediate CA certificates. Mozilla received a report the same day. Browser makers subsequently confirmed the findings and moved to block the affected website certificates.

According to Google's security disclosure, the private keys had been generated with insufficient cryptographic randomness, making them recoverable from their corresponding public certificates.

The eight affected certificates comprised six intermediate CAs used for Transport Layer Security (TLS), which helps secure website connections, and two used for code signing, which helps systems verify the publisher and integrity of software.

In a statement published on October 21, eMudhra said the affected intermediate CAs were created during a key-generation ceremony on April 30, 2025. A flaw in a key-wrapping and unwrapping step produced a second set of weak keys alongside the intended strong keys. The weak keys were the ones published to browser root stores.

The company said the incident was limited to the affected intermediate authorities and did not involve its root CA private keys or other intermediate CAs. It is investigating the root cause.

Must read: What are eMudhra certificates? What to know about the security scare and could your data be at risk?

In a response to Business Today, Rahul Sasi, co-founder and CEO of CloudSEK, said, “This is not your usual data breach where hackers break into a system. This is much more fundamental. The entire internet runs on trust, and encryption is a big part of that trust.”

“A private key is supposed to be almost impossible to guess. Imagine trying to find one needle in a universe full of haystacks. Now imagine a global Certificate Authority issuing private keys with numbers like 4 or 115. That's like building the world's most secure vault and setting the password to 0000.”

“The problem here is not that someone broke the security. The security itself was broken from the beginning,” he added.

How did weak cryptographic keys create a security risk?

Certificate authorities help browsers and applications verify the identities of websites and servers. An intermediate CA sits between a trusted root certificate and the certificates it issues, forming part of the chain that allows a client to trust a website.

Under normal circumstances, private keys are generated using cryptographically secure randomness. Recovering a properly generated private key from its public counterpart should be computationally infeasible.

In this incident, CERT-In said the affected P-384 elliptic-curve private keys had values smaller than 256. Researchers recovered the keys almost instantly because the values came from an extremely small set of possibilities.

The problem was not a weakness in the P-384 algorithm itself. Rather, the key-generation failure undermined the security the algorithm is designed to provide.

Atul Tripathi, a quantum security expert and former official at India's National Security Council Secretariat (NSCS), said: “This is a critical security failure like protecting a bank vault with a lock that has only 255 possible combinations. The secret keys were small numbers below 256, allowing an ordinary computer to discover them almost instantly.”

“It shows that the process for creating secure, unpredictable keys and the checks meant to catch failures was seriously inadequate,” he added.

Must read: eMudhra certificate alert: How to update Windows, macOS and Linux devices for better security

Anyone who recovered the private keys could potentially use them to sign fraudulent certificates for domains they did not control. An attacker could then attempt to impersonate a legitimate website or server. To intercept a victim's connection, however, the attacker would generally also need to redirect or intercept network traffic, and the relevant client would need to accept the fraudulent certificate.

The two compromised code-signing intermediates also created a potential risk of fraudulent software-signing certificates. Code-signing certificates help establish a software publisher's identity and whether signed code has been altered; they do not, by themselves, guarantee that software is safe.

Tripathi said: “If eMudhra’s claim is correct, the incident does not mean its entire certificate infrastructure was compromised. However, the eight intermediate authorities had their own power to issue certificates. Their exposed keys could therefore enable forged certificates that systems trusting those authorities might accept.”

What could this mean for websites and internet users?

The incident has raised concerns about the broader web public key infrastructure (WebPKI), which browsers and applications use to establish trust in website certificates.

If a client continues trusting a compromised CA and accepts a fraudulent certificate, an attacker positioned between the client and the intended server could potentially read or modify communications. This could put authentication credentials, API keys and information exchanged with online services at risk.

However, the possibility of an attack should not be confused with evidence that one occurred.

Google said no TLS certificates chaining to the six affected website intermediates had appeared in Certificate Transparency logs before Chrome blocked them. Certificate Transparency is a system for publicly recording and monitoring the issuance of trusted website certificates. Google added that no fraudulent certificates issued by those authorities could have been used against clients enforcing the relevant Certificate Transparency requirements, including Chrome’s default protections for publicly trusted certificates.

Must read: Critical PHP vulnerabilities: What is it, how it can affect websites & what should users know?

eMudhra also said none of the eight affected intermediate CAs had issued end-entity certificates, and only one had been deployed in production. Its October 21 statement says this was confirmed through the company's internal analysis and public Certificate Transparency records.

These findings limit what can be concluded about the incident’s impact. However, they do not establish whether the compromised keys were misused through other channels or whether an attack occurred outside activity visible in public certificate logs.

Why PHP applications could face a separate risk

One complication is that browsers and server-side applications do not necessarily use the same certificate-verification mechanisms.

Browsers can receive updates that block compromised certificates. PHP applications, meanwhile, may rely on certificate authority bundles maintained by the operating system, included in programming libraries or packaged directly with application code.

Cybersecurity firm Sansec has warned that PHP applications using affected certificate bundles could continue trusting certificate chains involving the compromised authorities until those bundles are updated or the relevant trust anchors are removed.

This matters because PHP applications frequently make HTTPS requests to external services. For example, an e-commerce website may connect to a payment gateway, shipping provider, or enterprise resource planning platform through an application programming interface (API).

If the application accepts a fraudulent certificate and an attacker can intercept the connection, the attacker could potentially access API credentials and customer information in requests or manipulate responses. For example, a forged response could falsely indicate that a payment had succeeded.

Tripathi stated, “Applications using outdated library-specific certificate stores or older containers are particularly exposed because browser or host-system updates may not reach them. Applications using operating-system certificate bundles also remain exposed until the relevant protections are installed. The key question is whether the certificate store each PHP application actually uses has been updated to reject the affected authorities.”

Exposure depends on the certificate bundle and verification path in use. Sansec has identified both system-level and application-specific bundles as areas developers should review. The incident does not mean PHP itself has been compromised or that every PHP-powered website is vulnerable.

What should developers and businesses do?

Developers should determine whether their applications trust the affected certificate authorities, then update the relevant certificate bundles and software dependencies.

This includes checking operating-system CA bundles, libraries that package their own certificates, application dependencies and deployed container images. After applying fixes, teams should test the application’s actual HTTPS verification path because a successful browser check does not prove that a background service is protected.

Don Smith, vice-president of threat intelligence at Sophos, told Business Today: “Security teams should prioritise internet-facing systems, confirming which versions are affected as soon as the official advisory is published, and apply the updates without delay. And in line with the advice from NCSC, any vulnerable system that cannot be patched should be isolated from the internet until it can be secured.”

Cloudflare also cautioned developers against resolving certificate errors by disabling certificate verification. Doing so removes an important security check rather than addressing the underlying problem.
Rajesh Chhabra, general manager for India and Asia at Acronis, told Business Today: “Organisations need to upgrade the bundles of CAs in the operating system, PHP dependencies, trust stores for the application and containers' images, and then re-deploy and test their applications. They should also examine legacy systems, integration with third parties and any infrastructure managed by vendors that may not have automated mechanisms for updating.”

For ordinary users, keeping browsers and operating systems updated is an important precaution. Users should also avoid bypassing certificate warnings to access a website or service.

Are eMudhra's digital signature services affected?

In its October 21 advisory, CERT-In distinguished between eMudhra’s international public-trust infrastructure for website and software certificates and its domestic Indian digital signature certificate (DSC) and eSign services, which are regulated by the Controller of Certifying Authorities under the Ministry of Electronics and Information Technology.

CERT-In said the domestic Indian DSC and eSign services were not affected by the incident. eMudhra has likewise said that its Indian digital signature and eSign businesses operate on separate infrastructure and that the incident did not involve its root CA private keys or other intermediate authorities. The company also stated that there was no infrastructure compromise or data breach.

The incident nevertheless highlights the importance of secure key generation, independent verification and effective certificate revocation. Even when a cryptographic algorithm is considered strong, a failure in generating its keys can undermine the trust that browsers, applications and businesses rely on to secure online communications.

“The incident highlights that revoking a certificate does not instantly make every system reject it. Protection depends on whether a system checks its revocation status or receives an update blocking it. Browsers may act quickly, while operating systems, libraries and server applications follow separate update schedules; some use certificate lists that require manual replacement,” Tripathi said. “This creates a dangerous gap in which the same certificate may be rejected by one system but accepted by another. Announcing revocation is only the first step; ensuring it takes effect everywhere is the harder task.”