Skip to main content
eMudhra revoked its own website's certificate and kept serving it
Opinion Oct 23, 2026

eMudhra revoked its own website's certificate and kept serving it

Tls Security Certificate-management

eMudhra is an Indian certificate authority, one of the companies browsers trust to vouch for websites, and it sells TLS certificates under the emSign brand. On October 22, it announced that it is leaving the global SSL/TLS certificate business. The decision follows a week in which eight of its intermediate CA keys turned out to be so weak that outsiders recovered them, and every major browser blocked those intermediates within days.

This article is about something smaller, and we want to be precise about it, because the key compromise is what everyone has in mind right now. The certificate on eMudhra’s own website, emsign.com, was not issued by one of the compromised intermediates. Nothing suggests its key is weak or exposed, and visitors to the site are not at risk.

What happened is an operational mistake. On October 19, eMudhra revoked that certificate because it had been replaced, but the replacement was never installed on the server. Four days later, the site still serves the revoked certificate. A CA’s own homepage now presents a certificate that the CA’s own revocation services report as revoked.

Revoked on October 19, still served

echo | openssl s_client -connect emsign.com:443 -servername emsign.com 2>/dev/null > emsign.txt
curl -s -A "Mozilla/5.0" http://repository.emsign.com/certs/emSignSSLCAG1.crt \
  | openssl x509 -inform DER -out emsign-issuer.pem
openssl ocsp -issuer emsign-issuer.pem -cert emsign.txt \
  -url http://ocsp.emSign.com -VAfile emsign-issuer.pem 2>/dev/null

Terminal output: eMudhra's OCSP responder reports the certificate as revoked, reason superseded, revocation time October 19 2026 13:47:40 GMT.

eMudhra revoked this certificate on October 19, 2026 at 13:47 UTC. The reason, superseded, means it was replaced by a new certificate. But the new certificate never made it onto the server, so on October 23 emsign.com is still sending the revoked one. It chains to emSign SSL CA - G1, outside the compromised G3B and G3C intermediates.

Chrome and Safari still show the padlock

Open emsign.com in Chrome or Safari and the padlock looks normal. Browsers don’t ask the CA about each certificate. Apple and Chrome push their own revocation lists to devices, and those lists carry revoked CA certificates, which is how the eight eMudhra intermediates were blocked within days. Routine revocations of website certificates, like this one, mostly stay off those lists. Firefox is the exception. Its CRLite list includes revoked website certificates too, so Firefox refuses to open emsign.com.

Firefox blocks emsign.com with a full-page warning. The Advanced section says the certificate has been revoked and isn't trusted anymore, with error code SEC_ERROR_REVOKED_CERTIFICATE.

That is how a revoked certificate can sit on a CA’s homepage for days while many visitors see nothing wrong. SSLBoard does ask: it checks every certificate and intermediate it finds with the CA that issued it, and flags the revoked ones.

What an SSLBoard scan shows

We scanned both of eMudhra’s domains on October 23. The reports are open, so you can see what an SSLBoard report looks like: emsign.com scored 28/100 and emudhra.com scored 57/100.

SSLBoard fix list for emsign.com: the critical finding "Revoked certificate served" lists 12 endpoints, including emsign.com and www.emsign.com, alongside eMudhra's revoked-certificate test pages.

Part of the emsign.com report is expected for a CA. Browser root programs require every CA to host test pages with a valid, a revoked and an expired certificate, so software vendors can check that their clients reject the bad ones. Hostnames like testevg1r.emsign.com (revoked) and testovg1e.emsign.com (expired) are those pages, and they are doing their job.

Set them aside and the reports still show:

  • emsign.com and www.emsign.com serve the certificate revoked on October 19.
  • qa.emudhra.com also serves a certificate revoked on October 19 as superseded. Their QA environment faithfully reproduced the production bug, ten minutes ahead of schedule.
  • mail.emsign.com, the only mail server for emsign.com, does not offer STARTTLS, so mail to eMudhra’s certificate business arrives unencrypted. It does offer password login on that unencrypted connection.
  • empmonitor.emudhra.com and online.emudhra.com still accept TLS 1.0 and TLS 1.1.

The full emsign.com report costs $20. That is what it would have cost eMudhra to find its revoked homepage certificate before we did.

eMudhra won’t be missed

A certificate authority sells one thing: the promise that it handles keys, issuance and revocation with more discipline than anyone else on the internet. eMudhra’s public record over the past eighteen months shows it cannot keep that promise.

  • May 29, 2025. eMudhra published CRLs for six of its G3B and G3C intermediates with signatures nobody could verify. Rob Stradling spotted them on crt.sh, and eMudhra said the CRLs had been signed with the wrong key. Correct CRLs went out eight days later.
  • October 14, 2026. eMudhra published a CRL for its emSign Root TLS CA - G1 root whose signature did not verify against the root’s key. Zihao Wang found it appears to have been signed with an OCSP signing key instead.
  • October 17, 2026. A researcher known as Wayne reported to the browser root programs that the private keys of eight eMudhra intermediates were compromised, and proved it by signing the message “We have a problem here - Wayne” with each one. Mozilla’s Dennis Jackson, who published the advisory, found the keys were integers smaller than 256, so anyone who looked could recover them. eMudhra traced them to its April 2025 key ceremony, and said the May 2025 CRLs had been re-signed with these weak keys.
  • October 19, 2026. eMudhra revoked the certificate on its own website, emsign.com, without installing the replacement. The site still serves the revoked certificate, as shown above.

Mozilla responded to the key compromise by requesting the emergency removal of the emSign ECC Root CA - G3 root, and Chrome committed to the same path. Three of these four incidents are failures of routine work: signing a CRL with the right key, twice, and keeping a CA’s own website on a valid certificate. That is the everyday work a CA is supposed to be best at, and the last one happened while the whole industry was watching.

If you use eMudhra certificates

eMudhra estimated in the incident thread that around 30,000 certificates need to be migrated away from the affected hierarchy. If some of them are yours:

  1. Find every endpoint that chains to an emSign CA, including load balancers, API gateways, mail servers and anything behind a CDN. An SSLBoard scan of your domain finds your hostnames in Certificate Transparency logs, connects to each one and lists the issuers it sees, so every emSign certificate shows up with the hostnames and IP addresses serving it.
  2. Replace those certificates with ones from another CA, preferably one you can automate with ACME so the next migration does not depend on anyone remembering.
  3. Remove eMudhra from your CAA records so nobody can get a new emSign certificate for your domains. The SSLBoard report shows the CAA policy in force for each name.
  4. Put the new certificate in service before you revoke the old one, then scan again. The report shows the certificate each hostname and IP address actually presents, including the server that never picked up the replacement.
  5. Check revocation status with the CA rather than trusting the padlock. SSLBoard checks the status of every certificate and intermediate it finds and flags a revoked one as a fix, with the hostnames still serving it. emsign.com would show up there today.

Scan your domain and see what your servers actually present.

Sources