When the CA Key Was 4: What the eMudhra CA Key Compromise Teaches About CA Agility

A certificate authority just had eight of its CA private keys compromised, and nobody hacked anything. The keys were broken from the day they were created. One of them was the number 4.

On October 17, 2026, a researcher reported that eight eMudhra intermediate CAs, six for TLS and two for code signing, were protected by P-384 private keys that were almost entirely zeros. Each key was 47 zero bytes followed by one small byte, which means every key had at most 8 bits of real secrecy. Anyone holding the public certificate could recover the private key in under a second on a laptop. Those weak keys sat inside a publicly trusted chain for roughly 17 months.

Browsers shut the door within hours. The rest of the internet is still working out where the door even is. This post walks through what happened, why the fix landed unevenly, and what the incident says about CA agility, crypto-agility, and certificate agility for any team that runs on certificates, which is every team.

Key takeaways

• Eight eMudhra intermediate CAs (six TLS, two code signing) used P-384 private keys smaller than 256, so the keys could be recovered from the public certificates in under a second.
• eMudhra’s preliminary explanation is a key ceremony script bug that created a second, weak key pair on the HSM, plus human error caused by similar key labels. There was no breach and no stolen key.
• Chrome and Firefox blocked the intermediates on October 17, Apple followed on October 19, and Microsoft on October 20. Mozilla removed the emSign ECC Root CA – G3 root from NSS.
• Many non-browser clients, including curl, Python, and Node with default settings, still accepted a forged certificate in testing because they do not check revocation or Certificate Transparency by default.
• The incident is a live test of three capabilities: replacing a CA quickly (CA agility), changing algorithms and keys safely (crypto-agility), and reissuing certificates at scale (certificate agility).

What happened in the eMudhra CA key compromise

The eMudhra CA key compromise happened because the private keys behind eight intermediate CA certificates were generated with almost no randomness, not because an attacker got in. A P-384 private key is supposed to be a random 384-bit number. Mozilla’s analysis on Bugzilla incident 2083449 found that the affected keys were tiny integers below 256. With at most 255 candidates, recovering a key is a matter of multiplying the curve’s base point by small numbers until the result matches the public key in the certificate.

The affected CAs, all created in April 2025 and cross-signed by Sectigo’s AAA Certificate Services root in May 2025, were:

• TLS: EM DV TLS CA – G3B and G3C, EM OV TLS CA – G3B and G3C, EM EV TLS CA – G3B and G3C
• Code signing: EM OV CS CA – G3B and G3C

Because each key appears in two certificates (one issued by eMudhra’s root and one by Sectigo’s cross-sign), 16 CA certificates were affected in total. The certificates themselves were structurally valid. Nothing in their format or extensions looked wrong, which is why linting would not have caught the problem. The only test that works is checking the key itself.

Timeline of the response

Date (UTC)	Event
April 30, 2025	eMudhra key generation ceremony creates the eight ECC intermediate keys
May 2025	Sectigo cross-signs the eight intermediates under AAA Certificate Services
October 17, 2026	Researcher reports the issue to root programs. Chrome pushes a CRLSet block at 19:45. Mozilla completes a OneCRL block at 22:59
October 18, 2026	eMudhra revokes all eight intermediates with reason cACompromise
October 19, 2026	Downstream trust stores notified. Apple blocks the certificates on its platforms
October 20, 2026	Microsoft blocks the certificates. Mozilla announces publicly and ships an NSS update removing emSign ECC Root CA – G3. Chrome confirms the root will be removed in Chrome Root Store version 43

Sectigo has since revoked its cross-signed certificates. eMudhra has stopped issuing from all G3 intermediates and plans to move subscribers to its G1 chains, so if you hold certificates from the affected ECC intermediates, plan to reissue them.

Go also shipped patched releases (1.27.3 and 1.26.10), and Linux distributions, Node, and other CA bundle maintainers have been pushing updates since. Sources: the Mozilla dev-security-policy announcement, the public disclosure site, and Scott Helme’s full technical breakdown.

How an HSM-backed key ceremony ends up with an 8-bit key

