A CA Private Key of 4: What eMudhra Teaches Us About Trust

The cover image for this post is by FlyD on Unsplash

⚠️ An evolving situation

This post was written on Friday 23 October 2026, and its sources were last checked at 13:40 BST, six days after the incident was disclosed. eMudhra has not yet confirmed its root cause, the Chrome Root Program is still reviewing eMudhra’s remaining root certificates, and several of the questions put to eMudhra in public have not yet been answered. Details may change after publication. Every factual claim below links to its source, so you can check where things stand when you read this, and the end of the post lists archived copies of the main sources as they read on the day of writing.

Update, 24 October 2026: on 23 October, the Chrome Root Program told eMudhra that social media scrutiny and investor analysis “are not acceptable explanations for delayed responses”, and Mozilla said that eMudhra had not yet answered the questions it sent on 20 October. eMudhra’s comment earlier that day is quoted in “What We Still Don’t Know” below. Sources re-checked at 10:00 BST on 24 October 2026.

Update, 27 October 2026: on 25 October, eMudhra replied to the Chrome Root Program, rejecting its characterisation of eMudhra’s conduct, saying that its full report is due within the 14 days that CCADB allows, and arguing that software which checks revocation has been protected since 18 October. A contributor responded that 107,107 certificates signed with six of the compromised keys had been logged to CT on 20 and 21 October, after the keys became public, and that almost none of them carry a revocation pointer, so software that only checks a website’s own certificate for revocation won’t reject them. On 26 October, eMudhra’s status page apologised, attributed the weak keys to “a script error”, and said that eMudhra is commissioning an independent review of the incident; its full root-cause report has not yet been filed. “What We Still Don’t Know” and the checklist below have been updated to match. Sources re-checked at 09:40 GMT on 27 October 2026.

Update, 28 October 2026: Chrome’s removal of emSign ECC Root CA - G3 was due to reach all devices on 27 October (PDT), and Google hasn’t announced any change to that schedule. Apple’s own guidance says it began blocking the six TLS intermediates and their Sectigo cross-signs on 19 October, not 22 October as earlier versions of this post said, following Dennis Jackson’s disclosure site. The Chrome Root Program called its block “emergency containment, not the end of our work”, and has proposed that CCADB check every CA certificate for weak keys before it can be disclosed. eMudhra now says it will stop issuing from its G1 root as well. The timeline, the InCommon section, “What We Still Don’t Know” and the checklist below have been updated to match. CCADB’s rules give eMudhra 14 days from the incident’s public disclosure on 18 October to file its full root-cause report, so it is due by 1 November; this post will be updated when it is filed, and until then the Bugzilla thread is the place to follow it. Sources re-checked at 12:45 GMT on 28 October 2026.

Update, 29 October 2026: eMudhra has answered the twelve questions the Chrome Root Program asked on 21 October. It posted the answers to Bugzilla at 00:26 UTC on 29 October, after the seven-day window Chrome had set had passed, and says it had already sent them to the root programmes directly. The answers correct eMudhra’s first account of how the weak keys came to be used. It had said they were picked by mistake because their labels were similar; it now says the ceremony script itself specified them. eMudhra also accepts that it should have reported the 2025 warning sign to Sectigo and the root programmes at the time. It says about 70% of the affected certificates have now been replaced, and explains the October 2026 problem with a G1 revocation list as an operator error. Community contributors have already followed up with further questions. “How It Happened”, “The Warning That Was Missed”, the InCommon section, “What We Still Don’t Know” and the checklist below have been updated to match; the checklist also now notes that OpenJDK, unlike Oracle’s JDK, is still waiting for a fix. eMudhra’s full root-cause report is still due by 1 November, and this post will be updated once more after that date. Until then, the Bugzilla thread is the place to follow it. Sources re-checked at 16:40 GMT on 29 October 2026.

Update, 2 November 2026: CCADB’s rules required eMudhra to post its full root-cause report “within 14 days of the incident’s initial disclosure”, which meant by 1 November. By 09:50 GMT on 2 November, it had not appeared on the Bugzilla thread or as a new bug. Nor had the separate report on its revocation list error, which eMudhra said it would file on 29 October; on 1 November, a contributor asked for that report, or a new date and the reason for the delay. On 30 October, eMudhra appointed KPMG as the independent reviewer it had promised. Another bug has also undercut eMudhra’s argument, described in the 27 October update, that software which checks revocation has been protected since 18 October. In its own report on that bug, eMudhra confirms that from September 2022 until 26 October 2026, its web application firewall refused HTTP requests for its revocation lists and OCSP responses from curl, Wget, Python-urllib and libwww-perl, HTTP clients used by scripts and command-line tools. As a contributor pointed out, that included the lists revoking the eight compromised intermediates, for about eight days after they were revoked. Google still hasn’t announced that Chrome’s removal of emSign ECC Root CA - G3 is complete. “What We Still Don’t Know” below has been updated to match. Until eMudhra files its report, the Bugzilla thread is the place to follow it. Sources re-checked at 09:50 GMT on 2 November 2026.

