What if one of the keys behind internet security was so weak that its value was just “4”?
That sounds almost too ridiculous to be a cybersecurity story. Yet that is one of the details at the centre of the eMudhra certificate crisis that has now sent ripples across the global internet.
Eight intermediate Certificate Authorities linked to eMudhra’s global TLS business were found to have cryptographically weak private keys. The discovery prompted Google, Mozilla, Apple and Microsoft to block or distrust the affected certificate hierarchy. Days later, eMudhra announced that it would voluntarily exit the global SSL/TLS certificate business altogether.
Before the headlines make this sound like a giant internet hack, though, there is an important distinction.
There is no confirmed evidence of a widespread data breach or mass exploitation of these certificates. eMudhra says its infrastructure and customer data were not compromised, while CERT-In says the weakness created the possibility of fraudulent certificates and website impersonation.
So, what actually went wrong? Why did global browsers react so quickly? And does the incident affect Indian websites and eMudhra’s digital-signature services?
Here is the story without the cybersecurity jargon overload.
The short answer: eight intermediate Certificate Authorities in eMudhra’s global TLS business were created with dangerously weak cryptographic keys.
The affected CAs were created during a Key Generation Ceremony on April 30, 2025. eMudhra initially said a flaw in a wrap/unwrap process generated a second set of weak keys alongside the intended strong keys. In its latest update on October 26, the company clarified that a script error resulted in issuing CAs with weak keys.
These were not ordinary website certificates. They were intermediate CAs - part of the chain used to issue trusted digital certificates.
CERT-In found that the affected P-384 elliptic-curve private keys had values smaller than 256 and could be recovered almost instantly from their corresponding public keys. Importantly, CERT-In stressed that this was a key-generation failure, not a flaw in the P-384 cryptographic algorithm itself.
That difference matters.
The encryption system itself wasn't suddenly broken. The problem was that some of the keys generated to use it were extraordinarily weak.
For most people, a digital certificate is invisible.
You type a website address, see the padlock or HTTPS and move on.
Behind that simple experience sits a global system of trust involving Certificate Authorities, browsers, operating systems and cryptographic keys.
Website security certificates help browsers verify that a website is genuinely connected to the domain it claims to represent.
If an attacker obtains a sufficiently privileged CA private key, they could potentially create fraudulent certificates for domains they do not control. CERT-In warned that the compromised eMudhra intermediate CA keys could potentially be used to issue fraudulent certificates and impersonate legitimate websites, including in scenarios involving man-in-the-middle attacks.
That is why the incident triggered an immediate response.
The risk was not simply that one website might display a warning. A compromised CA can potentially undermine trust much further up the chain.
This is where the story gets genuinely bizarre.
The affected certificates were intended to use P-384 elliptic-curve cryptography - a modern cryptographic standard designed to make private-key guessing practically impossible.
Yet researchers were able to recover the private-key values because they were extraordinarily small.
CERT-In said the affected values were below 256. Reports around the incident highlighted one value as simply 4, with the other recovered values also being tiny.
Think of it this way: the lock itself wasn't defective. Someone had effectively left the key sitting on the table.
That is also why describing this as “P-384 encryption being cracked” would be incorrect.
The cryptographic algorithm wasn't broken. The key-generation process was.
And that is one of the biggest cybersecurity risks exposed by this incident.
The keys were generated in April 2025 and remained in browser trust systems until the problem was reported in October 2026.
Even more striking, eMudhra said the affected infrastructure had undergone independent audits for two consecutive years and had been included in browser trust lists since mid-2025.
An independent researcher reported the weakness on October 17, 2026. eMudhra then revoked the eight affected intermediate certificates the following day.
The episode raises an uncomfortable question for the wider cybersecurity industry: how do you make sure that a sophisticated security process hasn't been undermined by one simple software or operational error?
There is no evidence that the audits themselves caused the problem. But the incident does show that audits and compliance checks are not substitutes for continuous technical validation.
There is no confirmed evidence of widespread malicious exploitation.
This is perhaps the most important point for readers to understand.
eMudhra says its infrastructure was not compromised, no customer data was breached and the affected intermediate CAs had not issued publicly trusted end-entity certificates. The company revoked the eight intermediates within 14 hours of confirming the issue.
CERT-In nevertheless classified the incident as a compromise of intermediate CA certificates because the private keys could be recovered and potentially misused.
So there is a crucial difference between:
“These keys could have been abused”
and
“Hackers used these keys to attack millions of people.”
The first is supported by the available evidence. The second is not.
Once the weak keys became known, the global browser ecosystem moved quickly.
Mozilla blocked the affected TLS intermediates through Firefox's OneCRL system. Google blocked the affected public keys through Chrome's Certificate Revocation List Set. Mozilla also updated its trusted certificate list to remove the relevant root certificate.
Apple and Microsoft also moved to distrust the affected certificate hierarchy.
The speed mattered because browser and operating-system trust stores can effectively tell devices: “Do not trust this certificate anymore.”
That response helped limit the window in which the weak certificates could pose a risk.
However, older devices and systems that do not receive regular security or trust-store updates can be more difficult to protect. CERT-In therefore advised users and administrators to apply relevant security updates and keep systems current.
On October 22, eMudhra announced that its Board had decided to voluntarily withdraw from the global SSL/TLS certificate business.
The company says the business contributes only around 1% of its global revenue.
It also cited increasing data-sovereignty and compliance requirements, growing operational complexity and costs, and competition from providers offering SSL/TLS certificates free of charge. eMudhra added that the social-media amplification around the incident had created scrutiny it considered disproportionate to the size of the business.
But there is another factor that is difficult to ignore.
When your business is built around digital trust, reputation is part of the product.
The exit does not mean every certificate issued by eMudhra suddenly stops working.
The company says its G1 RSA roots will continue during the transition. It is also offering replacement certificates through partners at no additional cost to affected customers. Sectigo-issued certificates are available as an alternative, while revocation and certificate-status services will continue until issued certificates expire or are replaced.
For businesses using eMudhra TLS certificates, the sensible move is to check the affected certificate hierarchy and follow eMudhra's replacement guidance rather than panic.
For Indian users, this is probably the biggest question.
CERT-In says eMudhra's Indian Digital Signature Certificate and eSign services are not affected by this incident.
The global browser-trusted TLS business operates separately from eMudhra's Indian DSC and eSign infrastructure, with separate systems and cryptographic keys.
That means readers should not interpret this incident as evidence that Aadhaar, the Income Tax portal or other Indian government websites were hacked.
The incident is serious, but the available evidence does not support that conclusion.
The biggest takeaway for TheUnitedIndian audience isn't that modern encryption has failed.
It hasn't.
The lesson is that internet security is only as strong as the weakest part of the trust chain.
You can have advanced cryptography, hardware security modules, browser security teams and independent audits. But if a software or process error creates weak private keys, all those layers suddenly have a problem to solve.
The eMudhra incident also highlights another uncomfortable truth: cybersecurity risks aren't always about dramatic hacking scenes or sophisticated malware.
Sometimes the biggest problem begins with something much smaller.
A script.
A process.
A missed validation check.
Or, in this case, a cryptographic key whose value was reportedly4.
For ordinary internet users, there is no reason to panic based on the evidence available today. For businesses, however, the incident is a reminder to keep certificates, browsers, operating systems and trust stores updated - and to never assume that a security certificate is automatically safe simply because it carries the name of a trusted authority.
Because on the internet, trust is not just a feature. It is the foundation.
Everything you need to know
eMudhra announced its exit from the global SSL/TLS certificate business after eight intermediate CA certificates were found to have cryptographically weak private keys.
The incident involved weak private keys generated for eight intermediate Certificate Authorities. CERT-In said the keys could potentially be used to issue fraudulent certificates and impersonate legitimate websites.
There is no confirmed evidence of a widespread infrastructure breach or mass exploitation. eMudhra has said its infrastructure and customer data were not compromised.
According to CERT-In and eMudhra, the incident concerns the company's global browser-trusted TLS business. Its Indian DSC and eSign services are separate and were not affected.
Researchers found that some affected private-key values were extraordinarily small. CERT-In reported values below 256, making them recoverable with very little effort. One reported value was 4, highlighting the severity of the key-generation failure.
Oct 17, 2026
TUI Staff
Oct 17, 2026
TUI Staff
Oct 17, 2026
TUI Staff
Oct 12, 2026
TUI Staff
Oct 26, 2026
TUI Staff
Oct 26, 2026
TUI Staff
Oct 25, 2026
TUI Staff
Oct 23, 2026
TUI Staff
Comments (0)
Be the first to comment!