Compromised eMudhra Intermediate Certificates

to dev-secur...@mozilla.org

Dennis

to Dennis Jackson, dev-secur...@mozilla.org

Is there any information / details on the nature of the compromise available and whether it might impact / other CA’s might be vulnerable as well?

to dev-secur...@mozilla.org, Arvid Vermote, Dennis Jackson

Arvid's question is essential. And: Which communication channels and contact points shall the CAs address?

to dev-secur...@mozilla.org, Adrian Müller, Arvid Vermote, Dennis Jackson

to Dennis Jackson, dev-secur...@mozilla.org, Arvid Vermote

--

to Dennis Jackson, dev-secur...@mozilla.org, Adrian Müller, Arvid Vermote

All,

To share an update from the Chrome Root Program on our response to this incident:

On Saturday, October 17, 2026, at 18:05 UTC, the Chrome Root Program received a report from a security researcher regarding the compromise of private keys associated with eight eMudhra subordinate CA certificates (the same mentioned in Mozilla’s message).

At 19:45 UTC, Chrome completed corroborating the findings and landed a CRLSet update blocking the Subject Public Key Info (SPKI) hashes of all six affected TLS-issuing intermediate CAs. Because this CRLSet update blocks by SPKI, Chrome users were immediately protected against both the eMudhra-issued intermediate certificates and the Sectigo-issued cross-certificates sharing those keys, without requiring a browser update or restart. The two compromised Code Signing CAs did not require blocking, as Chrome's certificate verification logic does not permit building a TLS path through intermediate CAs constrained to the Code Signing Extended Key Usage. 

By default, Chrome enforces Certificate Transparency (CT) for all connections relying upon roots in the Chrome Root Store, rejecting any TLS certificate that has not been logged in accordance with our policy. Because no TLS certificates chaining to these six intermediate CAs were logged to CT prior to our CRLSet block on October 17, no fraudulent certificates issued by these CAs could have been trusted by default in Chrome or other CT-enforcing browsers.

Following the initial block, we evaluated all other CA certificates in the Chrome Root Store trust boundary and found no other instances of this failure mode. We are also working with CT log software maintainers and log operators to reject certificates chaining to these compromised intermediate CAs going forward to prevent risk to the CT ecosystem.

We will soon release an update to the Chrome Root Store (Version 43) that removes the upstream eMudhra root certificate that signed these intermediates. Although this change is not necessary to protect Chrome users, who have been protected via CRLSet since October 17, it helps protect downstream consumers of the Chrome Root Store that do not consume CRLSet. The corresponding Sectigo root responsible for the cross-certificates was removed from the Chrome Root Store in April 2025.

Inclusion in the Chrome Root Store requires that a CA Owner continuously demonstrate the technical competence and operational rigor necessary to protect Chrome users. Due to the seriousness of this incident, the Chrome Root Program is conducting a thorough evaluation regarding the status of eMudhra’s remaining CA certificate to ensure these standards continue to be met. We will share further updates as our review progresses.

- Chrome Root Program Team

to dev-secur...@mozilla.org, Chrome Root Program, dev-secur...@mozilla.org, Adrian Müller, Arvid Vermote, Dennis Jackson

I think it's worth noting that this compromise is much worse than the private keys simply being stolen by a researcher. They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained.

to Ian Carroll, dev-secur...@mozilla.org, Chrome Root Program

Please forgive my ignorance... I am having trouble following the
statement. What is the "they" with a single-byte key?

Jeff

to dev-secur...@mozilla.org

We have de-restricted Bug 2083449 which contains the initial incident report. 

to nolo...@gmail.com, dev-secur...@mozilla.org

Quite literally: For the private keys of the compromised certificates,
one of the factors of the moduli is always < 256 (hence single-byte).

They can be broken without any serious computation - literally trying a
few divisions using the "bc" command line calculator would be enough.

The factors have been posted on the fediverse but I don't know if a link
to them would be appreciated on this mailing list, so I am holding off
on linking them.

Li

to dev-secur...@mozilla.org

I'm aware of at least one HSM integration library that utilizes "reference" faux private keys -- the goal being to provide a way for software that supports (for example) PKCS12, but in very limited fashion -- to use a PKCS12 driver from the manufacturer to perform HSM isolated operations under the direction of software that can't easily pass in things like...which partition & key to reference in a given operation.  Those HSMs can spit out a fake key which parses for the form and nature of a private key and which the HSM vendors' software will dereference for a signing or encryption operation.  Is there any chance that's what we're looking at?  That somehow there was a failure of such a library or interface and the result was instead of aborting the operation to actually perform the operation over the faux key?

to li-...@riseup.net, dev-secur...@mozilla.org