Update, 3 November 2026: on the afternoon of 2 November, after the deadline had passed, eMudhra said it would need “an additional week (Nov 9th, 2026)” before it shares its full incident report. CCADB’s rules say the report “MUST be posted within 14 days of the incident’s initial disclosure”. eMudhra also said its earlier answers were “based on our analysis of what our internal teams could gather up until that point in time”, and a contributor has asked it to say which of them, including the account in “How It Happened” below, still stand. The separate report on its revocation list error has still not been filed. “What We Still Don’t Know” below has been updated to match. Sources re-checked at 14:20 GMT on 3 November 2026.

Update, 9 November 2026: eMudhra’s full incident report, which it said would need until 9 November, had not appeared on the Bugzilla thread by 10:35 GMT that day. On 6 November, CCADB also marked as stale eMudhra’s report on its blocked revocation checks, because the community’s questions on it had gone unanswered. In the meantime, the browsers have acted on G1, the root that InCommon’s institutions moved to as a stopgap. On 4 November, the Chrome Root Program announced that Chrome will stop trusting TLS certificates that chain to emSign Root CA - G1 and were first logged to CT after 23:59:59 UTC on 16 November 2026; certificates logged on or before then are unaffected. Its reason was that eMudhra “has not affirmatively responded to inquiries regarding its key-handling practices in a manner consistent with our expectations”. Mozilla set the same cutoff in its root store the next day. eMudhra’s status page adds that Apple will remove G1 on 30 November, after which no G1 certificate will be trusted on Apple’s platforms, whenever it was issued. Apple hasn’t announced this itself, so for now eMudhra is the only source for that date. eMudhra also says that every customer outside the US has already moved to another provider, and that it expects the rest to move before Apple’s date. The InCommon section, “What We Still Don’t Know”, the checklist and the closing section below have been updated to match. Sources re-checked at 10:35 GMT on 9 November 2026.

Update, 10 November 2026: by 11:20 GMT on 10 November, the day after eMudhra’s own revised date, its full incident report still hadn’t appeared on the Bugzilla thread, and eMudhra hadn’t given a new date; a contributor asked for one that morning. eMudhra does still say the report is coming. On 9 November, replying on the bug about its blocked revocation checks, it accepted that between 18 and 26 October the revocation lists and OCSP service covering the compromised intermediates were unreachable over HTTP for curl, Wget, Python-urllib and libwww-perl. It said it would correct its 25 October claim that software which checks revocation had been protected since 18 October (see the 27 October update above), and that the correction would appear “in the updated Full Incident Report”. Apple has also closed the macOS gap described in the checklist. Its updated guidance says that macOS 27.2.1, 26.7.3 and 15.8.3 stop curl, git and the other command-line tools from accepting the compromised certificates, and remove the affected roots from /etc/ssl/cert.pem, so the file now only needs editing by hand on Macs that can’t be updated. “What We Still Don’t Know” and the checklist below have been updated to match. Sources re-checked at 11:20 GMT on 10 November 2026.

On Saturday 17 October 2026, a researcher reported that eight intermediate certificate authority (CA) keys belonging to eMudhra, an Indian CA trusted by every major browser, could be recovered by anyone who looked at the certificates. The private key behind EM OV TLS CA - G3C, an intermediate that Chrome, Firefox, Safari and Windows all trusted to vouch for websites, was the integer 4: the same number you’d get by counting the wheels on a car.

It’s tempting to post a link to xkcd 221 and move on. What makes this worth a few thousand words is that nothing about these certificates looked wrong. They passed every structural check, sat inside browser trust stores for around seventeen months and two audit cycles, and were found only because someone tried. And this isn’t the first time a certified, audited key generation process has produced keys that anyone could work out.

I’ll start with what a certificate authority actually does, using a passport office as the analogy, because the places where that analogy breaks are where the risk lives. Then we’ll look at what went wrong at eMudhra, the pattern it fits, who is paying for it, and what you should still check outside the browser.

What a Certificate Authority Does: The Passport Office

Imagine you arrive at a border. The guard has never met you, has no idea who you are, and has a few seconds to decide whether to let you through. You hand over a passport. The guard doesn’t trust you; the guard trusts the government that issued the document, and the document says the government checked who you are before issuing it.

That is almost exactly what happens every time your browser connects to a website over HTTPS.

• ✅ The passport is the certificate. A website presents a certificate that says “this is example.com”.
• ✅ The government is the certificate authority. The certificate is only worth anything because a CA has signed it.
• ✅ The application process is validation. Before issuing, the CA checks that you control the domain (domain validation, or DV), or goes further and checks the organisation behind it (organisation validation, OV, and extended validation, EV).
• ✅ The border guard is the browser, or any TLS client: the software that receives the certificate and decides whether to trust it.
• ✅ The cancelled passport list is revocation. CAs publish certificate revocation lists (CRLs) of documents that should no longer be accepted, and browsers ship their own block lists on top (Mozilla calls its list OneCRL; Chrome’s is called a CRLSet).
• ✅ Expiry dates exist on both. A certificate is valid for a fixed period, then it has to be renewed.

