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.

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 check before Chrome removes the affected root on Tuesday 27 October.

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 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.
• 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: Apple begins blocking. eMudhra announces it will leave the global TLS certificate business.
• 27 October (PDT): Chrome’s removal of emSign ECC Root CA - G3 is 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, and because the key labels were similar, the weak keys were used by mistake to create the certificate signing requests. eMudhra acknowledges human error at multiple steps, and says it has not yet confirmed the exact root cause.

The best label for this today is a test artefact promoted to production by mistake. 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.

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?

My suspicion is 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.

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.”

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.
• 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 its latest update offers Sectigo certificates. The Chrome Root Program has formally asked which it is.
• 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 has asked whether multiple key pairs exist for G1 or any other root, and Chrome says it is still reviewing eMudhra’s remaining certificates.
• Whether anyone used the keys. No forged certificates have been found in CT logs, and Chrome enforces CT, so Chrome users were protected. 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 Do Before 27 October

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.
• ✅ 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 Java, Bun, Deno and Electron builds), certifi and its equivalents, and container base images. Rebuild images; don’t just restart them.
• ✅ Check macOS developer machines. At the time of writing, Jackson’s site reports that macOS’s /etc/ssl/cert.pem, which curl, git, Python, Perl, Ruby and OpenSSL use, has not been updated.
• ✅ Watch for stragglers. RHEL 7 and Bottlerocket 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 before Chrome’s removal lands on 27 October. 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 by Tuesday the affected root will be gone from Chrome as well. 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 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.