We request that eMudhra answer the following questions to help us (and others) better understand the situation and more effectively plan next steps to protect our user communities.
We note that eMudhra has published (a) a status page at https://emudhra.com/en/post/certificate-security-incident ("eMudhra Statement on Recent Certificate Security Incident", first published October 20, 2026 and updated October 21, 2026), linked from a notice on the emudhra.com homepage, and (b) an October 21, 2026 press release 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 serve eMudhra's CRL and ACME endpoints - redirects to the CertiNext product page on emudhra.com, which appears to carry neither the notice nor a link to either document.
More importantly, neither document appears to contain the information subscribers and relying parties need:
- Neither identifies the distrusted root (
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; both refer only to "eMudhra's ECC root" and eight intermediate CAs;
- Neither provides browser or root store trust removal or modification timelines (beyond quoting Mozilla's Firefox and NSS releases), nor links to this bug; and
- Neither explains how a subscriber can determine whether its certificates chain to the distrusted root or what action to take, beyond stating that eMudhra has "notified affected customers and partners directly" and is "working directly with customers who may be affected to give them replacement certificates."
(Q1): How and when is eMudhra communicating actionable technical details (affected CA identifiers, root store trust removal timelines, and migration instructions) to affected subscribers and relying parties, and will this information be added to the status page and surfaced on emsign.com?
(Q2): Please confirm whether affected subscribers are being migrated to eMudhra's emSign Root CA - G1 hierarchy, to a hierarchy operated by another CA Owner (please name the corresponding root), or both. The most recent update states replacement certificates are being issued "from an alternate, independently operated, publicly trusted CA hierarchy."
(Q3): Please describe how eMudhra intends to offer "CA redundancy for all Enterprise TLS customers. We are offering every Enterprise TLS customer certificates from an additional publicly 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 about 30,000 certs that require migration and about 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, approximately 30,800 unexpired precertificates chain 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 after 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 standard ACME clients do not automatically replace certificates outside their configured renewal window without ACME Renewal Information support or manual intervention - and because transitioning from an ECC G3 hierarchy to an RSA G1 hierarchy may require client-side configuration…
(Q6): Please provide exact metrics, broken down by issuing Intermediate CA:
- Total number of affected subscribers and active (unexpired, unrevoked) certificates prior to the start of migration;
- Number of subscribers and certificates that have successfully transitioned to a replacement hierarchy to date;
- Number of subscribers and certificates remaining to be transitioned; and
- eMudhra's projected completion date for 100% of affected subscribers, particularly in light of imminent root store removals (including Chrome Root Store v43, which we expect to land 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 original ECC keys were created onboard as expected"
- "an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance"
- "a flaw in the code resulted in the second pair of keys being created onboard which were weaker"
- "these second pair of weaker keys were used by mistake 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 with the wrong key on May 29, 2025 and corrected on June 6, 2025): "The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys." (from Comment 11)
This disclosure raises serious concerns regarding eMudhra's transparency and incident handling during and after Bug 1970728:
(Q7): At what exact date and time did eMudhra personnel first realize that multiple key pairs with similar labels existed on the HSM for the G3B and G3C Intermediate CAs?
(Q8): When investigating Bug 1970728 in June 2025 - upon finding that the key used to sign each CRL did not match the public key in the corresponding issued CA certificate, and then locating and using a second key that did - 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?
(Q9): eMudhra's Bug 1970728 Full Incident Report described a root cause contributing factor as "Incorrect Key Configuration Used During Manual CRL Generation" ("A manual CRL generation process used incorrect CA key configuration due to insufficient verification steps") and stated only that "While the underlying keys were from the issuing environment, they did not match 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 original keys generated for these same CAs during the April 30, 2025 KGC, and the CA certificates had instead been issued over a second, unintended set of keys. Why did eMudhra's report omit that two key pairs existed on the HSM for each of these CAs, that the KGC had deviated from its usual process, and that the issued CA certificates did not correspond to the intended ceremony keys?
(Q10): Comment 11 states that the CSRs from the weak keys "were also sent over to Sectigo for cross signing," and the resulting Sectigo (AAA Certificate Services) cross-certificates carry a notBefore of May 14, 2025. After eMudhra's June 2025 investigation established that the keys used to sign the CRLs did not match 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 ceremony generated 24 Intermediate CAs across 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 series were created in Entrust HSMs and were meant for deployment only 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 reason for that replacement related in any way to the KGC script, procedure, or key-handling steps used in the same ceremony, and if so, why did it not prompt a review 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) with an invalid cryptographic signature that does not verify against emSign Root TLS CA - G1 or any CCADB-disclosed 4096-bit RSA CA public key.
-
(a): Which private key was used to sign roottlscag1.crl (CRL #11) on October 14, 2026, and do multiple key pairs also exist on eMudhra's HSMs for emSign Root TLS CA - G1 or any other 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 process with an automated workflow to eliminate reliance on human configuration of key mappings." Why did those controls fail to prevent the publication of an invalidly signed Root CA CRL on October 14, 2026 (again, described in Comment 7 and attached in Comment 8)?
We request that eMudhra answer the following questions to help us (and others) better understand the situation and more effectively plan next steps to protect our user communities.
We note that eMudhra has published (a) a status page at https://emudhra.com/en/post/certificate-security-incident ("eMudhra Statement on Recent Certificate Security Incident", first published October 20, 2026 and updated October 21, 2026), linked from a notice on the
emudhra.comhomepage, and (b) an October 21, 2026 press release 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 serve eMudhra's CRL and ACME endpoints - redirects to the CertiNext product page onemudhra.com, which appears to carry neither the notice nor a link to either document.More importantly, neither document appears to contain the information subscribers and relying parties need:
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; both refer only to "eMudhra's ECC root" and eight intermediate CAs;(Q1): How and when is eMudhra communicating actionable technical details (affected CA identifiers, root store trust removal timelines, and migration instructions) to affected subscribers and relying parties, and will this information be added to the status page and surfaced on
emsign.com?(Q2): Please confirm whether affected subscribers are being migrated to eMudhra's
emSign Root CA - G1hierarchy, to a hierarchy operated by another CA Owner (please name the corresponding root), or both. The most recent update states replacement certificates are being issued "from an alternate, independently operated, publicly trusted CA hierarchy."(Q3): Please describe how eMudhra intends to offer "CA redundancy for all Enterprise TLS customers. We are offering every Enterprise TLS customer certificates from an additional publicly 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 about 30,000 certs that require migration and about 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, approximately 30,800 unexpired precertificates chain to
emSign ECC Root CA - G3. 30,791 (99.9%) were issued by two Internet2 / InCommon Subordinate CAs (InCommon Intermediate CA - OVG3C[23,806] andInCommon 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, andemSign TLS CA - G3), excluding precertificates logged after October 17, 2026 under the compromisedEM DV TLS CA - G3B.(Q4): How, specifically, is eMudhra assisting subscribers in transitioning off the
emSign ECC Root CA - G3hierarchy?(Q5): Because standard ACME clients do not automatically replace certificates outside their configured renewal window without ACME Renewal Information support or manual intervention - and because transitioning from an ECC G3 hierarchy to an RSA G1 hierarchy may require client-side configuration…
(a): What concrete mechanism is eMudhra using to trigger and complete renewals for ACME subscribers?
(b): Can you describe the set of steps subscribers need to take to complete the transition?
(Q6): Please provide exact metrics, broken down by issuing Intermediate CA:
In Comment 11, eMudhra stated that during the April 30, 2025 Key Generation Ceremony (KGC):
This disclosure raises serious concerns regarding eMudhra's transparency and incident handling during and after Bug 1970728:
(Q7): At what exact date and time did eMudhra personnel first realize that multiple key pairs with similar labels existed on the HSM for the
G3BandG3CIntermediate CAs?(Q8): When investigating Bug 1970728 in June 2025 - upon finding that the key used to sign each CRL did not match the public key in the corresponding issued CA certificate, and then locating and using a second key that did - 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?
(Q9): eMudhra's Bug 1970728 Full Incident Report described a root cause contributing factor as "Incorrect Key Configuration Used During Manual CRL Generation" ("A manual CRL generation process used incorrect CA key configuration due to insufficient verification steps") and stated only that "While the underlying keys were from the issuing environment, they did not match 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 original keys generated for these same CAs during the April 30, 2025 KGC, and the CA certificates had instead been issued over a second, unintended set of keys. Why did eMudhra's report omit that two key pairs existed on the HSM for each of these CAs, that the KGC had deviated from its usual process, and that the issued CA certificates did not correspond to the intended ceremony keys?
(Q10): Comment 11 states that the CSRs from the weak keys "were also sent over to Sectigo for cross signing," and the resulting Sectigo (
AAA Certificate Services) cross-certificates carry a notBefore of May 14, 2025. After eMudhra's June 2025 investigation established that the keys used to sign the CRLs did not match 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 ceremony generated 24 Intermediate CAs across 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 series were created in Entrust HSMs and were meant for deployment only 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 reason for that replacement related in any way to the KGC script, procedure, or key-handling steps used in the same ceremony, and if so, why did it not prompt a review 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) with an invalid cryptographic signature that does not verify againstemSign Root TLS CA - G1or any CCADB-disclosed 4096-bit RSA CA public key.(a): Which private key was used to sign
roottlscag1.crl(CRL #11) on October 14, 2026, and do multiple key pairs also exist on eMudhra's HSMs foremSign Root TLS CA - G1or any other 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 process with an automated workflow to eliminate reliance on human configuration of key mappings." Why did those controls fail to prevent the publication of an invalidly signed Root CA CRL on October 14, 2026 (again, described in Comment 7 and attached in Comment 8)?