When the keys that establish trust on the internet are weak, even HTTPS can no longer guarantee that a website is who it claims to be.
Digital certificates are a fundamental part of internet security. They help browsers verify website identities and establish encrypted connections, protecting users as they access banking services, business applications, government portals, and other online platforms.
A recently disclosed incident involving Indian digital trust provider eMudhra has raised serious concerns about the security of this infrastructure. Major browser and technology vendors have moved to block affected intermediate Certificate Authority (CA) certificates after researchers determined that their private keys could be recovered because of weaknesses in the key-generation process.
The incident is an important reminder that cybersecurity depends not only on strong encryption algorithms, but also on how cryptographic keys are generated, managed, validated, and retired.
What Happened in the eMudhra Certificate Incident?
On October 17, 2026, a security researcher reported that the private keys associated with eight eMudhra intermediate CA certificates had been compromised. The certificates originated from a key-generation process conducted in April 2025.
According to disclosures from browser vendors and eMudhra, a flaw in the key-generation workflow resulted in a second set of weak cryptographic keys being created alongside the intended stronger keys. The weak keys were mistakenly used in the affected certificate requests.
The problem was not that the underlying cryptographic algorithm had been broken. Instead, the keys were generated with insufficient randomness, making their private values recoverable from the corresponding public information.
The consequences were significant:
- Eight intermediate CA certificates were affected. Their associated private keys could be recovered, undermining the trust placed in those certificates.
- Fraudulent certificates could potentially be created. An attacker with a compromised CA private key could attempt to issue certificates impersonating other websites or services.
- Major technology providers took action. Google, Mozilla, Apple, and Microsoft moved to block affected certificates or otherwise reduce trust in the compromised certificate hierarchy.
- Some systems may still need remediation. Applications, servers, devices, and other software that rely on separate or outdated trust stores may not receive the same protections automatically.
Google also announced plans to remove the emSign ECC Root CA – G3 certificate from the Chrome Root Store, with the change expected to roll out beginning October 27, 2026, potentially affecting legitimate websites that still rely on that trust hierarchy.
eMudhra has stated that the incident is limited to the affected intermediate certificates and does not involve compromise of its root CA private keys or other intermediate CAs. The company has also reported that the affected intermediates did not issue end-entity certificates, based on its analysis and publicly available Certificate Transparency records.
These findings are important context. The weakness created a serious potential for certificate forgery, but the available disclosures do not establish that fraudulent website certificates were successfully used in real-world attacks.
Why Intermediate Certificate Authorities Matter
To understand the severity of this incident, it helps to understand how digital certificate trust works.
When a user visits a website over HTTPS, the browser checks its TLS certificate and verifies whether it can establish a valid chain of trust to a trusted root Certificate Authority.
That chain typically includes:
- Root CA: The highest-level trust anchor maintained in a browser or operating system trust store.
- Intermediate CA: A certificate authority authorized to issue or sign certificates beneath the root.
- Website certificate: The certificate presented by a website to establish its identity and support a secure connection.
Intermediate CAs play a critical role because they allow certificate issuance to be managed without using the root CA’s private key for every operation.
However, if an intermediate CA’s private key is compromised, an attacker may be able to create fraudulent certificates that appear trustworthy to clients that continue to trust the affected CA.
This can create opportunities for website impersonation, phishing, and interception of encrypted communications under suitable conditions.
HTTPS is only as trustworthy as the certificate validation and trust infrastructure behind it.
The Core Failure: Weak Cryptographic Key Generation
Modern cryptographic algorithms depend on appropriately generated keys. A strong algorithm cannot protect a system when the secret key is predictable or can be recovered easily.
In this case, the issue reportedly originated during the key-generation ceremony, when a workflow flaw produced unintended weak keys alongside the intended keys. Similar labels between the two key sets contributed to the wrong keys being used.
This highlights several important security lessons.
1. Strong Algorithms Cannot Compensate for Weak Keys
Cryptographic security depends on both the algorithm and the quality of the secret material used by it.
Keys must be generated using reliable sources of randomness and validated before they are used in production. If private key values are predictable, the mathematical strength of the underlying algorithm becomes irrelevant.
2. Human and Process Errors Can Undermine Technical Controls
Hardware Security Modules, formal procedures, and independent audits are important safeguards. However, they do not automatically eliminate the risk of workflow errors, incorrect configuration, flawed scripts, or mistakes during key selection.
Security-critical processes need independent verification rather than relying solely on the assumption that approved tools and procedures have been followed correctly.
3. Certificate Issuance Requires Strong Lifecycle Controls
Organizations that operate public key infrastructure must validate the entire lifecycle of cryptographic material, including generation, approval, deployment, monitoring, rotation, revocation, and destruction.
Automated validation and independent checks can help prevent unintended keys from entering trusted certificate chains.
What Are the Risks for Organizations?
The incident has implications beyond browsers. Certificate trust is embedded across a wide range of technologies, including operating systems, APIs, enterprise applications, mobile devices, servers, and connected infrastructure.
Website Impersonation and Phishing
If a vulnerable client continues trusting a compromised CA, an attacker could potentially present a fraudulent certificate for a legitimate domain. Depending on the environment and attack conditions, this could support impersonation or interception attempts.
Enterprise Systems That Miss Trust Updates
Updating a browser does not necessarily update every application or device in an organization. Some software uses independent certificate stores or embedded trust configurations.
Organizations should therefore identify systems that may continue trusting affected certificates and verify that appropriate security updates and trust-store changes have been applied.
Business Continuity and Certificate Replacement
Organizations using affected certificate hierarchies may need to replace certificates and validate their trust chains. Failure to prepare could result in legitimate websites or applications becoming inaccessible when browser vendors remove trust in the relevant root.
Regulatory and Governance Implications
Weak cryptographic controls can raise questions about security governance, risk management, supplier oversight, and compliance with applicable security requirements.
Organizations should assess the incident against their contractual and regulatory obligations rather than assuming that a certificate-related issue is outside the scope of their broader security program.
What Organizations Should Do Now
Security teams should take a structured approach to reduce exposure and prevent similar failures.
1. Inventory certificates and trust dependencies
Identify public-facing TLS certificates, intermediate CAs, root certificates, application trust stores, and external dependencies. Determine whether any services rely on the affected eMudhra certificate hierarchy.
2. Replace affected certificates where required
Website and application owners should follow official vendor guidance and replace affected certificates with valid certificates issued through an unaffected, trusted hierarchy. Confirm that the replacement certificate chain is correctly configured.
3. Update browsers, operating systems, and applications
Apply relevant vendor security updates and verify that affected certificates are no longer trusted. Pay particular attention to systems that do not automatically receive browser trust-store updates.
4. Review cryptographic key-generation procedures
Use approved cryptographic libraries and secure key-generation mechanisms. Validate generated keys before use and ensure that cryptographic parameters meet current security requirements.
5. Introduce independent verification
Separate key generation, approval, and deployment responsibilities where appropriate. Automated checks, independent review, and maker-checker controls can help detect incorrect key selection and workflow errors before certificates are published.
6. Strengthen certificate lifecycle management
Maintain a complete inventory of certificates, ownership, expiration dates, issuing authorities, and dependencies. Establish procedures for certificate rotation, revocation, replacement, and emergency response.
7. Test incident response readiness
Exercise scenarios involving compromised certificates, untrusted root authorities, and emergency certificate replacement. Include security, IT operations, application owners, legal, compliance, and business continuity teams.
8. Review third-party cryptographic dependencies
Organizations should understand how certificate authorities, cloud platforms, service providers, and software vendors manage cryptographic keys. Vendor assessments should examine the effectiveness of controls, not just the existence of certifications or audit reports.
Industries That Should Pay Attention
This incident offers lessons for every industry that depends on secure digital communications.
- Financial services: Banks, payment providers, and insurers should verify certificate trust across customer portals, APIs, mobile applications, and transaction systems.
- Healthcare: Hospitals and healthcare technology providers should assess certificates used by patient portals, connected medical services, and systems that exchange sensitive information.
- Retail and e-commerce: Online retailers should validate website certificates, payment integrations, APIs, and external services that support customer transactions.
- Manufacturing: Industrial organizations should review certificate dependencies in enterprise systems, connected devices, remote access services, and operational technology where applicable.
- Government: Public sector organizations should assess certificates used by citizen portals, identity systems, administrative platforms, and critical digital services.
- Technology and SaaS: Software providers should evaluate their certificate inventories, deployment pipelines, trust stores, and dependencies across customer-facing services.
Conclusion
The eMudhra incident demonstrates how a weakness in a fundamental security process can undermine trust across a much wider digital ecosystem.
The central lesson is that secure cryptography requires more than selecting a strong algorithm. It depends on reliable key generation, independent verification, disciplined certificate lifecycle management, and effective coordination between certificate authorities, software vendors, and organizations that rely on their services.
Browser-level blocking is an important defensive measure, but organizations must also consider applications, devices, servers, and other systems that may maintain separate trust stores.
For security leaders, this is an opportunity to review certificate dependencies, validate cryptographic controls, improve supplier oversight, and ensure that incident response plans account for trust infrastructure failures.
Digital trust must be continuously verified, not simply assumed.
About COE Security
COE Security partners with organizations in financial services, healthcare, retail, manufacturing, and government to secure AI-powered systems and ensure compliance.
Our offerings include:
- AI-enhanced threat detection and real-time monitoring
- Data governance aligned with GDPR, HIPAA, and PCI DSS
- Secure model validation to guard against adversarial attacks
- Customized training to embed AI security best practices
- Penetration Testing (Mobile, Web, AI, Product, IoT, Network & Cloud)
- Secure Software Development Consulting (SSDLC)
- Customized CyberSecurity Services
In addition, COE Security helps organizations strengthen their security posture through vulnerability assessments, penetration testing, network and cloud security reviews, application security assessments, secure development consulting, and compliance-focused cybersecurity services.
For organizations that rely on certificates and cryptographic trust, we can help assess the security of applications, APIs, infrastructure, and connected systems, identify weaknesses, review security configurations, and support risk-based remediation planning.
We also help organizations evaluate third-party security risks, improve security governance, and embed security practices throughout the software development lifecycle.
Follow COE Security on LinkedIn for ongoing insights into cybersecurity threats, digital trust, secure technology adoption, and compliance. Stay informed, strengthen your security posture, and stay cyber safe.
Click to read our LinkedIn feature article