A FIPS-validated HSM protects the keys it is told to use. It does not decide which key your ceremony script picks. According to eMudhra’s preliminary account on the Bugzilla ticket, the original ECC keys were generated on the HSM as expected. An approved deviation for a wrap and unwrap test was then introduced, and a flaw in the ceremony code created a second, weak key pair on the same HSM. The two sets of keys had similar labels, so the weak ones were picked to build the certificate signing requests. Those requests were signed by eMudhra’s root and sent to Sectigo for cross-signing.

eMudhra states that its Utimaco HSMs are FIPS 140-2 Level 3 compliant and were not at fault, and that its RSA issuers followed a different path and are unaffected. Mozilla had not independently verified those claims at the time of writing. eMudhra has said human error occurred at multiple steps and that it will re-verify every key ceremony it has performed.

The lesson here is uncomfortable for every PKI team, including ones with excellent hardware. Ceremony scripts, witnesses, and checklists usually verify that a step happened. Few verify that the output is sound. A key ceremony that records “key generated, CSR created, CSR signed” would have passed this test with every box ticked.

There was also an earlier signal. In June 2025, CRLs for the same six TLS intermediates were flagged for invalid signatures (Bugzilla incident 1970728) and eMudhra closed the incident by publishing new CRLs. According to eMudhra’s account in the new ticket, the original CRLs were signed with the correct HSM keys, which did not match the weak public keys in the certificates, and the fix re-signed them with the flawed keys. The incident was treated as a configuration problem, and nobody checked the keys themselves.

Browsers got a fast fix. Everything else got a long tail.

Browsers were protected quickly because they enforce Certificate Transparency (CT) and ship their own revocation channels. Most other software does neither. That gap is the most important part of this story for enterprise teams.

Chrome, Safari, Firefox, and Edge require TLS certificates to appear in public CT logs. According to Chrome’s statement in the Mozilla thread, no TLS certificates from these intermediates had been logged to CT, so a forged certificate could not have been trusted by default in Chrome. On top of that, Chrome’s CRLSet and Firefox’s OneCRL let each browser vendor push a block to users within hours. If CT is new to you, our explainer on what Certificate Transparency is and how SCTs work covers the mechanics.

Outside the browser, the picture is different. In Scott Helme’s testing, a forged certificate for a test hostname, issued under one of the affected intermediates, was accepted by:

• curl with default settings, which reported “SSL certificate verify ok”
• Python, which completed the TLS handshake
• Node, which reported the connection as authorized

This held on every Linux and macOS machine tested. On Windows, CryptoAPI accepted the chain unless revocation checking was turned on, and even then only one of two revocation routes flagged it. The disclosure site adds that macOS’s /etc/ssl/cert.pem bundle was not updated, so built-in tools like curl, git, and python3 on a Mac can still trust the affected roots after Apple’s platform block.

The reason is simple. Most non-browser clients trust a CA bundle file on disk, do not check revocation by default, and do not check CT at all. A revocation that browsers see in hours reaches these clients only when someone updates the bundle, rebuilds the container image, and redeploys. For devices with frozen trust stores, such as IoT, embedded, and operational technology firmware, that may never happen. Per Scott Helme’s analysis, the affected intermediate certificates remain valid until July 2039.

For most enterprises, that is where the exposure sits: CI/CD pipelines, curl-based installers, server-to-server API clients, service mesh sidecars, and Windows code-signing verification. Those systems move money, data, and software. They are also the ones nobody thinks of as “a browser.”

Three kinds of agility this incident just tested

The eMudhra incident tests three related capabilities at once. Each one answers a different question about how fast an organization can recover when trust breaks.

