# A Certificate Authority Left Its Keys in the Door: The eMudhra Compromise

URL: https://nanosolutions.io/emudhra-certificate-authority-key-compromise
Date: 1792627200
Description: A company trusted to vouch for websites made keys anyone could copy. Your browser is safe. Your servers and apps may not be. What to check this week.

---


<div class="post-tldr">
  <p class="post-tldr__label">The short version</p>
  <ul>
    <li>eMudhra, one of the companies trusted to vouch for websites, made eight of its signing keys so badly that anyone could copy them.</li>
    <li>With them, a criminal could fake any website or make malware look like trusted software.</li>
    <li>Your web browser was never fooled and now blocks them. Servers, apps and older devices may still trust them.</li>
    <li>The fix is a routine update. Ask whoever runs your IT to confirm it is done, and that container images were rebuilt.</li>
  </ul>
</div>

## The padlock, in one paragraph

When you see the padlock in your browser, a small number of companies called certificate authorities have vouched that the website is who it says it is. Your computer trusts them completely. Their signing keys are among the most important secrets on the internet, because anyone holding one can vouch for anything.

## What went wrong?

eMudhra is an Indian certificate authority trusted by Apple, Google, Microsoft and Mozilla. In April 2025 it made a new set of signing keys at a formal key ceremony. A software bug during that ceremony produced eight keys that were barely keys at all. [Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) describes them as *"effectively all-zeroes apart from the last byte."* Imagine a safe whose combination is 0-0-0-7.

Nobody noticed for 18 months. On [date:2026-10-17|https://emudhra.we-have-a-problem.com/], a researcher called Wayne reported it, and proved the point by signing the message *"We have a problem here"* with all eight keys.

Six of the keys could vouch for websites. Two could vouch for Windows software, which means they could have made malware look like it came from a verified publisher.

## Was anyone actually at risk?

**Not through your browser.** Chrome, Firefox, Safari and Edge only accept a website certificate that has been recorded in public logs, and no fake ones ever were. All four now block the eight keys outright.

**Everything else is a different story.** Servers, apps, scripts, smart devices and developer laptops usually keep their own list of trusted companies and do not check those public logs. Until that list is updated, they would accept a fake. The researchers say plainly: *"We do not know if attackers exploited the flawed key generation to target these clients."*

## What happened next

- **17 October**: reported. Firefox and Chrome block the keys the same evening.
- **18 October**: eMudhra cancels all eight.
- **19 October**: Apple blocks them.
- **20 October**: Microsoft blocks them through Windows Update. Mozilla stops trusting the eMudhra root they came from altogether.
- **27 October**: Chrome is expected to do the same.

## What we found on our own machines

We tested our own equipment the morning after:

- **Our servers**, including the one running this website, had already taken the update and refused the fake certificates.
- **One of our developer laptops did not.** The browser was fine, but the command-line tools, PHP and Node.js on the same Mac all accepted them.
- **This website's code** included a PHP library with an old trusted list. We updated it the same day.

The servers were where we expected trouble, and they were fine. The laptop and a code library were the gaps. That is probably true for a lot of businesses.

## What should you do?

Ask your IT provider or developer three questions:

1. **Have our servers had this week's security updates?** On Linux, the package is `ca-certificates`.
2. **Have our container images been rebuilt since 20 October?** Updating a server does not update the images running on it.
3. **Do any of our apps or devices keep their own trusted list?** Mobile apps, desktop apps, old integrations and network appliances are the usual ones.

Most websites do not need new certificates. Only about 30,000 were issued under the affected hierarchy, nearly all through InCommon, a service used by US universities. Click the padlock on your site: if it says Let's Encrypt, DigiCert, Sectigo, Google or Amazon, you are fine.

## For the technical team

Each of these should fail with a certificate error. Run them on hosts, inside containers and from your app's runtime:

```bash
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
```

If either loads, update. Fixed so far: Ubuntu `ca-certificates` 20260816ubuntu0.*, Debian 20250419+deb13u1 and ~deb12u2, Alpine 20261020-r0, Node.js 22.23.4 / 24.22.1 / 26.12.1, Java 21.0.13 / 17.0.21 and the other October updates, Go 1.27.3, Python `certifi` 2026.10.19, PHP `composer/ca-bundle` 1.6.0. Node.js and Java carry their own lists, so updating the operating system is not enough for them.

On macOS, Homebrew users should run `brew upgrade ca-certificates`, and `/etc/ssl/cert.pem` needs the manual fix on the [researchers' page](https://emudhra.we-have-a-problem.com/), which also has the full list of fixes and a Windows script.

For organisations working to the Essential Eight, this is ordinary [application](/essential-eight/patch-applications) and [operating system](/essential-eight/patch-operating-systems) patching. Container images count.

## Frequently asked questions

### Could someone have faked our website?

To visitors on a normal browser, no. To software that does not check the public logs, it was possible. Nobody has reported it happening, but nobody can rule it out.

### Is this connected to PHP2Shell?

No, the timing is a coincidence. [PHP2Shell](/php2shell-critical-php-vulnerabilities) is a bug in PHP itself. Both are good reasons to check this week that your servers are actually being updated.

### What happens to eMudhra now?

Mozilla's investigation is still open. Certificate authorities have been removed from browsers entirely for less. We will update this post if that happens.

---

Not sure whether your servers and apps have taken the update? [Get in touch](/contact) and we will check for you. For ongoing patching, see our [cloud maintenance service](/services/cloud-maintenance).

**Photo credits.** All images used under the [Unsplash License](https://unsplash.com/license) &mdash; free for commercial use, attribution appreciated:

- Keys hanging in a door lock &mdash; [Matt Clark](https://unsplash.com/photos/keys-hanging-in-a-door-lock-WETkxYfCPGw)

## Sources

- [eMudhra Intermediate CA Compromise](https://emudhra.we-have-a-problem.com/) &mdash; Dennis Jackson and contributors, 20 October 2026. Proof, test sites, full list of fixes, workarounds for each platform.
- [Bug 2083449](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) &mdash; Mozilla. What went wrong at the key ceremony, timeline, number of affected certificates.
- [Mozilla dev-security-policy discussion](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE) &mdash; CA operator thread.
- [Ubuntu](https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/2171507), [Debian](https://bugs.debian.org/1151413), [FreeBSD](https://www.freebsd.org/security/advisories/FreeBSD-SA-26:73.caroot.asc), [OpenJDK](https://openjdk.org/groups/vulnerability/advisories/2026-10-21), [Python certifi](https://github.com/certifi/python-certifi/releases/tag/2026.10.19) and [composer/ca-bundle](https://github.com/composer/ca-bundle/pull/154) &mdash; fixes.
