Indian government sites serve revoked eMudhra certificates after mass revocation

A significant certificate authority incident involving eMudhra has left hundreds of Indian government websites serving revoked digital certificates. The issue emerged in mid-October 2026 when private keys for several intermediate certificate authorities were compromised, leading to the distrust of the emSign ECC Root CA - G3 by major browsers like Chrome and Mozilla.

What happened

On October 17, 2026, security researchers discovered that eight eMudhra intermediate certificate authorities chaining to the emSign ECC Root CA - G3 had private keys that were trivially recoverable. These keys were revoked the following day. In response, Mozilla and Chrome moved to distrust the entire G3 root. Separately, on October 19, eMudhra revoked 9,356 certificates on its unaffected RSA hierarchy, known as emSign Root CA - G1. The stated reason for this bulk revocation was "Superseded," affecting every unexpired certificate that lacked a specific certificate-type policy OID required by eMudhra’s own certification practice statement.

The Ministry of Electronics and Information Technology (MeitY) attempted to downplay the severity of the incident on October 21. A social media post from the ministry claimed the impact on Indian websites was very limited and short-lived. This assessment contradicts technical evidence showing the flawed keys existed since April 2025, allowing potential recovery for eighteen months. Furthermore, the revocation event has caused widespread disruption, with eMudhra estimating that 30,000 certificates from unaffected intermediates require migration, many belonging to US universities rather than Indian entities.

Despite the official reassurance, Indian government sites are still serving revoked certificates days after the event. Four bodies under MeitY itself, including the Controller of Certifying Authorities which regulates eMudhra, are among those affected. An updated scan on October 24 identified 1,377 Indian government domain names on revoked certificates, with 811 still actively serving them. Notable services impacted include visa processing, immigration portals, citizen service platforms like ICEGATE, and educational resources.

Key details

• Eight eMudhra intermediate CAs had recoverable private keys generated in April 2025, leading to their revocation on October 18, 2026.
• On October 19, 2026, eMudhra revoked 9,356 certificates on its RSA hierarchy for missing policy OIDs, affecting 2,976 government domain names.
• As of October 24, 2026, 811 Indian government domains were still serving revoked certificates, including critical services like indianvisaonline.gov.in.
• Browser behavior varies significantly: Firefox blocks these sites via CRLite, while Chrome, Edge, and Safari often allow access due to incomplete revocation lists.
• SSL Labs assigns a Grade F to these sites, marking them as revoked, yet they remain accessible to many users depending on their client software.
• The Controller of Certifying Authorities, the regulator for eMudhra in India, is itself serving a revoked eMudhra certificate on its PKI site.

Background

Transport Layer Security (TLS) certificates verify the identity of websites and encrypt data in transit. Certificate Authorities (CAs) like eMudhra issue these certificates. When a CA discovers a security breach or configuration error, it must revoke the affected certificates. Revocation informs browsers that a previously trusted certificate is no longer valid. Browsers check revocation status using mechanisms like Certificate Revocation Lists (CRLs), Online Certificate Status Protocol (OCSP), or compact sets like CRLite and CRLSet.

In this case, the inconsistency arises because different browsers use different methods to check for revocation. Firefox uses CRLite, which covers all revocations and blocks access immediately. Chrome uses CRLSet, which had not included these specific certificates as of late October, allowing connections to proceed. This fragmentation means some users see errors while others do not, creating a false sense of security for those whose browsers fail to enforce the revocation.

Why it matters

For teams running self-hosted software or managing internal infrastructure, this incident highlights the fragility of relying solely on external certificate authorities without independent monitoring. If a major CA fails to notify subscribers or if browser enforcement is inconsistent, your services may appear functional to some users while being flagged as insecure by others. This can lead to data exposure risks, loss of user trust, and compliance violations, especially for organizations handling sensitive citizen or customer data.

The delay in replacing revoked certificates also demonstrates operational gaps. Even when revocations are issued, migrating thousands of certificates takes time and coordination. Without automated alerts and visibility into certificate status, IT teams may remain unaware that their services are degraded until users report issues. For government and enterprise entities, this lag can disrupt critical services like visa applications or tax filings, causing real-world harm.

Furthermore, the regulatory irony of the controller itself serving a revoked certificate underscores the need for rigorous internal audits. Compliance is not just about obtaining a certificate but maintaining its validity throughout its lifecycle. Teams must assume that external notifications may be delayed or incomplete, making proactive monitoring essential for maintaining uptime and security posture.

What you can do

• Implement automated TLS certificate monitoring that checks for revocation status independently of browser behavior, using tools that query CRLs and OCSP responders directly.
• Set up alerts for certificate expiry and revocation events to ensure your team is notified before users encounter connection errors.
• Regularly audit your certificate inventory to identify any certificates issued by CAs undergoing security incidents or root distrust events.
• Test your services across multiple browsers and devices to understand how different revocation checking mechanisms affect user access.
• Maintain a contingency plan for rapid certificate replacement, including pre-configured automation for deploying new certificates from alternative CAs if needed.
• Review your certification practice statements and ensure your certificates include all required policy OIDs to avoid bulk revocations due to compliance errors.