The government rarely stamps every passport itself. It delegates to regional offices, which have their own official stamps, and the government vouches for those stamps. In certificate terms these offices are intermediate CAs: the root CA, which is kept offline and guarded carefully, signs an intermediate, and the intermediate signs the certificates websites actually use. Every one of the eight eMudhra certificates in this story was an intermediate: a regional office.

Then there’s the question of which countries accept which passports. A border guard in one country has a list of the governments whose documents it accepts. Browsers and operating systems have exactly this; it’s called a trust store, and the organisations that maintain them (Apple, Google, Microsoft, Mozilla and others) run root programmes that decide which CAs get in, what they have to do to stay in, and when they get thrown out.

The last piece is the seal. For centuries, official documents were sealed with a signet ring. Anyone could look at the wax and check the impression; only the holder of the ring could make it. A CA’s private key is that ring. The signature on a certificate is the impression in the wax, and anyone can check it against the CA’s public key. The whole arrangement depends on nobody else being able to make a ring that leaves the same impression, and at eMudhra, the ring is what broke.

Where the Metaphor Breaks Down

Analogies are useful right up until the point you start reasoning from them instead of from the thing itself. The passport office gets the shape of the system right, but there are four places where the real thing is more fragile than the metaphor suggests, and every one of them matters to this incident.

There Is No Hologram

A passport resists forgery physically: specialist paper, holograms, embedded chips, ink that changes colour under ultraviolet light. A border guard who suspects a fake can tilt it under the light.

A certificate has nothing like that. It’s a small file of structured data, and its only protection is the mathematical signature, which is only as strong as the secrecy and randomness of one very large number. If that number can be guessed, the forgery is perfect. There is nothing to tilt under the light. As Scott Helme put it when he examined the eMudhra certificates:

It’s interesting that nothing about these certificates looks wrong. A public key derived from d = 4 is a perfectly valid point on the curve, the encoding is fine, the curve is fine, every structural check passes. The only way to find out is to try.

A Certificate Doesn’t Say Who You Are

A passport identifies a person. A TLS certificate does something narrower: it binds a key to a domain name. It says “whoever holds this key may speak for example.com”, and that’s all. It doesn’t say the organisation is honest, competent or solvent. This matters because someone holding a forged certificate doesn’t need to fool anyone about who they are; they only need to be in the network path between you and the site.

Many Border Guards Never Check the List

A border guard always checks the cancelled passport database. Software usually doesn’t check revocation at all. Browsers maintain their own block lists precisely because live revocation checking is slow and unreliable, but outside the browser, the defaults are worse. Most command-line tools and language runtimes don’t check revocation by default. They trust whatever is in their trust store, and if a bad intermediate chains to a trusted root, they accept it. Scott Helme tested this with a forged certificate for api.stripe.com chained through one of the eMudhra intermediates: with default settings, curl, Python and Node.js all accepted it.

ℹ️ Warning

This is why “the CA has revoked the certificates” isn’t the end of the story. Revocation only protects the clients that check for it. Everything else, from your CI pipeline to the container image a supplier built two years ago, keeps accepting them until its trust store is updated.

Every Country Can Issue Your Passport

This is where the system is most fragile, and the passport metaphor hides it. In the physical world, France can’t issue a valid British passport. In the world of web certificates, any trusted CA can issue a certificate for any domain. A CA in one country can vouch for your bank or your company’s login page, and browsers will accept it, because the system has no concept of which CA “owns” which websites.

There are mitigations. Domain owners can publish Certification Authority Authorization (CAA) records saying which CAs may issue for them, and Certificate Transparency (CT) logs make every issued certificate public so that misissuance can be spotted. But CAA is checked by honest CAs at issuance time; someone holding a stolen or guessed CA key isn’t going to check it. So the security of every website on the internet depends, in part, on the operational discipline of every CA that browsers trust; several dozen organisations, any of which can sign for anyone.

What Happened at eMudhra

In passport terms, a government accredited a regional passport office whose official seal, it turned out, was the factory default design. Nobody stole anything. Anyone who looked at a passport the office had stamped could make an identical seal, and anything they stamped with it was indistinguishable from the real thing.

Forgers copy a good seal; here, the genuine, official seal was itself the reproducible thing.

The Keys

On 30 April 2025, eMudhra held a key generation ceremony (the formal, witnessed process in which a CA creates its signing keys) and produced 24 intermediate CAs. Eight of them, all using the P-384 elliptic curve, ended up with private keys that were tiny. Mozilla’s Dennis Jackson described the problem in the incident’s public bug:

The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte.