Thanks. I guess that's why I was having so much trouble processing
the statement.

From <https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c10>:

Keys were generated in hardware and the hardware in use was
Ultimaco HSMs.

And from <https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11>:

The hardware used for each of the issuers is in the attached file.
These HSMs are FIPS 140-2 Level 3 compliant.

It is hard to believe a FIPS 140-2 module failed like that 6 or 8
times. But I don't quite follow the explanation of the "weaker keys"
in Comment 11, given the HSM was FIPS 140-2.

Jeff

to li-...@riseup.net, nolo...@gmail.com, dev-secur...@mozilla.org

Jeffrey Walton <nolo...@gmail.com> writes:

>given the HSM was FIPS 140-2.

FIPS 140 isn't any guarantee of security, and may actually make you less
secure (think JEnt in software implementations). In addition a whole pile of
things you'd never expect, like an OLPC (via its Marvell PXA61x), are FIPS-140
compliant. Some others are routers, firewalls (which one CA actually used as
a, cough, "HSM" a few years ago, ignoring the long string of vulnerabilities
in the certified-secure firewall), disk drives, digital cinema projectors,
franking machines, a whole array of USB keys, satellite modems, a medication
monitor, a barcode reader, Java cards, and a handful of tape drives. So you
could replace the above with "given the HSM was a medication monitor" or
"given the HSM was an OLPC".

Not saying that this was the case here, merely that FIPS 140 is more an
indication of how much money you're prepared to burn to get government sales,
not a guarantee of security.

Peter.

to leeyc0, dev-secur...@mozilla.org, li-...@riseup.net, nolo...@gmail.com

leeyc0 <lee...@gmail.com> writes:

>However eMudhra incident proved that improper operations can cause extremely
>weak key being generated. Is there any way inspected the (expected) key
>entropy generated by HSM?

It has been done a few times before, e.g. by Švenda et al in "The Million-Key
Question - Investigating the Origins of RSA Public Keys",
https://www.fi.muni.cz/reports/files/2016/FIMU-RS-2016-03.pdf

Peter.

to dev-secur...@mozilla.org

I've had more than a few emails asking on how this was discovered. The simple answer is: https://github.com/google/paranoid_crypto

Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...

I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.

So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far.

- Wayne

to dev-secur...@mozilla.org, Peter Gutmann, dev-secur...@mozilla.org, li-...@riseup.net, nolo...@gmail.com

I have questions about keys generated by HSM. Since the purpose of HSM is sealing the key and not to be exposed to outside, we cannot directly inspecting the key generated by HSM to ensure the key is having enough entropy. However eMudhra incident proved that improper operations can cause extremely weak key being generated. Is there any way inspected the (expected) key entropy generated by HSM? Without such mechanism I am afraid similar incidents may occur again.

to dev-secur...@mozilla.org, Matthew Hardeman

I think that’s what happened. The actual key was generated in the HSM, and a reference key file was written to disk. The CSR was then generated using the reference key file as if it were a real key. The public key was derived from the reference value (“4”) as its private scalar, and the CSR was self-signed with it. The issuing CAs then certified that “reference” public key.

The incident report mentions that CRLs signed by the CAs failed to validate against their certificates. That’s consistent with this scenario. The CRLs were presumably signed by the real HSM-resident keys, while the certificates contain the public key derived from the reference value, so the CRL signatures can’t validate against them.

Thanks,
Corey

to Corey Bonnell, dev-secur...@mozilla.org, Matthew Hardeman

to Corey Bonnell, dev-secur...@mozilla.org, Matthew Hardeman

to dev-secur...@mozilla.org, Bas Westerbaan, dev-secur...@mozilla.org, Matthew Hardeman, Corey Bonnell

The incident report highlights that no end-entity certificates (and therefore no OCSP responses) were signed using these CAs. The only artifacts signed were CRLs, and those failed signature validation using the CA certificates. That suggests the signing flow used the real HSM key correctly, and the mistake was limited to CSR generation.

Thanks,
Corey

Dennis Jackson

unread,

to Daniel Lenski, dev-secur...@mozilla.org, li-...@riseup.net, nolo...@gmail.com, leeyc0

Daniel Lenski <dle...@gmail.com> writes:

>And lastly, it is trivial to distinguish RSA SSH keys that were generated by
>older versions of OpenSSH and PuTTY, due to their non-standard public
>exponents.

The reason for this is:

/* OpenSSH versions up to 5.4 (released in 2010) hardcoded e = 35,
which is both a suboptimal exponent (it's less efficient that a
safer value like 257 or F4) and non-prime. The reason for this
was that the original SSH used an e relatively prime to
(p-1)(q-1), choosing odd (in both senses of the word)
numbers > 31. 33 or 35 probably ended up being chosen frequently
so it was hardcoded into OpenSSH for cargo-cult reasons, finally
being fixed after more than a decade to use F4. In order to use
pre-5.4 OpenSSH keys that use this odd value we make a special-
case exception for SSH use */