Capability	What it means	What eMudhra tested	What failure looks like
CA agility	The ability to stop trusting a CA, or stop buying from one, and move to another without an outage	Every relying party now has to remove emSign ECC Root CA – G3 and the eight intermediates from its trust stores. Every subscriber has to move to a different issuing hierarchy	Nobody knows which trust stores exist, which certificates chain to the bad CA, or which applications hardcode a CA
Crypto-agility	The ability to change algorithms, key sizes, and key generation methods across systems through policy rather than rewrites	The keys were ECC P-384 on paper and roughly 8-bit in practice. Algorithm choice was correct; key generation was not validated	Policy checks the algorithm name but never the key quality, and nobody can enumerate where a given key type is in use
Certificate agility	The ability to discover, reissue, and redeploy certificates at scale, on demand, with automation	eMudhra estimates about 30,000 customer certificates need to migrate to a different hierarchy	Certificates live in spreadsheets, renewal depends on tickets and calendar reminders, and a forced reissue becomes a multi-week fire drill

One detail from the Bugzilla ticket deserves more attention than it is getting. eMudhra reports that about 97% of those roughly 30,000 certificates were issued through ACME. Certificates issued through automated enrollment can be reissued from a new CA by changing an endpoint and letting automation run. The other 3% are where the late nights happen. In practice, certificate agility decides whether a CA incident costs you an afternoon or a quarter.

These are also the same muscles that the post-quantum transition will demand. Moving from RSA and ECC to ML-DSA (FIPS 204) means changing algorithms, CA hierarchies, and certificates across the same estate, on a deadline. Our guide to crypto-agility strategy for the PQC migration covers that timeline. Teams that cannot rotate away from one bad CA this month will struggle to rotate away from an entire algorithm family later.

Three questions to ask your team this week

If any of these answers is “not sure,” that is the work to do before the next incident.

1. Do we validate key strength and entropy at every key ceremony, or do we trust the script?

Add an explicit output check to every ceremony that generates a CA key. At minimum, export the public key and confirm the algorithm, curve or modulus size, and that the key is not trivially small or a known weak value. For high-assurance hierarchies, have an independent party run the check, and record the result in the ceremony log alongside the witness signatures. If your ceremony includes test or deviation steps, list every key object on the HSM at the end and account for each one by label and fingerprint. This applies whether you run Microsoft AD CS, an open source CA, or a managed PKI.

2. Which of our clients and workloads never check revocation or CT?

Assume the answer is “most things that aren’t a browser” until you prove otherwise. Inventory where TLS clients get their trust anchors: OS bundles, certifi in Python, Node’s bundled store, Java cacerts, Go’s root handling, container base images, and appliance firmware. Then prioritize the ones that move sensitive data or verify code. For those, decide whether to enable revocation checking, pin to a curated trust store or specific trust anchors, or at least set a maximum time between trust store updates.

3. If a CA in our trust stores went bad tonight, how fast could we remove it everywhere?

Time this as a tabletop exercise. You need three answers: which certificates chain to the CA (including through cross-signs), which systems trust it, and how long it takes to reissue and redeploy everything affected. If the honest answer involves emailing application owners and waiting for replies, that is your gap.

Our take: plan for distrust as a routine event

The CA ecosystem has removed trust from CAs before. Symantec’s distrust ran from 2017 to 2018, and Chrome announced in 2024 that it would stop trusting new certificates from Entrust’s roots. eMudhra is different only in how fast it happened and how simple the root cause was. Our view is that enterprises should treat CA distrust the way they treat a critical CVE: not likely on any given day, but certain over a few years, and something you rehearse for.

That has practical consequences. Single-CA dependency is a risk, so keep at least one tested alternate issuer for public TLS and know how to switch. Manual renewals are a risk too, and not only because of the CA/Browser Forum’s move to 47-day certificates by March 2029 (with the maximum already at 200 days since March 2026 and dropping to 100 days in March 2027, as covered in our 47-day certificate validity guide). The same automation that handles shorter lifetimes is what makes a forced migration survivable.

We would also push back on one comforting reading of this incident: that it was “only” a CA’s problem because browsers fixed it. Browsers protect browsers. Your API clients, build systems, and devices are protected by whatever you have put in place, and in most organizations that is less than people assume.

Where CertSecure Manager fits

When a CA goes bad, the first question is always “where are we exposed?” and the second is “how fast can we get off it?” CertSecure Manager, Encryption Consulting’s certificate lifecycle management platform, is built to answer both.

