Live monitoring Updated 72-hour alert levelPriority Editor: Frédéric LENQUETTE
CYBERIACKCybersecurity & AI intelligence · by Frédéric LENQUETTE
CybersecurityImportant

Over 100,000 fake google.com certificates were signed with eMudhra's keys

The Indian certificate authority's eight weak keys are now within anyone's reach. Browsers hold up, but your servers and scripts may not: here is what to check.

Translated from French by AI. The original French article is the reference version.

Article illustration : Over 100,000 fake google.com certificates were signed with eMudhra's keys
AI-generated illustration

The certificate bears the name google.com and a signature that verifies perfectly. Yet the certificate authority it claims to come from never issued it. On October 20 and 21, 107,107 certificates signed with six of eMudhra's eight compromised keys were logged in e-Szignó's transparency logs, public registries of website certificates. More than 106,000 carry only the name google.com. The count comes from researcher Jacob Durham, in the incident report opened by Mozilla.

These keys belong to eight intermediate certificates of the Indian authority eMudhra, so poorly generated that they could be guessed in 256 attempts. According to Google, they allow anyone to forge an HTTPS certificate for any website, against software that still trusts them. Jacob Durham calls them "proofs of concept."

Why your browser isn't fooled

Chrome blocked these intermediates on October 17, less than two hours after the report, and other browsers followed within three days. Above all, Chrome requires every certificate to appear in the transparency logs. According to Google, no certificate tied to these intermediates appeared there before they were blocked, so no fake could have fooled it.

The danger has shifted to servers and scripts

On October 25, eMudhra argued that its intermediates were revoked within 14 hours of confirmation. In its view, any software that checks revocation is therefore safe. Half an hour later, Jacob Durham replied that all but two of these fake certificates contain no revocation address. A client that checks revocation only for the final certificate, a common configuration in his view, therefore has nothing to check.

Another obstacle, according to the researcher: eMudhra's revocation servers reject requests from curl, Wget and Python and Perl libraries, widely used in scripts, but accept them as soon as the tool changes its name. Q Misell, who observed this independently, opened a Mozilla report, still with no response from eMudhra.

Google and eMudhra clash in public

On October 23, an eMudhra representative judged any serious analysis "practically impossible" under pressure from social media, investors and customers. These explanations are not "acceptable," Chrome's root certificate program replied: they suggest that reputation comes before the obligations owed to the "billions" of exposed users. On October 25, eMudhra owned its error "without reservation," but noted that its weak keys had been public for about eighteen months, and covered by audits, without anyone spotting them.

To eMudhra, Jacob Durham points out that as early as May 2025, the revocation lists of these intermediates failed signature verification: examining the keys then could have revealed the flaw sixteen months earlier. To Google, he asks why no check detected them, when members of its security team published a tool in 2022 capable of spotting them. Google says it has since verified that no other key in its trust stores has this flaw.

What should you check?

According to ctlogs.dev, which analyzes transparency logs, the risk concerns software that uses an outdated certificate list without checking either transparency or revocation: servers, containers built on old images, programming languages, embedded devices.

  • Update the certificate stores of your systems and languages (ca-certificates, certifi for Python, Go), with patched versions listed in our first article.
  • Rebuild your containers from up-to-date base images.
  • If a script checks revocation, an unreachable list must count as a failure, never a green light.
  • If one of your sites depends on the emSign ECC Root CA – G3 root, switch to another hierarchy recognized by Chrome, as Google requests.

Google has scheduled the removal of this root from Chrome for Tuesday, October 27, in the morning Pacific time, at the cost of legitimate certificates that will have to be replaced, and is reviewing the fate of eMudhra's other roots. Next step: according to Jacob Durham, eMudhra is due to have answered Chrome's twelve questions by October 28.

Method: AI-assisted monitoring, verified sources, article reviewed and approved by Frédéric LENQUETTE. Our editorial policy.

Vendor page: Google · 76 exploited vulnerabilities

Share this article