There's also "41 (another weird value used by GPG until mid-2006)".

Peter.

to Corey Bonnell, dev-secur...@mozilla.org, Matthew Hardeman

to Corey Bonnell, dev-secur...@mozilla.org

Shockingly, they did in fact sign CRLs with the weak private keys: https://bugzilla.mozilla.org/show_bug.cgi?id=1970728#c2

Regards,
Andrew

to dev-secur...@mozilla.org, Peter Gutmann, li-...@riseup.net, nolo...@gmail.com, leeyc0

Maybe I need to be make it clear. I am not asking about systematic bias, but how to detect such enormous mistake in HSM.

We are not supposed to have direct access to the private key itself.

to dev-secur...@mozilla.org, Peter Gutmann, li-...@riseup.net, nolo...@gmail.com, leeyc0

In 2024, I surveyed millions of TLS and SSH public keys, developing a somewhat novel scanning methodology to find potentially forgotten, broken, or obsolete keys that remain live, and which are not captured by zgrab2, Censys, or Shodan.

Despite not using sophisticated classification methods like Švenda et al, I found several cases where key material is so glaringly idiosyncratic that it must identify a common bespoke codebase used to generate the key. For example, hundreds of DNSKEYS where the RSA *exponent* contains what I can best describe as a typographical error:

"We observed exactly 93 distinct RSA public keys with a public exponent of 65337; this value appears to result from a typographical error or misunderstanding about the decimal representation of the common public exponent of 65537 (= 2^16 + 1). All of these keys were used as DNSKEYs; the vast majority of them are associated with .fi domain names (Finland), but they also include domain names of one US government agency. Because of the extreme rarity of this RSA public exponent, and the fact that it only appears in geographically-clustered DNSKEYs, there is a strong probability that some common key-generating codebase is shared by the DNSSEC infrastructure for these domains."

And lastly, it is trivial to distinguish RSA SSH keys that were generated by older versions of OpenSSH and PuTTY, due to their non-standard public exponents. If anyone discovers a weakness in the keygen entropy source(s) of pre-2010 OpenSSH or pre-2022 PuTTY, there are hundreds of thousands of easy-to-find SSH server and user keys to target for attacks. 

to dev-secur...@mozilla.org, Daniel Lenski, Peter Gutmann, li-...@riseup.net, nolo...@gmail.com, leeyc0

It now gives October 17 for notification and October 18 for revocation, instead of October 18 and October 19. There’s no note on the page that it was changed.

Before: Wayback Machine
After: Certificate security incident

Parikshith

to dev-secur...@mozilla.org, Rufus Buschart, dev-secur...@mozilla.org, Matthew Hardeman, Corey Bonnell

I agree that key attestation should be required, and the CSR attestation draft will help make that possible once it is published as an RFC.