A P-384 private key should be a random number with around 116 decimal digits. Each of these was a number between 1 and 255. You can recover them by generating the first 256 possible keys and seeing which ones match; Scott Helme published the recovered values:

The six TLS intermediates were trusted by the Chrome, Mozilla, Microsoft and Apple root programmes, and both Google and Mozilla said that anyone holding one of these keys could have issued a trusted certificate for any website. The two code signing intermediates were trusted by Microsoft, which, as India’s CERT-In warned, could let malicious software appear signed by a legitimate publisher. In May 2025, Sectigo had also cross-signed all eight, so sixteen certificates in total shared these eight keys.

The Week That Followed

The response from the root programmes was fast. All times below are UTC, and are drawn from the Bugzilla thread, Google’s post, Apple’s support article and Dennis Jackson’s disclosure site.

• 17 October, 16:27: the researcher, who goes by Wayne, finds the break while testing a corpus of intermediates published in the Common CA Database (CCADB).
• 17 October, 18:05: Wayne emails Apple, Chrome, Microsoft, Mozilla and eMudhra, with signed proof of each key.
• 17 October, evening: Chrome confirms the findings at 19:45 and pushes a CRLSet blocking the six TLS intermediates. Mozilla independently recovers the keys at 21:48, without knowing the reporter’s method, and completes its OneCRL block at 22:59.
• 18 October, 09:24 to 09:38: eMudhra revokes all eight, using the revocation reason cACompromise.
• 19 October: Sectigo revokes its cross-signs; Android devices receive Chrome’s block via Google Play Services. Apple begins blocking the six TLS intermediates and their cross-signs.
• 20 October: after several people independently recover the keys, and some post about it publicly, Mozilla removes the root above them, emSign ECC Root CA - G3, entirely. Microsoft begins blocking the same day.
• 22 October: eMudhra announces it will leave the global TLS certificate business.
• 23 October: Apple begins blocking emSign ECC Root CA - G3.
• 27 October (PDT): Chrome’s removal of emSign ECC Root CA - G3 was due to reach all devices.

Notice the ordering. Firefox and Chrome had blocked the intermediates by 23:00 on the 17th, more than ten hours before eMudhra revoked them. The system is designed to work that way: the root programmes are the backstop, and on this occasion the backstop did its job.

Mozilla’s reasoning for the root removal is worth quoting, because it explains the non-browser problem better than I can:

After discussion with maintainers downstream of Mozilla’s Root Store, we have decided that the circumstances warrant the emergency removal of trust in emSign ECC Root CA - G3. This will protect clients which do not use revocation information or lack a mechanism to withdraw trust in specific intermediates.

How It Happened, According to eMudhra

eMudhra’s preliminary account, which Mozilla has not independently verified, is that the keys were generated on FIPS 140-2 Level 3 hardware security modules (HSMs), the tamper-resistant devices CAs use to create and hold their keys. During the ceremony, an approved deviation from the usual script was in place to test wrapping and unwrapping the keys for export. A flaw in that code created a second, weaker set of keys on the device. eMudhra first said that, because the key labels were similar, the weak keys were used by mistake to create the certificate signing requests (CSRs). Its answers to the Chrome Root Program on 28 October corrected that. The ceremony script generated each key, then wrapped, unwrapped and re-imported it as a planned rehearsal, and “the ceremony script specified creating the CSRs from the re-imported keys, and it did so.” The participants knew that each CA now had two key objects with the same label; what they didn’t understand, eMudhra says, was that the two objects contained different data. eMudhra acknowledges human error at multiple steps, is commissioning an independent review, and says it has not yet confirmed the exact root cause.

The best label for this today is a rehearsal step that became production: the script did what it was written to do, and nobody noticed that the key that came out wasn’t the key that went in. Others in the thread have asked how an HSM in its certified mode could produce a key of 4 at all; as one commenter set out, either key material was supplied to the device, or the CA’s own policy that keys are generated inside a certified device wasn’t followed in practice. That question is still open, and contributors have since asked whether the HSM generated a second set of keys or corrupted the first set on re-import, and for the script, ceremony records and HSM logs themselves.

The Warning That Was Missed

The part of this story that should worry engineering leaders most happened in mid-2025. Shortly after the ceremony, eMudhra published revocation lists for six of these intermediates that failed signature verification, and a bug was filed. The CRLs had been signed with the original, strong keys; the certificates had been issued over the weak ones. The two didn’t match.

That mismatch was the canary. It was resolved by re-signing the CRLs with the keys that did match, which were the weak ones. The Chrome Root Program has since asked eMudhra the obvious question:

Why did eMudhra simply re-sign the CRLs with that second key rather than halting operations, auditing why two key pairs existed for these CAs from the April 30, 2025 KGC, and revoking the certificates?

When I first wrote this, my suspicion was that the honest answer is the most ordinary thing in engineering: a puzzling mismatch turned up, someone found a configuration that made the error go away, and the system went green. Most of us have done exactly this with a failing test or a flaky deployment.

