Abstract
On Tuesday, October 27, Chrome will distrust an eMudhra root certificate, emSign ECC Root CA - G3. Mozilla already did. Most of the people who have to deal with it run IT at American universities. They get their certificates from InCommon, the certificate service Internet2 runs for higher education. The certificates say Internet2 on them, but since April, eMudhra, an Indian certificate authority, has issued them.
Chrome counted about 30,800 unexpired certificates under that root, and 30,791 of them are InCommon’s. The universities that own them have until Tuesday to replace all of them.
Yet this was the top of eMudhra’s status page on October 21.
“All systems operational.” Except issuing certificates. You know, the thing a CA does.
How eMudhra went wrong
A certificate authority is just a handful of private keys and tools built to protect them. The keys are generated inside a hardware security module (HSM), a tamper-resistant box with its own random number generator, at a key ceremony with a written script, an auditor in the room, and probably some chanting.
On April 30, 2025, eMudhra held a ceremony to generate keys for 24 intermediate certificates. Some were meant for data centers in the US and Europe, so eMudhra changed the script to test exporting them. It says a flaw in that change created a second set of weak keys with similar labels. Staff picked the wrong set, eMudhra’s root signed them, and Sectigo cross-signed them. eMudhra’s summary is “human errors in multiple steps.” Nothing in its process caught it, and neither did the WebTrust audit eMudhra paid for over the next year.
A P-384 private key should be a random number about 116 digits long. Eight of the keys eMudhra created were three digits or fewer. One of them was literally 4.
-----BEGIN EC PRIVATE KEY-----
4
-----END EC PRIVATE KEY-----
(Yes, I know that the real version is base64 encoded and looks more complex. But it isn’t. This is an accurate representation of the key.)
Cracking it means trying 1, 2, 3, then 4. I have the same combination on my luggage. Scott Helme recovered all eight in under a second.
A researcher discovered them on October 17. Chrome and Firefox blocked them within hours, and eMudhra revoked them 15 hours later. They never issued a customer certificate, but that didn’t matter. Anyone can forge certificates with them, and plenty of software never checks revocation. Mozilla distrusted the root on October 20, and Chrome said it would follow. Microsoft and Apple are likely not far behind.
eMudhra was warned in June 2025
A month after the ceremony, when the incense smoke had cleared, revocation lists for the new intermediates failed their signature checks. Sectigo reported it. eMudhra blamed an “incorrect CA key configuration” and re-signed the lists with a key that matched the certificates. We now know that key was the broken one. eMudhra made the error go away by using the broken key in more places, so that everything matched. Chrome asked why eMudhra didn’t stop to find out where the second set of keys came from.
There’s no answer from eMudhra yet.
Then it happened again. On October 14, eMudhra published a revocation list for the RSA hierarchy used by most InCommon schools. Its signature doesn’t verify against any key eMudhra has disclosed. eMudhra replaced it about 14 hours later and hasn’t filed an incident report, though it said in 2025 that it had automated these signature checks. By the time the keys were found, eMudhra had seven other incident reports open, three of them about InCommon.
eMudhra says it has checked its other keys, “corroborated primarily using mathematical models facilitated by AI.” That sounds a lot like “ChatGPT said it was okay.”
Chrome is investigating whether to distrust eMudhra’s RSA root as well. I think eMudhra should be distrusted entirely. Root programs don’t trust keys. They trust the people holding them. These people generated a key of 4, missed it for 17 months, re-signed around the one alarm, and repeated the failure.
What it means for Internet2’s InCommon certificates
InCommon’s own ECC intermediates weren’t broken, but they chain to the distrusted root, so they go down with it. They have to, because anyone can now forge certificates under that root. On October 21, the open-source interception proxy mitmproxy added an --emudhra option that signs certificates for any site with the compromised intermediate key. Anything that still trusts the root and skips revocation checks, from a Python script with an old CA bundle to a device that never gets updates, will accept them.
On the evening of October 21, our CT log search showed 43 of 57 large universities still had current certificates on the ECC chain, 5,042 in all.
| Domain | Certificates on the ECC chain |
|---|---|
| umn.edu | 916 |
| umich.edu | 806 |
| uw.edu and washington.edu | 705 |
| ucsd.edu | 595 |
| cmu.edu | 246 |
Schools are trying. RSA issuance at these universities went from about 600 a day to 3,660 on October 21, and Indiana University replaced 586 certificates in one afternoon. Almost all of it stayed with eMudhra. Of 1,023 certificates we saw replaced in seven hours, 967 went to its RSA chain and 56 to Let’s Encrypt. Michigan’s security office lists Let’s Encrypt first and warns that a new RSA certificate from eMudhra “may not be permanent.”
This is higher ed’s second forced CA move this year. InCommon finished moving schools from Sectigo to eMudhra in July, after picking it as “the provider built to meet those requirements for the next 15 years.” Three months later, its ECC root is being distrusted.
If your certificate’s issuer ends in G3C, it’s going to stop working on Tuesday. Check your domain in our chain checker, which flags the distrusted root starting October 22.
Replacing 30,000 certificates in a week
eMudhra says 97% of these certificates came through ACME, which should make this easy. It doesn’t, because the CA and key type are set separately on every server that asks for a certificate.
Staying with eMudhra is the easy path, and almost everyone is taking it. Even that means touching every server. ECC orders now sit and wait, per eMudhra’s status page, so admins are pushing bulk config changes, or logging into servers one at a time, to switch each Certbot certificate to --key-type rsa.
Leaving eMudhra is the better path, but it’s harder. Every client has to be pointed at a new CA, and the popular ones won’t move an existing certificate without forcing a new one. CAA records that only allow emsign.com have to change first. The new CA brings its own rate limits. At Let’s Encrypt’s 50 new certificates per domain per week, the University of Minnesota would need about 18 weeks. And the load balancers and appliances ACME never touched still need someone to log in and import a certificate by hand.
eMudhra took the better path and got its own certificates elsewhere. On October 21, the same day its status update offered every Enterprise TLS customer “certificates from an additional publicly trusted CA” (quoted by Chrome), a Sectigo certificate for its own *.certinext.io product site showed up in CT logs. By the next morning, the site was serving it.
If you’re moving off eMudhra (and you should)
With per-server ACME, the CA lives in hundreds of separate configs, and changing it means logging into each server and checking what it serves. That takes days.
In CertKit, the issuer is just a setting on your certificates. You can create a certificate with Sectigo and move it to Let’s Encrypt or Google in a few clicks. If there’s another emergency like eMudhra, ask us. We can bulk migrate all your certificates in about 10 minutes, spread across several CAs so no single rate limit holds it up, and deployed all the way into your infrastructure.
If you’re dealing with the eMudhra distrust, contact us. We’ll help you set up CA-agnostic tooling, so this is the last time switching CAs takes a week.
CertKit automates certificate lifecycle management so the next CA distrust is someone else’s problem.