However, the CSR attestation draft only defines how attestation evidence is conveyed in a CSR. It does not say what format that evidence should be in, so it does not solve the problem of each HSM vendor using its own proprietary format (for example: https://pkic.org/wg/cm/remote-key-attestation/).

Another IETF draft, Evidence Encoding for Hardware Security Modules (https://datatracker.ietf.org/doc/draft-ietf-rats-pkix-key-attestation/), addresses this by defining a standard, vendor-neutral attestation format for PKCS #11-style HSMs. It covers claims such as PKCS #11 key attributes (CKA_EXTRACTABLE, CKA_NEVER_EXTRACTABLE, etc.) and FIPS mode status. This may be especially helpful for auditors, or for CA organizations cross-certifying another organization’s key.

Thanks,
Corey

to Corey Bonnell, dev-secur...@mozilla.org, Matthew Hardeman

Corey Bonnell <corey.j...@gmail.com> writes:

>The public key was derived from the reference value (“4”) as its private
>scalar, and the CSR was self-signed with it. The issuing CAs then certified
>that “reference” public key.

A slight aside, this key is still secure against attack from current quantum
"computers", so there is that at least.

Peter.

to dev-secur...@mozilla.org

This will not convince Peter, and is definitely off-topic (so if anyone else—not me—wants to discuss it further please change the Subject line), but I think it's important for the folks reading this list to get perspective on this funny trope.

to dev-secur...@mozilla.org

A question for the Mozilla and Chrome root programs (also for others, but I'm mostly curious of the two active root programs):

Wayne has said the weak keys were found by running the open-source paranoid_crypto tool, out of the box, against the CCADB corpus, and Chrome has since confirmed that a review of its trust boundary found no other instances. These intermediates were disclosed in CCADB for roughly 18 months before that scan was run by a community member.

Can each program explain why an automated weak-key check was not already part of intermediate disclosure or ongoing monitoring? Do you plan to add one, for example a scan of every CA certificate at CCADB disclosure and again at regular intervals?

to dev-secur...@mozilla.org, Peter Gutmann, Matthew Hardeman, Corey Bonnell

Has anyone verified if eMudhra used these scalar-below-256 keys for the entire 16-month period mentioned in reports?

to dev-secur...@mozilla.org, Amir Omidi (aaomidi)

Google's paranoid_crypto repository was archived on August 19, 2026.

https://github.com/google/paranoid_crypto

On October 21, Wayne confirmed that he had identified the weak eMudhra CA keys by running the tool against the CCADB certificate corpus using its default configuration.

Given this demonstrated application to publicly trusted CA certificates, would Google consider unarchiving the repository and resuming active maintenance?

Has the Chrome Root Program incorporated these checks into its monitoring infrastructure, or is an actively maintained alternative available?

to dev-secur...@mozilla.org, Jacob Durham, Amir Omidi (aaomidi)

I have a purely technical question and hope to get discussion:

Aside from blocklist mechanisms, are there other computation-only methods to quickly validate weak-entropy RSA and EC keys based on their public keys?

to Arabella Barks, dev-secur...@mozilla.org, Jacob Durham, Amir Omidi (aaomidi)

There are unlimited ways to generate "weak entropy" keys.
The question can, therefore, not be reasonably answered in a generic
way.

However, in the recent case, we are talking about a very specific type
of "weak entropy": a private key that is a very small scalar number.

For elliptic curve algorithms, this can be algorithmically detected by
the Baby Step Giant Step algorithm (which is what paranoid-crypto does,
the tool that detected it) or by Pollard's Lambda, also known as
Pollard's Kangoroo.

For RSA, there's a similar vulnerability with small private exponents.
However, it's relatively rare, as a small private exponent leads to a
large public exponent, which is very unusual. If you see large public
exponents you should assume something is wrong. (It's pretty much
standard to have a public exponent of e=65537. My recommendation is to
simply not accept keys with e!=65537, that prevents this possible issue
and some other RSA weaknesses entirely.)

An efficient algorithm to detect such keys is known as Wiener's attack.
(My own tool badkeys contains an implementation.)
I've recently seen such small private exponent RSA keys (more precisely:
confused exponent, as the *private* exponent was d=65537) in the Linux
version of a software called CompleteFTP that used them as SSH host
keys.

--
Hanno Böck - Independent security researcher
https://itsec.hboeck.de/
https://badkeys.info/

to Jacob Durham, dev-secur...@mozilla.org, Amir Omidi (aaomidi)

Hi Jacob,

We appreciate your interest and participation in this space.

Because you asked these questions earlier in Bugzilla, we've posted a detailed response there in hopes of keeping the discussion consolidated.

For those following along here on MDSP, our response clarifies that:

1. A Google pipeline that predates this incident (and is not specific to Chrome) evaluates certificates logged to CT against paranoid_crypto. Because neither the affected CAs nor any certificates they issued were ever logged to a CT log relied upon by Chrome, they never entered that pipeline.

2. That pipeline is being updated to also consider certificates disclosed to the CCADB as a source of input.

3. Separately, the Chrome Root Program's own recurring checks (including inclusion and cross-certificate assessments) now evaluate CA certificates disclosed to CT and the CCADB against paranoid_crypto. This extends our preexisting linting evaluations that we regularly carry out on the CAs within our root store's trust boundary - which, prior to this incident, did not include the small-scalar (BSGS) or pairwise-difference EC checks that identified these keys.

4. We will pursue adding automated weak-key pre-checks to CCADB CA certificate disclosures (see mozilla/CCADB-Tools#185).

5. Because paranoid_crypto was developed and maintained by a separate team within Google, we can't make commitments regarding the repository's status. In the meantime, its checks remain freely available, and we're encouraged to see badkeys and pkimetal already moving to strengthen existing checks in response to this incident.

We believe our Bugzilla response also addresses Amir’s questions above.

- Chrome Root Program Team

to dev-secur...@mozilla.org, Chrome Root Program, dev-secur...@mozilla.org, Amir Omidi (aaomidi), Jacob Durham

Just one suggestion:

When a CA performs cross-signing for an external CA in the future, should audit logs such as the KGC key-generator-scripts and full KGC recording be evaluated?

While it is impossible to completely eliminate bugs in the random factor without touching the private key, this would add an extra layer of safeguard, enabling participating CAs to cross-verify for KGC whether there are any flaws in the procedures or scripts.