eMudhra’s answer, filed on 28 October, comes close to that. In June 2025 the failure “looked to us like a signing-key configuration issue”, so the fix was to point the CRL application at the key that matched each certificate. It also concedes the larger point:

In hindsight, the mismatch we found in June 2025, between the key that signed the CRLs and the key in each CA certificate, was enough on its own to tell Sectigo and the root programs that the certified keys might not be the keys the ceremony intended, even before we understood why. We should have reported it in those terms.

Amy Edmondson has a name for this shape of failure. In Right Kind of Wrong, which I reviewed last year, she separates basic failures, caused by inattention or lack of skill, from complex ones, which emerge when several ordinary factors interact in a setting everyone thinks they understand:

Complex failures happen in familiar settings, which is what distinguishes them from intelligent failures. Despite being familiar, these settings present a degree of complexity where multiple factors can interact in unexpected ways. Usually, complex failures are preceded by subtle warning signs. Finally, they often include at least one external, seemingly uncontrollable, factor.

A routine ceremony, a one-off deviation in the script, two keys with similar labels, and a revocation list error that went away when someone tried the other key. None of those, on its own, is the root cause. That matters for what happens next, because complex failures are fixed by changing the system that produced them, and looking for someone to blame gets in the way. To its credit, eMudhra has defended the experience of the team involved rather than offering anyone up. The question the root programmes are rightly asking is what in the process allowed the warning sign to be explained away.

💭 Thought

If a cryptographic check failed in your organisation tomorrow, and an engineer found a key that made it pass, would anyone ask why there were two keys? Or would the ticket be closed as resolved?

Reading the Statements Carefully

eMudhra’s incident statement includes a line I agree with: “We believe an organization’s character is shown in how it responds when something goes wrong.” So it’s worth reading its responses closely, because several of them are accurate and still answer a question nobody asked.

Announcing its exit from the business on 22 October, eMudhra’s chairman said that the company revoked the affected CAs “within 14 hours of discovery”, and that:

Its infrastructure was not compromised and no data was breached. All physical and logical security controls remained intact.

All of that is true, and almost entirely beside the point. Nobody broke in because nobody needed to; the keys were derivable from public data from the day the certificates existed. In PKI terms that is a compromise, which is why eMudhra itself revoked them with the reason cACompromise. The fourteen hours depends on where you start the clock: the report reached eMudhra at 18:05 on the 17th, and the last revocation landed at 09:38 the next morning, about fifteen and a half hours later. The statement that no end-entity certificates were issued from the affected CAs is genuinely good news, but it covers only the certificates eMudhra issued. The risk was always that someone else could issue them.

There are two more claims to handle with care. You may have read that the weak keys were “found by AI”. eMudhra says the researcher “reportedly” used AI-assisted tooling; the researcher’s own timeline says only that he’d started playing with some new toys. What is confirmed is that Dennis Jackson tested local AI agents and found they recovered the keys on their first attempt from a one-line prompt. That tells us how trivial the attack was, not how the flaw was found. And you may have seen early coverage saying 60 million certificates can’t be trusted; that’s eMudhra’s lifetime issuance, not the exposure. The real number is eight keys, sixteen certificates, and roughly 30,800 legitimate certificates that now need replacing.

This Has Happened Before

As far as I can find, eMudhra is the first time a publicly trusted CA’s key has been trivially derivable. The failure mode itself has happened before.

Debian’s keys were generated by widely trusted open source software. ROCA’s were generated inside certified secure hardware, and were trusted by a national government for its citizens’ identity cards. eMudhra’s were generated in a formal, audited ceremony using FIPS-certified HSMs. In every case, the process around key generation was respectable, and the output was broken.

There’s a second strand of history running alongside this one: CAs that failed through process and oversight rather than mathematics. Symantec’s weak supervision of the partners it allowed to issue certificates led to a phased distrust and the sale of its CA business to DigiCert in 2017. In 2024, Google cited six years of compliance failures and unmet improvement commitments when it moved to distrust Entrust. eMudhra sits at the junction of both strands: a key generation failure that a process failure then kept in place for seventeen months.

Audits Certify That a Process Exists

eMudhra had a documented ceremony, certified hardware, and two clean audit cycles. Every one of those controls asks, in effect, “do you have a process, and did you follow it?” None of them asked “is the key you produced actually random?”, and that is a question you can only answer by checking the output.

I’ve written before about treating penetration tests like final exams: a point-in-time check that tells you a moment in the past went well. Audits work the same way. They’re necessary, and they are not the same thing as verification.

Who Pays: The InCommon Story

If you read eMudhra’s own statement, the impact sounds contained: it says the distrust “affects one customer ecosystem in the United States”. That ecosystem deserves a closer look.

The Chrome Root Program’s analysis of CT logs found roughly 30,800 unexpired certificates chaining to the root being removed. 99.9% of them came from two intermediates operated for InCommon, the certificate service that Internet2 runs for US universities and research institutions.

