Indian government sites are serving revoked eMudhra certificates

A digital certificate links a website’s name to a public key and an issuing certificate authority. When the authority revokes it, the certificate must no longer be accepted, even if its expiry date has not arrived. Revocation can reflect a compromised key, incorrect issuance, or another serious problem. Serving the certificate leaves visitors with a credential the issuer has explicitly withdrawn.

In this incident, eMudhra revoked certificates on 19 October with the reason “Superseded.” The article identified 2,976 government domain names on revoked certificates. Of those, 894 were still serving the revoked certificate, while 810 had moved to a new one. Firefox checked revocation data and refused to load them. SSL Labs marked them Grade F.

Browser behavior differs because revocation checking is not uniform. Chrome, Edge, and Android loaded these sites because their CRLSet lacked the relevant entries. Safari on iOS generally checked OCSP only for EV certificates. Operators need to install replacement certificates promptly, then verify that browsers can see the change.

The article gives two related counts because the investigation expanded. Its government-domain table listed every name on an unexpired certificate that eMudhra had revoked: 2,976 names. This was the broad table count, covering government domain names found on the revoked certificates.

Within that table, 894 domains were still serving the revoked certificate. Another 810 had moved to a new certificate, and the remaining domains did not respond. The certificates were revoked mainly within minutes of one another on 19 October and appeared in eMudhra CRLs, including DV/G2A-1, OV/G2A-1, EV/G2A-1, and G1.

The author later rescanned every name on eMudhra’s revoked certificates and rechecked sites that blocked foreign visitors from India. That produced a narrower reported count of 1,377 Indian government domain names, with 811 still serving revoked certificates. The figures describe different stages and scopes of the investigation, rather than necessarily a single unchanged total.

Certificate revocation is checked through browser-specific systems and policies. A browser may use a certificate revocation list, or CRL, containing revoked certificate identifiers. It may also ask an online OCSP responder about a particular certificate. If the browser lacks the relevant data or does not perform that check, it can continue loading a certificate that another browser rejects.

The article gives a sharp example. Firefox ships CRLite, which covered every revocation discussed and refused to load the affected sites. Chrome’s 24 October CRLSet had none of the certificates on the DV/G2A-1 CRL, so Chrome, Edge, and Android loaded them. Safari on iOS checked OCSP only for EV certificates, so it treated most differently.

This creates inconsistent user experiences and delays remediation. A site can appear broken in Firefox but normal in Chrome, even while serving the same revoked certificate. Operators cannot rely on one browser’s result; they must replace revoked certificates and confirm the new certificate is served correctly across browsers.

Mozilla and Chrome distrusted emSign ECC Root CA - G3 because eight eMudhra intermediate CAs chaining to it had trivially recoverable private keys. Those intermediates were revoked on 18 October. Their flawed keys had been generated in April 2025, leaving about 18 months during which they could have been recovered. Distrusting the root limits trust in the wider G3 chain.

The compromised intermediates barely issued certificates, but the root decision still affected many unrelated certificates. eMudhra estimated that 30,000 certificates from unaffected G3 intermediates would need migration. Most appeared to belong to US universities using eMudhra through InCommon, rather than Indian sites.

G1 was a separate RSA hierarchy, signed under emSign Root CA - G1, and was described as still trusted by browsers. It was not implicated in the recoverable-key problem. Separately, eMudhra revoked 9,356 unexpired G1 certificates because they lacked a certificate-type policy OID required by its own CP/CPS, using “Superseded” as the reason.

A website operator’s practical response is to obtain or issue a replacement certificate, configure the website to serve it, and verify that visitors receive the new certificate. The replacement should chain to a trusted authority and avoid the problem that caused the original revocation. Revocation alone does not change the certificate already installed on a server.

Browsers learn about the problem through revocation mechanisms. A CRL is a published list of revoked certificates, while OCSP lets a browser ask an issuer’s responder about an individual certificate. In the incident, eMudhra listed many revoked certificates in CRLs such as DV/G2A-1, OV/G2A-1, EV/G2A-1, and G1. Its OCSP responder reported the isea.gov.in certificate as revoked.

These mechanisms identify the old certificate as invalid; they do not announce or install a replacement. Browser coverage differs. Firefox used CRLite, while Chrome’s CRLSet lacked the affected DV/G2A-1 entries. Operators therefore need prompt certificate rotation and should test across browsers, not assume every browser sees the same revocation.

eMudhra is the certificate authority at the center of the incident. It operated the G3 and G1 hierarchies, revoked eight compromised intermediate CAs, distrusted or migrated certificates through its ecosystem, and revoked 9,356 G1 certificates marked “Superseded.” It also publishes CRLs and operates an OCSP responder that reports certificate status.

MeitY, India’s Ministry of Electronics and Information Technology, posted a public statement on 21 October saying the impact was limited and short. The article disputes both claims. The Controller of Certifying Authorities regulates eMudhra’s CA business in India, yet its own India PKI site was serving a revoked eMudhra certificate. STPI, Bhashini, and UIDAI were also named as MeitY-related bodies still affected.

Browsers are the final decision-makers for visitors. Mozilla and Chrome distrusted the G3 root. Firefox used CRLite and blocked covered certificates, while Chrome, Edge, Android, and usually iOS Safari accepted many sites because their checks lacked the relevant information or followed different policies.

Public-key infrastructure uses a chain of certificates. A website presents its own certificate and, usually, certificates linking it to an intermediate authority. The browser verifies the digital signatures through that chain until it reaches a root certificate already trusted in the browser. It also checks that the certificate names the website and remains within its validity period.

Revocation adds another condition. If the issuing authority publishes that a certificate or intermediate is revoked, a browser that receives or stores that information can reject the chain. In this incident, Firefox’s CRLite covered every revocation discussed. Chrome’s CRLSet did not contain the certificates on the DV/G2A-1 CRL, so Chrome, Edge, and Android loaded many of the same sites.

The root’s status matters too. Mozilla and Chrome moved to distrust emSign ECC Root CA - G3 after eight intermediates had recoverable private keys. The separate emSign Root CA - G1 remained trusted. Thus, certificate validity depends on the chain, identity, dates, revocation evidence, and browser trust store.