Eight eMudhra CA Keys Were Weak. Browsers Blocked Them. Other Clients May Not Have.

On October 17, 2026, at 18:05 UTC, the Chrome Root Program got a researcher report: the private keys for eight eMudhra subordinate CA certificates were generated with too little randomness. Anyone who recovers one of those keys can forge an HTTPS certificate that a still-trusting client will accept for any site.

Chrome corroborated the report and, at 19:45 UTC the same day, shipped a CRLSet that blocks the keys by their public-key hash. That block does not need a browser restart. The researcher’s write-up says Firefox and Chrome have blocked the certificates since October 17, Apple devices since October 19, and Microsoft platforms since October 20. The certificates were created in April 2025. The keys have been recoverable from the public certificates since then.

This is a CA key-generation failure, not a report that Google, Mozilla, Apple, or Microsoft were hacked. Google says no TLS certificates chaining to the affected intermediates were in Certificate Transparency logs before the block, so CT-enforcing browsers were not a path for a forged cert. Google’s post says eight subordinate certificates, then says no certificates chaining to six intermediates were in those logs. We are not smoothing those two counts into one.

Clients that do not check revocation or Certificate Transparency — curl, many language trust bundles, Docker base images — can still treat the intermediates as trusted until the bundle is updated.

Snapshot

Google is also removing emSign ECC Root CA - G3, the root that signed the weak intermediates, from the Chrome Root Store. That removal is expected Tuesday morning, October 27, 2026 PDT (sooner on Canary and Beta). Legitimate sites still chaining to that root will break in Chrome. Operators need a certificate from a different hierarchy in the Chrome Root Store before then. eMudhra has committed to moving those subscribers. Chrome is still deciding whether eMudhra’s other roots stay included.

eMudhra told Mozilla, in the root-program bug, that a key-wrapping test created a second, weak key pair and that operators used those keys because the labels looked alike. The CA has revoked the compromised intermediates. We are not publishing key values or a recovery method. The researcher’s page is the place for the signed proof; this post is the impact and the update.

What still trusts the keys

A browser that already took the block is not the client that worries us. A script, a container, or a language installer that ships its own CA bundle will keep trusting a forged certificate until that bundle changes.

The researcher published two hosts that present a certificate from the weak intermediates. A certificate error means your client does not trust them. A normal page means it still does.

Run the same URL with the curl or language you actually ship, not only with Chrome.

Ubuntu, Debian, Fedora, Alpine, Arch, and other ca-certificates builds are on the same page. Update the package. Hand-editing a trust store is how a machine ends up trusting the wrong root, or trusting nothing.

MFA on the accounts around this incident

A hardware key or authenticator app protects a login. It does not refresh a trust store, and it does not stop a client from accepting a certificate signed by a weak CA key.

eMudhra’s eSign login still offers SMS OTP. A customer how-to also shows Google Authenticator as an optional TOTP after username and PIN. SMS remaining keeps the grade at Fail. No public YubiKey enrollment.

emSigner documents email or SMS OTP, and it names Google Authenticator, Microsoft Authenticator, and emSigner’s own app. Email and SMS keep Fail. No public YubiKey.

Sectigo’s WebHost / Reseller / EPKI article names Google Authenticator, Microsoft Authenticator, and Authy for a TOTP QR. No SMS path in that article, and no YubiKey, so the account row is Pass. SAS adds an authenticator app and passkeys (platform managers and password managers). Sectigo’s YubiKey article is code-signing key storage on the token, not account login. A signing key on a YubiKey does not grade the portal Strong.

Google Account and Microsoft Account stay Strong (security key plus authenticator). Those keys do not install a CRLSet or a new ca-certificates package.

Directory: MFA support directory · Business Apps and Email & Identity.

Recommended MFA tools

We may earn a commission if you buy a YubiKey or sign up for Proton Pass through the links above.

Independent cybersecurity audits

We audited the CA, the cross-signing CA, two root-program hosts, the curl project, and the researcher’s check domain on October 21, 2026. 100% is the ideal — none reach it. These scores are public email / transport / website posture. They do not measure whether a trust store still contains the weak keys.

Audit links: mozilla.org · sectigo.com · curl.se · google.com · emudhra.com · we-have-a-problem.com

emudhra.com, sectigo.com, mozilla.org, and curl.se sit at 15% transport (MTA-STS / related). emudhra.com is Identity 50%. Type emudhra.com yourself if a mailer offers a “reissue your certificate” link.

Website stack

Passive homepage + Certificate Transparency probes (October 21, 2026). Versions only — not a claim these sites were compromised, and not a claim the website certificate is one of the eight weak intermediates.

The Sectigo-issued certificate on emudhra.com is the public website’s TLS certificate. It is a separate fact from the eight weak intermediate keys.

Blacklist and lookalikes

Email blacklist checks (public DoH, October 21, 2026): emudhra.com, sectigo.com, mozilla.org, google.com, and curl.se were clear on mail/domain lists we can query. curl.se and mozilla.org showed web/CDN SPFBL on some IPs — shared-edge noise, not led.

we-have-a-problem.com showed UCEPROTECT Level 3 on three OVH mail IPs. That is provider-netblock noise. It is not a reason to skip the HTTPS trust check, and it is not a finding that the researcher domain is a spam source we are leading with.

Registered lookalikes that matter if a “reissue” or “check your CA” mail turns into a fake portal:

emudhra.tech also has mail. Several curl.* names show mail because curl is a common word — that scan is not evidence those domains impersonate the curl project. curl.dev points at the project’s own mail. Type the real hosts. Continuous monitoring: Cybersquat Domain Monitoring.

CourtListener has ClearCircle LLC v. eMudhra Limited, E.D. Texas 2:26-cv-00294, filed April 13, 2026. The cause is patent infringement. It is not a docket about these CA keys. Searches did not turn up a case for the October disclosure.

Related coverage

• Chrome 154 security update
• Google Calendar invite phishing
• MFA support directory

Sources: Chrome Root Program, Oct 20, 2026 · Researcher summary, Oct 20, 2026 · Mozilla bug 2083449 · eMudhra eSign login · emSigner product security · Sectigo TOTP help · Sectigo SAS account security. Independent EmailMeNow audits, website-tech, blacklist, cybersquat, and CourtListener searches October 21, 2026. Domain scores: audit.emailmenow.com only.