InCommon didn’t pick its provider casually. Its transition guide describes a redesign group formed in 2023 that surveyed nearly 500 certificate administrators before selecting CertiNext, a US subsidiary of eMudhra, “as the provider built to meet those requirements for the next 15 years”. Subscribers moved over from Sectigo between 7 April and 17 July 2026, and every institution signed a new agreement.

Three months after completing that migration, those institutions are migrating again, ahead of a browser deadline they didn’t set, because of a key ceremony they had no part in. And it may not be the last move. InCommon’s FAQ, updated on the evening of 22 October, says that because eMudhra is winding down its public roots, its intermediates “will need to be chained up to different publicly trusted roots, or certificate issuance will need to be provided via a different public root CA.” On 28 October, eMudhra confirmed that those institutions are now issuing from its G1 RSA root as a stopgap, and that it will stop issuing from G1 once they have moved to another provider, which will make it their third migration this year. eMudhra told the Chrome Root Program the same day that, going by its contact with the 267 organisations affected, about 70% of their certificates have been replaced, although 25,058 of them were still unexpired and unrevoked. It has asked the browsers for time to move the rest off G1, and says it can’t give a completion date until they respond. The browsers have since given it one. Chrome and Mozilla will stop trusting G1 certificates issued after 16 November, and eMudhra says that Apple will stop trusting every G1 certificate, however old, on 30 November.

InCommon did the due diligence most organisations only intend to do, and it still couldn’t see inside another organisation’s key ceremony. Anyone who buys infrastructure is in the same position.

The knock-on effects spread further. Python’s widely used certifi package, which supplies the trust store for a large share of Python software, has no way to block an individual intermediate. So its first fix, on 18 October, removed every emSign root, and university users reported breakage within hours; one commenter warned it would “break quite a bit of Python software in the US Research & Education community”. A follow-up release restored the unaffected roots the next day. Nobody in that chain made a bad decision. The maintainers chose the blunt option because the alternative was exposing every user to interception. But it shows how a CA’s problem lands on people who never chose that CA, and never knew they depended on it.

Running Your Transport Layer as a Rounding Error

For decision makers, the commercial side of this may matter most. In its exit announcement, eMudhra said global TLS certificates contributed about 1% of its revenue, that costs were rising, and that “some of the large entities issue the SSL/TLS free of cost”. It also said:

The level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business.

The markets disagreed about the proportion: Business Standard reports that eMudhra’s shares hit the maximum permitted daily fall of 20% on two consecutive days, reaching a 52-week low. Free, automated certificates have pushed the margin on public TLS close to zero, which is good for the web and leaves little commercial cushion for a CA that suffers a reputational hit. The organisation you trust with the integrity of your transport layer may be running that function as a side line, and may rationally decide to walk away from it.

💭 Thought

Do you know whether your CA considers your certificate its core business, or a legacy line it might exit?

Back at the passport office, the arc is complete. A regional office issued documents with a reproducible seal; border posts around the world started rejecting everything from it; and the country then announced that it would stop issuing passports for international travel altogether, while continuing to issue domestic identity documents as before. eMudhra is keeping its Indian digital signature, eSign and enterprise businesses, and describes its exit as voluntary. But international recognition was always a privilege extended by other countries, and by the time eMudhra announced its exit, they had already withdrawn it.

What We Still Don’t Know

Some of the most important questions in this incident are still open at the time of writing.

