返回资讯中心
外部精选
软件工程
#开发者实时流

eMudhra served a revoked certificate for four days, then switched to Sectigo

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/…

Hacker News 最新weddpros2026/10/23 · 14 天前11 分钟阅读

以下正文同步自 Hacker News 最新,版权归原站所有,已转换为易读排版。

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.

Update, October 23: emsign.com now serves a certificate issued by Sectigo, valid from October 21. qa.emudhra.com still serves its revoked emSign certificate.

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

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.

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.

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.

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.

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:

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

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.

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.

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:

Scan your domain and see what your servers actually present.

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →