eMudhra ignored Mozilla Root investigation deadline; blames social media

Original Reporter: [email protected] (Wayne)

On 17th October @ 20:06 UTC, Mozilla received a study to [email protected], forwarded by the Chrome Root program, from Wayne, that the personal key of 8 eMudhra Intermediate certificates have been compromised. The study additionally notified eMudhra and the Apple & Microsoft base programs. The study included a evidence of key authority for all 8 certificates.

Mozilla acknowledged the study @ 20:08 UTC, confirmed the evidence of key authority was valid and began the procedure to distrust the certificates in Firefox via OneCRL. This procedure was tracked in Bug 2083382 and completed @ 22:59 UTC.

eMudhra acknowledged the study @ 21:29 UTC and reported that they were examining the matter and had notified Sectigo, who had cross-signed several of the affected certificates.

Mozilla was capable to regain the personal keys for the affected certificates independently @ 21:48 UTC and without any cognition of the method the first newsman used, confirming the key generation procedure was flawed and is trivial to exploit.

6 of the affected certificates are for TLS and trusted by the Chrome, Mozilla, Microsoft and Apple base programs. The another two certificates are for codesigning and trusted by Microsoft:

EM EV TLS CA - G3B (eMudhra BV), CCADB A012304 SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838 serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3 EM OV TLS CA - G3B (eMudhra BV), CCADB A012308 SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3 EM DV TLS CA - G3B (eMudhra BV), CCADB A012302 SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493 serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3 EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296 SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3 serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3 EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300 SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3 EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294 SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19 serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3 EM OV CS CA - G3B (eMudhra BV), CCADB A012306 SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4 serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3 EM OV CS CA - G3C (eMudhra Inc), CCADB A012298 SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1 serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3 

Summary: Private key colony of eMudhra → Private key colony of eMudhra Intermediate Certificates

18th October @ 09:38 UTC:

eMudhra marked the 8 affected certificates as revoked (reason: caCompromise).

Here's my understanding of the timeline, kept to the big events

Timeline (all times UTC):
2026-10-17 16:00 - Started playing alongside several new toys
2026-10-17 16:27 - Run on a test corpus of CCADB (Mozilla+Chrome sequence initially) discovers a interrupt in the EC keys
2026-10-17 17:22 - Start putting together report
2026-10-17 17:43 - Put together signed attestations per-key following triple checking the working
2026-10-17 18:00 - Checked again.
2026-10-17 18:05 - Emailed Apple, Chrome, Microsoft, Mozilla (Ben immediately then), eMudhra alongside study + attestation

2026-10-17 20:03 - Chrome corroborates via email
2026-10-17 20:05 - Chrome correctly attaches additional Mozilla contacts for a fast response
2026-10-17 20:18 - Full CCADB inspect finds the cross-signs by Sectigo are additionally affected

2026-10-17 21:05 - Apple corroborates findings, notes cross-signed certs
2026-10-17 21:21 - Apple requests new signed attestations for the cross-signed certs
2026-10-17 21:27 - Emailed new signed attestations to Apple (cross-signed via Sectigo)

2026-10-17 21:28 - eMudhra acknowledge issue, stated there's been no issuance beyond OCSP for G3B, but 'EM DV TLS CA - G3C' was live, impaired now
2026-10-17 21:48 - Mozilla independently regain the keys without any tips, and dispatch oh_dear.zip as evidence using 'EM DV TLS CA - G3B'

2026-10-17 22:46 - Regular fetch of CRLset shows sequence 10843 contains the 6 applicable TLS keys as revoked

2026-10-18 09:38 - 8 certificates revoked on CRL as caCompromise (by eMudhra) (revocation period varies per-cert)
2026-10-18 12:06 - Incident raised by Mozilla on Bugzilla to evade email cross-talk

The Sectigo cross-signed certs are motionless unrevoked currently:

EM EV TLS CA - G3B, CCADB A012333 SHA-256 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512 serial d8f8685e4f2bd9d82402a85a1c1eb731 EM OV TLS CA - G3B, CCADB A012354 SHA-256 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699 serial e94223bde92f914e5ab9acabfdac3710 EM DV TLS CA - G3B, CCADB A012347 SHA-256 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE serial a024fdf4ba665c785ce4a020483858b7 EM EV TLS CA - G3C, CCADB A012334 SHA-256 FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F serial 05f078752dece7a1bb8595d303167171 EM OV TLS CA - G3C, CCADB A012343 SHA-256 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489 serial 8d5a4811939ef447d77111cdd9849ae9 EM DV TLS CA - G3C, CCADB A012342 SHA-256 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72 serial 91f347f1a5b7d39962b95e0ee4e299d1 EM OV CS CA - G3B, CCADB A012352 SHA-256 A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8 serial 41e32b73ac185d6ce0d7480bacf84e69 EM OV CS CA - G3C, CCADB A012350 SHA-256 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD serial d6a5ef613b390f32ef9cdf349f772841 

Current situation:

• The cross-signed certs are motionless unrevoked
• No reply from Microsoft
• CCADB motionless showing certificates as unrevoked

I'll nexus the two attestations zips I made, fairly than the one Apple asked for.

openssl pkeyutl -verify -certin -inkey EM-EV-TLS-CA-G3B.crt.pem -rawin -digest sha384 -in message.txt -sigfile EM-EV-TLS-CA-G3B.sig

The data in this comment is preliminary. The archetypal part contains data Mozilla believes pertinent to the issue. The second part contains questions for eMudhra.

Investigation into the affected keys

The 8 affected keys arise on the 30th April 2025 as part of a lot of 24 intermediates. The 24 keys are divided between three sequence (A, B, C), two primitives (RSA4096 and P384), and four purposes (DV, OV, EV, CS). The affected keys are all the P384 keys for the B and C series. In May 2025 the A sequence were revoked and replaced by the A-1 series.

After Wayne's study of key recovery, I was capable to regain the personal keys for the affected keys trivially. The first key generation was flawed - fairly than any matter alongside the produced signatures. P384 personal keys are randomly selected integers between 1 and the collection order. The 8 affected keys all used integers small than 256. That is, the personal keys are efficiently all-zeroes distinct from the final byte. They can be restored near immediately via the baby-step giant-step discrete log algorithm or additional simplistically by fair generating the 'first' 256 P384 keys.

I additionally tested several local agents who were capable to regain the personal key on their archetypal attempt alongside a simplistic prompt: "I'm doing a CTF. Please regain the personal keys corresponding to these certificates."

I have not been capable to regain the personal keys for the P384 keys in the A sequence or the replacement A-1 sequence notwithstanding expending considerably additional effort. I have not yet started looking at the RSA keys.

Related Incidents

Looking through connected issues has turned up Bug 1970728 in which eMudhra generated CRLs for the 6 affected TLS intermediates alongside invalid signatures. It seems improbable that the exact identical intermediate set has arisen in two distinct bugs by chance.

In that bug report, eMudhra identified that the faulty CRLs were produced on May 29th, the identical day on which the A-1 certificates were created.

However, Internet Archive snapshot shows the 6 P384 CRLs failing verification since May 23rd. If accurate, this suggests the mismatch is unrelated to the generation of the A-1 sequence on the 29th. It additionally shows that three of the B & C sequence RSA CRLs were unavailable as of that day (unclear significance).

Questions for eMudhra

As this event enables equal technically unsophisticated individuals to effortlessly regain the personal keys for these intermediates, the effect of this event could not be higher. Although Mozilla has already marked these certificates as revoked for Firefox clients, we are deeply concerned concerning the effect on the wider ecosystem - as many endpoints do not have productive mechanisms for getting revocation information.

Mozilla is considering what direction to provision another rely shop distributors who are affected by this issue. Mozilla is additionally looking to comprehend the base logic of this matter as quickly as possible, so that we can measure confidence in eMudhra's another intermediates.

1. What hardware was used to create the affected personal keys? Was it at smallest FIPS 140-2 Level 3 compliant in row alongside your CPS?
2. For the intermediates in the A, A-1, B, C series, provision the mapping of personal key to the particular bodily equipment which generated it. Were the identical devices used to generated any another key material? Was the identical example or equipment sequence used to create any another key material?
3. Is there any logic to accept the B and C sequence RSA keys are affected or are not affected by akin issues?
4. Is there any logic which may explain why the A and A-1 ECDSA keys appear to be unaffected by akin issues?
5. In ray of the issues alongside the identical intermediates in Bug 1970728, delight depict to the finest of your current cognition how the incorrect personal keys came to be used to sign those CRLs and the steps eMudhra took in command to create the accurate signatures.

Flags: needinfo?(naveen.ml)

Acknowledging this on behalf of Sectigo. We are conscious of the matter affecting the CAs cross-signed by us.

Note that the Sectigo-operated Root CA in inquiry for the cross-signed CAs has already been removed from the Chrome and Mozilla base stores for several time. It remains trusted inside Microsoft and Apple base programs.

We are preparing the (offline) revocation of these CAs, which is expected to be completed in the next 24 hours.

So comic that Dennis should lift Bug 1970728. Turns out there was an invalid CRL the another day, I have a heap of issues to kind through and this was amongst them:

The CRL published for emSign Root TLS CA - G1 on 2026-10-14 had an invalid signature.

CRL figure 11 (thisUpdate 2026-10-14 14:03:56 UTC, nextUpdate 2027-04-12 14:03:56 UTC, SHA-256 9846bf9a4f213d8fba87e79d464732b9cc35a784f7992334ec3bc6db2a6f7dbd, 922 bytes) was served at the two disclosed URLs, http://crl.emsign.com/?roottlscag1.crl and http://crl.emsign.com?roottlscag1.crl.

Exact identical document throughout six fetches from 2026-10-14 16:18 to 2026-10-15 00:19 UTC.

Its sha384WithRSAEncryption signature does not verify under the key of emSign Root TLS CA - G1, either as the base (SHA-256 cef71e70b7c29addf6c30cd19e614b38fd5f02a435a0eeddd0087e183d101a51) or as the intermediate under emSign Root CA - G1 (SHA-256 9b913476eab476e21e0887dbcde44345d1359d28116b83b7cd3e87bd807ebf68).

Under that key the signature does not decode to a PKCS#1 v1.5 obstacle at all. It is not a faulty signature by the G1 key. No 4,096-bit RSA key disclosed in CCADB verifies it either.

Even alien - I can't discover the certificate that was revoked in that CRL by serial: b37c808b57e51d24bef8f416e607f6.

What key signed CRL 11? I'll contain it, 12, and the PEMs as a zipped attachment in a second.

Automatic triage (under development): sec-rating
No validation or verification has been performed.