• The root cause. eMudhra has promised a full report to the root programmes. The question of how a certified HSM produced these keys hasn’t been answered. On the morning this post was written, eMudhra commented on the Bugzilla report that it would uphold its disclosure obligations, but that social media scrutiny and investor and customer analysis had made “doing any meaningful analysis of the event pretty much impossible” so far. On 27 October, eMudhra said it had answered Mozilla’s questions in private, because of “the sensitive nature of some of the content”, and would work with the root programmes on what could be published. Its full report was due by 1 November under CCADB’s rules, and had not been posted by 09:50 GMT on 2 November. That afternoon, eMudhra said it would share the report by 9 November, and described its earlier answers as based on what its internal teams “could gather up until that point in time”. On 30 October, eMudhra appointed KPMG to review the incident independently. When this post was last checked, at 11:20 GMT on 10 November, the report still hadn’t appeared, and eMudhra hadn’t said when it would.
• Where customers should move. eMudhra first told Bugzilla that subscribers would move to its RSA root, emSign Root CA - G1, the “only alternative available”. Its status page then spoke of “an alternate, independently operated, publicly trusted CA hierarchy”, and a later update offered Sectigo certificates. The Chrome Root Program formally asked which it is, and eMudhra’s answer on 28 October was both. Subscribers outside the US, who mostly didn’t use ACME, are being reissued Sectigo certificates, which eMudhra expects to finish by 15 November; InCommon’s institutions are on G1 as a stopgap until a further move. On 5 November, eMudhra said that every customer outside the US had moved, and that it expects the US customers to follow before 30 November. It hasn’t said which provider InCommon will move to.
• The G1 root itself. On 14 October, three days before the disclosure, eMudhra published a revocation list for one of its G1 roots with a signature that didn’t verify. Contributors to the bug traced it to the wrong signing key, the same class of error as the 2025 canary. Chrome asked whether multiple key pairs exist for G1 or any other root. eMudhra’s answer is that an operator, while replacing the certificates of its OCSP responders (the services that answer revocation queries), mistakenly pointed the root’s CRL signing at a new OCSP responder key. It says G1 has a single key pair, and that a review of its other roots is under way. It also admits that the checks it introduced after the 2025 canary covered only the CRLs of its issuing CAs, not those of its roots. A contributor has since pointed to a second root CRL signed in the same way. eMudhra said it would file a separate incident report for the CRL error on 29 October; none had appeared by 11:20 GMT on 10 November. On 4 November, Chrome announced that G1 certificates issued after 16 November will not be trusted, because eMudhra had not answered questions about its key handling “in ways that convincingly prove the risk to Chrome users does not extend beyond the now known weak CA keys”. It also warned that the timeline could be brought forward if it finds further risk.
• Whether anyone used the keys. According to Google, no certificates from the six TLS intermediates were logged to CT before Chrome blocked them, and Chrome enforces CT, so Chrome users were protected. Since then, others have logged 107,107 certificates signed with six of the keys, most of them proof-of-concept certificates for google.com. Clients that don’t enforce CT, which is most software outside the browser, have no such assurance. Whether anyone abused these keys between April 2025 and October 2026 is unknowable, and the honest phrasing is that no misuse has been found, not that none occurred. As Scott Helme put it: “Here, nobody had to steal anything. The key was effectively public from the day the certificate existed.”

Failure Is a Better Teacher in Public

I’d rather not file this under schadenfreude, because the way the WebPKI handles failure is one of the most useful things about it. It has an unusual rule: CAs are expected to fail in public. Every incident gets a public bug, a published incident report, and questions from anyone who cares to ask them. It’s uncomfortable by design. In my review of Rising Strong, I quoted Brené Brown’s definition of vulnerability as “having the courage to show up and be seen when we have no control over the outcome”. A public incident bug is that idea, written into policy.

And it works for the people outside the organisation as much as for those inside it. Within days of this disclosure, participants on Mozilla’s security policy mailing list were asking whether other CAs could be affected, CERT-In was advising that “independent verification of generated key parameters” should form part of every CA’s key generation process, and people were asking HSM vendors hard questions about how a certified device could produce a key of 4. All of that depends on failures being reported in full, which is why the 2025 incident report, which described a key configuration problem without mentioning that two key pairs existed, matters more in the long run than the original mistake.

Trust works the same way inside your organisation. In my review of Daring Greatly, I wrote about Brown’s marble jar: trust that is accumulated one small, visible act at a time, and spent far faster than it is earned.

Trust is a product of vulnerability that grows over time and requires work, attention, and full engagement. Trust isn’t a grand gesture—it’s a growing marble collection.

Root programmes fill a CA’s jar slowly, through years of audits and incident reports handled well. eMudhra’s week shows how quickly it empties. The 2025 mismatch was the moment eMudhra’s own people held the information that could have stopped all of this. Whether anyone felt able to say so, we don’t know, and it isn’t ours to judge. But it is worth asking of your own team. When an engineer spots something that doesn’t add up, do they feel safe saying “this doesn’t make sense, and I think we should stop”? Or does the silence tell you everything is fine?

What to Check Outside the Browser

Browsers are largely sorted. The exposure that remains is everything else. Over the years I’ve maintained OwaspHeaders.Core, an open source security headers library with over two million downloads, and its default configuration sends a Strict-Transport-Security header, which tells browsers to only ever connect to your site over HTTPS. This incident is a useful reminder of what that header can’t do. HTTPS guarantees an encrypted connection to whoever holds a trusted certificate. If an attacker can mint a trusted certificate, HTTPS will cheerfully deliver your users to them. The transport layer is only as trustworthy as the trust store underneath it.

This Week