• CertSecure Manager continuously discovers certificates across Microsoft, public, and private CAs into one inventory, and its full trust chain visualization shows which intermediates and roots each certificate depends on, so filtering to a compromised issuer takes minutes instead of a spreadsheet hunt.
• The Certificate Risk Profile scores every certificate in the inventory, weighing key length, deprecated curves, signature algorithms such as SHA-1, and validity period, so risky certificates surface automatically. It complements the ceremony-level key check above rather than replacing it.
• Bulk revocation and bulk ownership transfer handle many certificates in one operation, and the platform supports rapid reissuance during a CA compromise.
• ACME, SCEP, EST, and REST APIs, plus renewal agents for F5 BIG-IP, Apache, Nginx, IIS, and Tomcat, let you point enrollment at a different CA and let zero-touch renewal do the redeployment.
• Organization-wide enrollment policies restrict allowed algorithms and enforce FIPS requirements, with multi-level approval workflows for sensitive certificate types.

CertSecure Manager runs on-premises, in the cloud, or as SaaS, and it integrates with ServiceNow, HashiCorp Vault, Azure Key Vault, Ansible, and SIEM tools like Splunk and Datadog. The CertSecure Manager 3.3 release covers the risk profile, chain visualization, and bulk operations in detail.

If the third question above made you uneasy, that is exactly the scenario CertSecure Manager is designed for. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 compliant, and our PKI team can also review your key ceremony procedures and CA hierarchy design alongside the platform rollout.

Conclusion

The eMudhra CA key compromise did not need an attacker. It needed one script bug, two similar key labels, and a ceremony that checked that steps happened rather than whether the output was sound. Browsers recovered in hours because they invested years in CT, CRLSets, and OneCRL. Most enterprise software has no equivalent, and a long tail of devices may trust these CAs until 2039.

You cannot control whether a CA in your trust store fails. You can control how long it takes you to find out where you depend on it and to move off it. That speed is what CA agility, crypto-agility, and certificate agility actually measure, and the teams that can answer the three questions above with confidence are the ones who will treat the next incident as a routine change rather than a crisis.

See how fast you could move off a compromised CA. Book a CertSecure Manager demo or start a 15-day free trial, and ask our team to walk you through a CA replacement scenario end to end.

Not ready for a call? Paste any certificate into our free OpenSSL CSR and Certificate Decoder to check its issuer and key details in seconds.

Frequently asked questions

What happened with eMudhra’s CA keys?

In October 2026, a researcher found that eight eMudhra intermediate CAs, six for TLS and two for code signing, used P-384 private keys smaller than 256. Anyone could recover the keys from the public certificates in under a second. eMudhra attributes the issue to a key ceremony script bug and human error, not a breach. Browsers, Apple, and Microsoft blocked the intermediates within three days.

Am I affected by the eMudhra CA compromise if I don’t use eMudhra certificates?

You may be. The risk is not only to eMudhra customers. Any client that trusts the emSign ECC Root CA – G3 root or Sectigo’s cross-signed versions of the intermediates could accept a forged certificate. Browsers are protected, but curl, Python, Node, Java, and devices with outdated CA bundles may still trust the chain until their trust stores are updated.

What is CA agility?

CA agility is an organization’s ability to stop trusting a certificate authority, or stop using one as an issuer, and move to another without outages. It depends on knowing which certificates chain to each CA, which systems trust each root, and having automated enrollment that can be pointed at a new CA. Without it, a CA distrust event becomes a manual, multi-week migration.

How is crypto-agility different from certificate agility?

Crypto-agility is the ability to change cryptographic algorithms, key sizes, and key generation methods through policy, for example moving from ECC to ML-DSA. Certificate agility is the ability to discover, reissue, and redeploy certificates at scale. Crypto-agility decides what you can change to, and certificate agility decides how fast you can roll that change out across every system.

Why did curl, Python, and Node accept a certificate that browsers blocked?

Browsers enforce Certificate Transparency and receive revocation updates through channels like Chrome’s CRLSet and Firefox’s OneCRL. Most non-browser clients trust a CA bundle on disk, do not check revocation by default, and do not check CT. Those clients stop trusting a bad CA only when their CA bundle is updated and the application or container is rebuilt and redeployed.