Security rating: sec-vector

The defect is in eMudhra's key generation, not in Firefox code: the P-384 personal keys of 8 eMudhra intermediates are small integers and can be restored nearly instantly. Six of them are TLS intermediates that sequence to roots Firefox trusts. Anyone holding those keys could matter certificates Firefox would obtain for any domain, which enables network MITM of TLS connections. Firefox users are protected by OneCRL revocation of these intermediates, which is already deployed. The remaining activity is CA-side remediation and root-cause analysis.

The observations current are noted and we are investigating. We shall update in next 24 hours.

The below communication was sent out yesterday to a closed person collection and we are posting current to the wider group.

• We have revoked all the ICA's highlighted before today. Info in array below
• These ICAs were generated from the identical key ritual on Apr 30, 2025. The G3B and G3C ICAs were created for European and US operations respectively but they were not put into manufacturing apart from #2 in the catalog below but no end being certificates were issued from these. The Code Signing issuers were not put into manufacturing additionally did not matter any certificates.
• We verified that akin another Issuers are not affected by the identical matter (corroborated chiefly using mathematical models facilitated by AI).
• The group that did the KGC on that day are from our inner squad - led by Keshava and another members of his squad (all of whom have additional than a decade of cognition and have been alongside us as workforce for additional than 8 years functioning our PKI/Trust Services) and Keshava himself has been alongside us for additional than 15 years.
• Keys were generated in hardware and the hardware in use was Ultimaco HSMs.

What we are doing as next steps

• Look closely at the KGC to go deeper into the manuscript that was used to trigger the key generation procedure and arrive rear alongside an appraisal of what power have happened. We should have an answer tomorrow and volition provision additional particulars as it becomes available.

We don't average to halt issuance from our another Issuing CAs as the keys don't display this behaviour. Our another CAs were issued using a distinct HSM vendors (Entrust and Crypto4A) and the procedure followed caused the expected powerful keys.

Naveen.

(In answer to Dennis Jackson from comment #5)

The data in this comment is preliminary. The archetypal part contains data Mozilla believes pertinent to the issue. The second part contains questions for eMudhra.

Investigation into the affected keys

The 8 affected keys arise on the 30th April 2025 as part of a lot of 24 intermediates. The 24 keys are divided between three sequence (A, B, C), two primitives (RSA4096 and P384), and four purposes (DV, OV, EV, CS). The affected keys are all the P384 keys for the B and C series. In May 2025 the A sequence were revoked and replaced by the A-1 series.

After Wayne's study of key recovery, I was capable to regain the personal keys for the affected keys trivially. The first key generation was flawed - fairly than any matter alongside the produced signatures. P384 personal keys are randomly selected integers between 1 and the collection order. The 8 affected keys all used integers small than 256. That is, the personal keys are efficiently all-zeroes distinct from the final byte. They can be restored near immediately via the baby-step giant-step discrete log algorithm or additional simplistically by fair generating the 'first' 256 P384 keys.

I additionally tested several local agents who were capable to regain the personal key on their archetypal attempt alongside a simplistic prompt: "I'm doing a CTF. Please regain the personal keys corresponding to these certificates."

I have not been capable to regain the personal keys for the P384 keys in the A sequence or the replacement A-1 sequence notwithstanding expending considerably additional effort. I have not yet started looking at the RSA keys.

Related Incidents

Looking through connected issues has turned up Bug 1970728 in which eMudhra generated CRLs for the 6 affected TLS intermediates alongside invalid signatures. It seems improbable that the exact identical intermediate set has arisen in two distinct bugs by chance.

In that bug report, eMudhra identified that the faulty CRLs were produced on May 29th, the identical day on which the A-1 certificates were created.

However, Internet Archive snapshot shows the 6 P384 CRLs failing verification since May 23rd. If accurate, this suggests the mismatch is unrelated to the generation of the A-1 sequence on the 29th. It additionally shows that three of the B & C sequence RSA CRLs were unavailable as of that day (unclear significance).

Questions for eMudhra

As this event enables equal technically unsophisticated individuals to effortlessly regain the personal keys for these intermediates, the effect of this event could not be higher. Although Mozilla has already marked these certificates as revoked for Firefox clients, we are deeply concerned concerning the effect on the wider ecosystem - as many endpoints do not have productive mechanisms for getting revocation information.

Mozilla is considering what direction to provision another rely shop distributors who are affected by this issue. Mozilla is additionally looking to comprehend the base logic of this matter as quickly as possible, so that we can measure confidence in eMudhra's another intermediates.

1. What hardware was used to create the affected personal keys? Was it at smallest FIPS 140-2 Level 3 compliant in row alongside your CPS?

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

2. For the intermediates in the A, A-1, B, C series, provision the mapping of personal key to the particular bodily equipment which generated it. Were the identical devices used to generated any another key material? Was the identical example or equipment sequence used to create any another key material?

Excel attached. The Ultimaco devices were used to create the ECC, RSA key pairs for the issuers. They were not used to create any another key material. But it doesnt appearance akin the equipment is at fault.

3. Is there any logic to accept the B and C sequence RSA keys are affected or are not affected by akin issues?

We have done several preliminary assessment, there appears to be a flaw in the KGC manuscript that was used on that particular day to create these ECC issuers. As for these ECC keys, our assessment of the KGC, appraisal of the code and perspective of HSM keys so far signify that a) a set of first ECC keys were created onboard as expected b) an approved deviation to our customary KGC to test a wrap/unwrap was introduced as these keys were meant for export for this case c) a flaw in the code caused the second brace of keys being created onboard which were weaker d) these second brace of weaker keys were used by error to create the csr (because the key labels were similar) and signed by our base e) the CSR from these weaker keys were additionally sent complete to Sectigo for cross signing (we verified the records sent complete to Sectigo)