• ✅ Test your clients. Dennis Jackson’s test site includes test hosts served from the affected chains, including chains that aren’t logged to CT. If a client connects successfully, it still trusts the compromised intermediates. If you’re behind a proxy that inspects TLS traffic, a successful connection means the proxy still trusts them, and so does everything behind it.
• ✅ Update trust stores everywhere. Going by the patch list on Jackson’s site, that means operating system ca-certificates packages, language runtimes (Go 1.27.3 or 1.26.10, Node.js 26.12.1, 24.22.1 or 22.23.4, Python 3.15.1, 3.14.9 or 3.13.17, and current Oracle JDK, Bun, Deno and Electron builds), certifi and its equivalents, and container base images. Rebuild images; don’t just restart them.
• ✅ Update macOS developer machines. On macOS, curl, git, python3, ruby, perl and openssl check certificates against /etc/ssl/cert.pem, which Apple’s block in Safari and its frameworks doesn’t cover. Apple’s updated guidance says that macOS 27.2.1, 26.7.3 and 15.8.3 fix this: they block the compromised certificates in those tools, and remove the affected roots from /etc/ssl/cert.pem along with three other eMudhra roots, including G1. Update, then confirm the fix with the checks on Jackson’s test site, which now include one for git. Apple’s steps for editing the file by hand are only needed on Macs that can’t be updated, and Jackson says manual edits made earlier are safe to leave in place. Apple warns that tools which use only this file might not be able to verify some websites whose certificates chain to the removed roots; those include G1, the root InCommon’s institutions moved to as a stopgap.
• ✅ Watch for stragglers. On 10 November, Bottlerocket, certbot, containerd, Godot, LibreOffice, OpenHarmony, OpenJDK and TrueNAS were still listed as pending on Jackson’s site.
• ✅ Clean up private configuration. Remove emSign ECC Root CA - G3 and the eight intermediates from any private trust store, mutual TLS (mTLS) configuration or certificate pinning list.
• ✅ Replace affected certificates. If any of your certificates chain to emSign ECC Root CA - G3, replace them now; Firefox and Apple devices already reject them, and Chrome’s removal was due on 27 October. If yours were reissued from eMudhra’s G1 root, move them to another CA too. Chrome and Firefox won’t trust G1 certificates issued after 16 November, so any renewal after that date has to come from someone else, and eMudhra says Apple devices will reject every G1 certificate from 30 November. While you’re there, check your CAA records; if they only permit one CA, a forced move will fail at issuance.

ℹ️ Note

You can’t update a trust store you don’t know exists. If you’ve never inventoried the certificates and trust bundles inside your own software, the same discipline that produces a software bill of materials applies here.

The Longer-Term Lessons

• ✅ Treat entropy as a supply chain dependency. Weak keys are invisible to inspection, so ask how key material is generated and verified, not only where it’s stored.
• ✅ Verify outputs, not only process. Add automated sanity checks to signing ceremonies, CI signing pipelines and secrets tooling: key size, non-trivial values, uniqueness, and a check that the key you’re using is the one you think it is. The same thinking sits behind build attestations.
• ✅ Treat anomalies as incidents. The 2025 CRL mismatch was eMudhra’s chance to find this, and it was resolved in the wrong direction.
• ✅ Monitor Certificate Transparency. CT is how Chrome could say no forged certificate worked against its users. It detects misissued certificates after the fact, so watch the logs for certificates issued for your own domains.
• ✅ Make CA migration routine. eMudhra estimated that around 97% of the affected certificates were issued through the Automatic Certificate Management Environment (ACME) protocol, which is what makes moving tens of thousands of certificates in ten days possible at all. Even so, ACME clients don’t renew early on their own unless they support ACME Renewal Information (ARI), and switching key types needs configuration changes. Keep at least two CA relationships, and automate issuance end to end. The same capability will be needed for the move to post-quantum cryptography; treat this as a rehearsal.
• ✅ Don’t casually roll your own CA. Private PKI is legitimate, and often the right choice for internal services and mTLS. But a professional CA with HSMs and audits still shipped a key of 4. Use managed private CA services or well-trodden tooling, and constrain internal CAs with name constraints and short lifetimes.

Questions to Ask Your Vendors

If you buy certificates, or buy products that embed trust stores, these are worth asking this quarter:

• ✅ How are your keys generated, and is the generation independently verified?
• ✅ Do you maintain a second CA hierarchy for failover?
• ✅ How quickly can you reissue our entire certificate estate?
• ✅ Which trust stores do your products embed, and how are they updated?
• ✅ Do your clients check revocation?

Wrapping Up

The root programmes protected browser users within hours of the report, and Chrome’s removal of the affected root was due to complete on 27 October. G1, the stopgap root InCommon’s institutions moved to, now has an end date too. eMudhra’s key of 4 came from an ordinary mistake that nothing in the system was built to catch, and the browsers caught it anyway, seventeen months late. The question for your organisation is everything that isn’t a browser: the pipelines, containers, scripts, appliances and supplier products that trust whatever they shipped with, and the vendors whose commercial priorities decide how much care goes into the seal.

If your business commissions software rather than running it, I’ve written a follow-up on who is responsible for that work, and the questions to ask your supplier.

If you’d like help working out where your organisation’s trust actually lives, from trust store inventories to CA redundancy and the questions to put to your suppliers, I’d like to talk it through.

Sources and Archived Copies

Because this is a live incident, several of the sources quoted above may be updated after publication. These are the versions this post was written against, captured by the Internet Archive’s Wayback Machine on 23 October 2026, or on 28 or 29 October or 1, 2, 3 or 9 November 2026 for the sources first cited in later updates.