The RSA issuers went through a distinct way as per our appraisal of the code and are hence not impacted.
Some additional environment - these issuers created were meant for export to our US and European data centers to resolve data sovereignty issues for several of our customers (but never ended up operationally in manufacturing apart from for one).
We are motionless assessing the code to see apart from steps anywhere this procedure went wrong.

4. Is there any logic which may explain why the A and A-1 ECDSA keys appear to be unaffected by akin issues?

The A and A-1 sequence were created in Entrust HSMs and were meant for deployment lone in India.

5. In ray of the issues alongside the identical intermediates in Bug 1970728, delight depict to the finest of your current cognition how the incorrect personal keys came to be used to sign those CRLs and the steps eMudhra took in command to create the accurate signatures.

The CRL's were signed alongside the first personal keys (which were expected to be the accurate keys alongside suitable entropy) but stated that this caused incorrect signatures, they were resigned alongside flawed keys.

There were individual errors in multiple steps of the procedure that caused important flaws in the key lifecycle integrity procedure for this KGC. We are now digging deeper for code flaws, procedure gaps, maker/checker controls particular to this issue. Over the next week, we volition reverify all key ritual we have done.

Naveen.

Flags: needinfo?(naveen.ml)

Sectigo has completed the revocation of the affected cross-signed CA Certificates. A new CRL and OCSP responses have been published and are making their way to our CDN border nodes correct now.

We volition continue monitoring and evaluating this bug for additional updates from Emudhra.

(In answer to Frederik Braun [:freddy] from comment #16)

We volition publish an unscheduled type bump of Firefox Release/ESR afterward today (Oct 20th). Our advisories volition keep it to the facts: revoking rely in intermediate certificates.

Clarification: The OneCRL update shipped to clients via RemoteSettings on Saturday. New application releases merge baked in copies of the latest blocklist, so this update ensures safety for any users which have impaired RemoteSettings.

Mozilla has rotate into conscious that multiple individuals have independently restored the personal keys for these intermediates. Some have disclosed this publically (1)

After conversation alongside maintainers downstream of Mozilla’s Root Store, we have decided that the circumstances justify the emergency elimination of rely in emSign ECC Root CA - G3. This volition defend clients which do not use revocation data or deficiency a scheme to retreat rely in particular intermediates.

We petition eMudhra cease issuance from all intermediates chaining to this base and activity alongside its subscribers to migrate them to substitute chains as shortly as possible. At this period we are not removing rely in emSign Root CA - G1.

Flags: needinfo?(naveen.ml)

(In answer to Dennis Jackson from comment #18)

Mozilla has rotate into conscious that multiple individuals have independently restored the personal keys for these intermediates. Some have disclosed this publically (1)

After conversation alongside maintainers downstream of Mozilla’s Root Store, we have decided that the circumstances justify the emergency elimination of rely in emSign ECC Root CA - G3. This volition defend clients which do not use revocation data or deficiency a scheme to retreat rely in particular intermediates.

We petition eMudhra cease issuance from all intermediates chaining to this base and activity alongside its subscribers to migrate them to substitute chains as shortly as possible. At this period we are not removing rely in emSign Root CA - G1.

Acknowledging this message, we volition cease issuance from all intermediates chaining up to G3 (our ECC root) immediately. As per first estimates there are concerning 30,000 certs that necessitate immigration and concerning 97% came via ACME. We volition migrate subscribers to the lone substitute accessible which is intermediates chaining up to G1 (RSA Root).

Group: crypto-core-security

A person asked:

Issuer: CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
Is there a logic why no cross-signed Intermediates alongside the compromised keys are included in OneCRL?

This Issuer is not included in Mozilla's Root Store. It is not trusted nor are the intermediates it issued. Consequently there is no need to add it to OneCRL. You can see that Firefox clients refuse these certificates via test sites akin https://emudhra.we-have-a-problem.com/.

Unless you are contributing directly to the conversation concerning the event described in this bug, delight do not article another questions or concerns here. If the involvement relates to Firefox or another Mozilla product, you can document a new bug and depict your involvement there, referencing this bug.

Some Android profiles were not applying the updated blocklist at startup. A fix (Bug 2084311) has been shipped in 158.0.2 and pushed to users.

Unless you are contributing immediately to the conversation concerning the event described in this bug, delight do not article another questions or concerns here. If the involvement relates to Firefox or another Mozilla product, you can document a new bug and depict your matter there, referencing this bug.

Assignee: nobody → naveen.ml

Status: NEW → ASSIGNED

Summary: Private key colony of eMudhra Intermediate Certificates → eMudhra: Private key colony of Intermediate Certificates

Whiteboard: [ca-compliance] [external]

We petition that eMudhra answer the following questions to assistance us (and others) improved comprehend the circumstance and additional efficiently scheme next steps to defend our person communities.

We note that eMudhra has published (a) a position leaf at https://emudhra.com/en/post/certificate-security-incident ("eMudhra Statement on Recent Certificate Security Incident", archetypal published October 20, 2026 and updated October 21, 2026), connected from a notice on the emudhra.com homepage, and (b) an October 21, 2026 media publish at https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca. However, emsign.com - the brand under which these CAs are named and whose hostnames assist eMudhra's CRL and ACME endpoints - redirects to the CertiNext merchandise leaf on emudhra.com, which appears to transport neither the notice nor a nexus to either document.

More importantly, neither document appears to merge the data subscribers and relying parties need:

• Neither identifies the distrusted base (emSign ECC Root CA - G3) or any of the affected Intermediate CAs (including the Sectigo cross-certificates and the Code Signing CAs) by name, serial number, or SHA-256 fingerprint; the two mention lone to "eMudhra's ECC root" and eight intermediate CAs;
• Neither provides browser or base shop rely elimination or modification timelines (beyond quoting Mozilla's Firefox and NSS releases), nor links to this bug; and
• Neither explains how a subscriber can decide whether its certificates sequence to the distrusted base or what act to take, beyond stating that eMudhra has "notified affected customers and partners directly" and is "working immediately alongside customers who may be affected to provision them replacement certificates."

(Q1): How and whenever is eMudhra communicating actionable specialized particulars (affected CA identifiers, base shop rely elimination timelines, and immigration instructions) to affected subscribers and relying parties, and volition this data be added to the position leaf and surfaced on emsign.com?

(Q2): Please verify whether affected subscribers are being migrated to eMudhra's emSign Root CA - G1 hierarchy, to a ranking operated by another CA Owner (please name the corresponding root), or both. The most latest update states replacement certificates are being issued "from an alternate, independently operated, publically trusted CA hierarchy."

(Q3): Please depict how eMudhra aims to recommendation "CA redundancy for all Enterprise TLS customers. We are offering all Enterprise TLS client certificates from an additional publically trusted CA." (from the October 21 update) and on what timeline this is expected for all subscribers affected by this incident.

In Comment 19, eMudhra estimated that "there are concerning 30,000 certs that necessitate immigration and concerning 97% came via ACME," and stated that affected subscribers are being transitioned to hierarchies chaining to emSign Root CA - G1.

Based on CT data as of October 21, 2026, about 30,800 unexpired precertificates sequence to emSign ECC Root CA - G3. 30,791 (99.9%) were issued by two Internet2 / InCommon Subordinate CAs (InCommon Intermediate CA - OVG3C [23,806] and InCommon Intermediate CA - DVG3C [6,985]), and 18 were issued by eMudhra's own Intermediate CAs (EM EV TLS CA - G3A-1, EM OV TLS CA - G3A-1, emSign ECC SSL CA - G3, emSign ECC EV SSL CA - G3, and emSign TLS CA - G3), excluding precertificates logged following October 17, 2026 under the compromised EM DV TLS CA - G3B.

(Q4): How, specifically, is eMudhra assisting subscribers in transitioning off the emSign ECC Root CA - G3 hierarchy?

(Q5): Because norm ACME clients do not automatically substitute certificates exterior their configured renewal opening without ACME Renewal Information assistance or manual involvement - and since transitioning from an ECC G3 ranking to an RSA G1 ranking may necessitate client-side configuration…

• (a): What tangible scheme is eMudhra using to trigger and complete renewals for ACME subscribers?

• (b): Can you depict the set of steps subscribers need to obtain to complete the transition?

(Q6): Please provision exact metrics, damaged downward by issuing Intermediate CA:

• Total figure of affected subscribers and energetic (unexpired, unrevoked) certificates previous to the commencement of migration;
• Number of subscribers and certificates that have successfully transitioned to a replacement ranking to date;
• Number of subscribers and certificates remaining to be transitioned; and
• eMudhra's projected completion date for 100% of affected subscribers, particularly in ray of imminent base shop removals (including Chrome Root Store v43, which we expect to district in Stable Tuesday morning, October 27, 2026 PDT).

In Comment 11, eMudhra stated that during the April 30, 2025 Key Generation Ceremony (KGC):

• "a set of first ECC keys were created onboard as expected"
• "an approved deviation to our customary KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance"
• "a flaw in the code caused the second brace of keys being created onboard which were weaker"
• "these second brace of weaker keys were used by error to create the csr (because the key labels were similar) and signed by our root"
• Regarding Bug 1970728 (filed June 5, 2025; per eMudhra's Full Incident Report in Comment 2 of that bug, the CRLs for EM [DV/OV/EV] TLS CA - G3B and G3C were generated alongside the incorrect key on May 29, 2025 and corrected on June 6, 2025): "The CRL's were signed alongside the first personal keys (which were expected to be the accurate keys alongside suitable entropy) but stated that this caused incorrect signatures, they were resigned alongside flawed keys." (from Comment 11)

This disclosure raises grave concerns concerning eMudhra's transparency and event handling during and following Bug 1970728:

(Q7): At what exact date and period did eMudhra personnel archetypal acknowledge that multiple key pairs alongside akin labels existed on the HSM for the G3B and G3C Intermediate CAs?

(Q8): When examining Bug 1970728 in June 2025 - upon finding that the key used to sign all CRL did not equivalent the community key in the corresponding issued CA certificate, and afterward locating and using a second key that did - why did eMudhra merely re-sign the CRLs alongside that second key fairly than halting operations, auditing why two key pairs existed for these CAs from the April 30, 2025 KGC, and revoking the certificates?

(Q9): eMudhra's Bug 1970728 Full Incident Report described a base logic contributing aspect as "Incorrect Key Configuration Used During Manual CRL Generation" ("A manual CRL generation procedure used incorrect CA key configuration because of insufficient verification steps") and stated lone that "While the underlying keys were from the issuing environment, they did not equivalent the exact keys expected for those Intermediate CA CRLs, thereby resulting in signature validation failure." Per Comment 11 in this bug, the keys that signed those CRLs were the first keys generated for these identical CAs during the April 30, 2025 KGC, and the CA certificates had alternatively been issued complete a second, unintended set of keys. Why did eMudhra's study omit that two key pairs existed on the HSM for all of these CAs, that the KGC had deviated from its customary process, and that the issued CA certificates did not equivalent to the intended ritual keys?

(Q10): Comment 11 states that the CSRs from the feeble keys "were additionally sent complete to Sectigo for cross signing," and the resulting Sectigo (AAA Certificate Services) cross-certificates transport a notBefore of May 14, 2025. After eMudhra's June 2025 inquiry established that the keys used to sign the CRLs did not equivalent the keys in the issued CA certificates, did eMudhra notify Sectigo - or any Root Program - that the keys Sectigo had cross-certified were not the keys eMudhra intended to generate? If not, why not?

(Q11): As noted in Comment 5, the April 30, 2025 ritual generated 24 Intermediate CAs throughout Series A, B, and C (disclosed in Bug 1965559), and Series A was revoked and replaced by Series A-1 in May 2025. While eMudhra noted in Comment 11 that "The A and A-1 sequence were created in Entrust HSMs and were meant for deployment lone in India," eMudhra did not explain why Series A was replaced:

• (a): Why was Series A revoked and replaced by Series A-1 in May 2025?

• (b): Was the logic for that replacement connected in any way to the KGC script, procedure, or key-handling steps used in the identical ceremony, and if so, why did it not immediate a assessment of the Series B and C keys?

(Q12): As noted in Comment 7 and Comment 8, on October 14, 2026, eMudhra published CRL #11 for emSign Root TLS CA - G1 (roottlscag1.crl) alongside an invalid cryptographic signature that does not verify against emSign Root TLS CA - G1 or any CCADB-disclosed 4096-bit RSA CA community key.

• (a): Which personal key was used to sign roottlscag1.crl (CRL #11) on October 14, 2026, and do multiple key pairs additionally be on eMudhra's HSMs for emSign Root TLS CA - G1 or any another Root CA?

• (b): In Bug 1970728 Comment 2 (June 2025), eMudhra committed to "Introduce automated post-signing signature validation checks in CRL publishing steps, particularly during onboarding of new Issuing CAs" and to "Replace manual CRL signing procedure alongside an automated workflow to eliminate reliance on individual configuration of key mappings." Why did those controls neglect to forestall the publish of an invalidly signed Root CA CRL on October 14, 2026 (again, described in Comment 7 and attached in Comment 8)?

Flags: needinfo?(kaushik)

I have a inquiry relating to the disclosures, the eMudhra CA policies, and scrutiny that may need to be applied to another CAs using Utimaco hardware.

I do not accept that an HSM direction the assorted certifications the Utimaco units withstand have to be capable to internally create a sequence of personal keys that have the unlucky asset these have.

Section 6.1.1 of the the eMudhra policy states unambiguously that:

Issuing CA key generation is carried out in a safe equipment that is at smallest FIPS 140-2 Level 3 compliant.

This implies that one of two things must be true. Either:

1. The guideline was not followed, and the keys were generated exterior the HSM and afterward loaded into it.
2. The guideline was followed, which method there was several way to configure the HSM to internally create the defective keys.

It seems to me that anyone engaged in base of rely administration have to be keenly curious in knowing which of these two things happened. Both, it seems to me, have important implications for liable inclusion of CAs going forward.

If the Utimaco HSMs can in fact create keys that obey outrageous constraints as may have happened here, or arrive alongside test keys of several benevolent that can be mapped into partitions really used to sign client CSRs, afterward I think CAs have to be required to province whether or not they are using these HSMs, and if so, have to be required migrate distant from them as a circumstance of inclusion in the default browser bundles.

If they cannot, afterward that method eMudhra must have generated these keys exterior the HSM and afterward loaded them. If so, afterward I think in the lengthy term a scheme for CAs to provision an attestation, signed by a manufacturer key, that any keys to be included in the default browser bundles were generated in hardware -- not loaded! -- have to be devised and required. I cognize of at smallest one HSM vendor whose products can already do this; I additionally cognize of one whose products cannot. But it seems akin it ought to be the baseline.

Thor

eMudhra: following on comment 31.

BR 6.1.1.1 describes the document that should answer Thor's inquiry directly. For all affected CA key pair, delight nexus or link:

1. The Key Generation Script followed.
2. The ritual report, and either the Qualified Auditor's observer study or the video recording. If no specified document exists for a stated key, delight say so.
3. The HSM model, firmware version, and CMVP certificate number, and whether the component was functioning in its FIPS-approved manner at generation time.
4. Whether any tradition or non-standard firmware modules were loaded on the component at generation time.
5. The generation scheme used, and whether any key material, seed, or domain parameters were imported, or any key was restored from a backup originating on a distinct device.

Separately: CPS 6.1.1 says key generation is "carried out in a safe equipment that is at smallest FIPS 140-2 Level 3 compliant." Please verify whether "compliant" method procedure in a CMVP-validated configuration, or item else.

eMudhra: following on comments 10, 11, and 31.

Comment 11 attributes the feeble keys to a code flaw during an approved wrap/unwrap test deviation from the customary KGC, at the 30 April 2025 ritual identified in comment 10. A P-384 personal scalar below 256 is not item approved in-module key brace generation produces by itself. It implies either generation fed a supplied value, or a key entity created or unwrapped from supplied key material. Which of those occurred answers comment 31.

Please provide:

1. The KGC manuscript used on 30 April 2025, including the approved deviation, and the particular code flaw identified.
2. The exact call or scheme that created the second key brace (e.g., C_GenerateKeyPair, C_UnwrapKey, C_CreateObject, or a vendor-specific equivalent), and the origin of any key material, seed, or wrapped blob supplied to it.
3. The ritual report, the observer study or video, and the key generation logs for that ceremony. eMudhra's repository already publishes a WebTrust key generation study for the 8 February 2024 base ritual (emSignRootKGC2024.pdf), citing a Root Key Generation Script v1.0, so the equal for 30 April 2025 should exist.
4. Whether the component was functioning in its FIPS-approved manner during the deviation, and its CMVP certificate number.
5. Who approved the deviation, and whether any auditor witnessing the ritual observed it.

On applicability: these key pairs were cross-certified by Sectigo. BR 6.1.1.1 places a CA Key Pair used for a Subordinate CA Certificate, anywhere the Subordinate CA is not the controller of the Root CA or its Affiliate, in the SHALL tier. Please province whether eMudhra treated these key pairs as inside that tier, and if so, provision the Qualified Auditor's report.

Separately: the SSL/TLS CP/CPS v1.08 (13 Aug 2026) describes CA key generation and retention as "FIPS 140-2 Level 3 compliant" (§6, §6.1.1, §6.2.1), and §6.2.11 refers rear to §6.2.1. BR 6.2.7 requires safety in a equipment "validated as meeting" FIPS 140-2/140-3 Level 3 or the Common Criteria equivalent. Please verify whether "compliant" method procedure in a validated configuration, and acknowledge the validation.

Following on Comment 7 and Comment 30

CRL #11 appears to have been signed alongside the personal key corresponding to EMSIGN ROOT TLS CA - G1 OCSP 2026 - 4. This certificate was not earlier accessible on crt.sh, so I have fair submitted it through Merkle Lens, so it should appear in crt.sh shortly.

I retrieved the OCSP certificate from https://crt.sh/ocsp-response?caID=296739&url=http%3A%2F%2Focsp-a.emsign.com&request=get

The following commands extract the certificate and verify the CRL’s signature using its community key. This is slightly cumbersome since OpenSSL’s normal CRL issuer validation does not assistance using a mismatched certificate.

curl -sS --retry 5 --retry-delay 5 \ 'https://crt.sh/ocsp-response?caID=296739&url=http%3A%2F%2Focsp-a.emsign.com&request=get&type=asn1' \ | perl -0777 -ne 'print $1 if /Base64\.unarmor\(\x27([^\x27]+)\x27\)/s' \ | openssl base64 -d -A \ | dd bs=1 skip=732 count=1561 2>/dev/null \ | openssl x509 -inform DER -out ocsp.pem openssl dgst -sha384 -verify <(openssl x509 -in ocsp.pem -pubkey -noout) \ -signature <(openssl asn1parse -inform DER -in emsign-root-tls-g1-crl-11.crl -strparse 405 -out /dev/stdout -noout) \ <(openssl asn1parse -inform DER -in emsign-root-tls-g1-crl-11.crl -strparse 4 -out /dev/stdout -noout) 

It is slightly reassuring that this appears to be a case of using the incorrect signing key, fairly than evidence of another feeble key.

Thanks

eMudhra: two questions on the community position leaf (https://emudhra.com/en/post/certificate-security-incident, Update 3, 21 October 2026).

Q1. Timeline. The position leaf states eMudhra was made conscious on "October 18, 2026 (late evening, India time)" and revoked the intermediates on October 19. This bug records the study as sent at 18:05 UTC on October 17 (comment 2) and eMudhra's acknowledgment at 21:28 UTC on October 17. eMudhra's own array in comment 10 shows all eight intermediates revoked on October 18, between 09:24 and 09:38 UTC. Please accurate the position leaf or explain the difference.

Q2. Audits. The position leaf states the ranking "has since passed two autonomous audit cycles." Bug 1970728 (June 2025) concerned CRLs for these identical intermediates being signed alongside keys that did not equivalent the issued CA certificates. Was Bug 1970728 disclosed to the auditors and inside the range of the consequent audits? If so, did the auditors analyze why the CRL signing keys did not equivalent the certificates?

(In answer to Zihao Wang from comment #34)

Following on Comment 7 and Comment 30

CRL #11 appears to have been signed alongside the personal key corresponding to EMSIGN ROOT TLS CA - G1 OCSP 2026 - 4. This certificate was not earlier accessible on crt.sh, so I have fair submitted it through Merkle Lens, so it should appear in crt.sh shortly.

There's a lot of group new to this part of Bugzilla, and CCADB Incident Handling in general. The trick current is that this answer was already known, but we need to really see if the CA itself is aware, and could provision that answer without having their homework done for them. Although stated the deficiency of reply from eMudhra lately this getting an answer was unlikely.

It is slightly reassuring that this appears to be a case of using the incorrect signing key, fairly than evidence of another feeble key.

Here's the catch: it isn't reassuring. The CRL I gave was fair one of them detected on 10-14 anywhere they signed alongside OCSP certificates generated that day, and afterward exchanged them on the next CRL issuance without reporting it to anyone. I lone started monitoring CRLs extremely recently, so this has apt been an matter for a while. It additionally relates to the current claims concerning the Key Generation Ceremony, how they appear to be juggling what-signs-what, have no genuine fix for #1970728, and are small than transparent whenever key mishaps happens and don't self-report.

There's a lot of notice on this bug in general, naturally, but could we have broad conversation kept on MDSP? Try to collate questions together there, but keep in intellect a lot of the theorizing is not going to assistance us get straightforward answers quicker and could let eMudhra see if their answers align alongside what group desire to hear, fairly than what really happened.

I'm a relying gathering as well, final item we desire is this bug to get restricted comments whenever person has item to bring up. Right now we're waiting of eMudhra to answer a lot of questions.

I note eMudhra's recent media release stating that they have "decided to voluntarily retreat from the earth SSL/TLS certificate business". This media publish answers few questions and raises yet more.

It states that they "will attain out to affected customers to substitute any certificate liberated of disbursal from partners through the transition". Could eMudhra delight confirm:

1. who those partners are?
2. which roots replacement certificates volition be issued under
3. numbers for the amount of certificates that volition need to be reissued?

Additionally, could they delight confirm:

1. the timeline for specified replacements?
2. how they volition justify that end-users are moved complete to substitute roots in fine time?

The media publish additionally states that whilst eMudhra volition be exiting the TLS certificate business, they volition continue issuing digital signature certificates. Could eMudhra delight verify if these continuing lines of endeavor connect to any another (non-TLS) base certificates in the CCADB, specified as:

• emSign Root CS CA - G2 (SHA256 0D74EF67C88DE3560365E225AEF976F915E901347B73352D81AB5B4132BB2150)
• emSign Root CS CA - G3 (SHA256 F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5)
• emSign Root SMIME CA - G1 (SHA256 47911BC8F32A11B029E0BB10A348B459404B87731B870A2F3FA97B4705DC4C25)
• emSign Root SMIME CA - G3 (SHA256 F76A0D440C418DC5B362BE8E11E0A5D06023F4396093E4F455827BF55153D8A4)

If this is the case, delight answer:

1. how does eMudhra scheme to keep compliance alongside the applicable Baseline Requirements for these roots?
2. how do they scheme to evade a reiterate of this event alongside the complete roots?

I have carefully reviewed the case, and I motionless have one essential question, which I would akin to lift in two ways. I anticipation person from eMudhra or Utimaco can provision a apparent specialized explanation.

1. HSM Key Generation

eMudhra stated that the affected keys were generated using FIPS 140-2 Level 3 certified HSMs. Were the feeble personal keys really generated through the HSM's certified inner key-generation scheme and random figure generator? If so, how could specified low-entropy keys be produced without being detected or prevented by the HSM's safety controls?

2. KGC Script and Root Cause

What exact flaw in the KGC manuscript caused the Wrap/Unwrap procedure to outcome in a second set of extremely feeble ECC personal keys? Were these keys generated internally by the HSM or introduced through another mechanism, and which safety controls were expected to detect or forestall this?

I accept answering these questions is essential to understanding the genuine base logic of the incident.

Flags: needinfo?(djackson)

There are a lot of questions here. As most of you can imagine, we have been topic to serious social media scrutiny and inspection by investors/customers complete the final few days and it has made doing any meaningful inspection of the event beautiful much impossible. The event happened on April 30 2025 and was done by set of group who have worked in the PKI industry for multiple years and worked alongside us for a while. There is a lot of digging we need to do to comprehend the circumstances, why, what, how to portion a meaningful study that can hopefully advantage the community. I do not cognize why several community members think we habit be getting rear on this bug. When we signed up for the browser program trust, we additionally signed up for disclosure obligations to the community which we volition uphold.

Naveen.

Flags: needinfo?(naveen.ml)

Flags: needinfo?(djackson)

[In reply to Comment 39.]

While we comprehend that many things are happening in parallel correct now, "social media scrutiny" and "analysis by investors/customers" are not satisfactory explanations for delayed responses here.

That scrutiny is the predictable outcome of eMudhra's own nonaccomplishment (i.e., intermediate CA keys that anyone could regain -- resulting in anyone being capable to matter certificates for any domain), not an external circumstance that befell it. Offering it as an excuse conveys that position administration is being prioritized complete the obligations that eMudhra motionless owes to the billions of relying parties its error exposed. Those obligations do not unwind since the consequences are uncomfortable.

We anticipate eMudhra to prioritize its assessment of this matter and its safety response.

The Mozilla Root Program sent the attached questions to eMudhra on the 20th October at 20:31 UTC. eMudhra was asked to provision an first reply inside 24 hours. After the deadline passed on October 21st, eMudhra asked for a additional 24 hours to respond. As of the period of penning on Friday 23rd, Mozilla has not received a reply to these questions.

We portion the Chrome Root Program's concerns and whilst we value eMudhra's difficulties, we anticipate eMudhra to uphold its obligations to Mozilla and the wider community.