0xofdebr AAAJ

On Saturday, October 17, at 20:06 UTC, Mozilla received a report from a community member that private keys associated with eight eMudhra intermediate certificates had been compromised. These keys could allow attackers to issue fraudulent HTTPS certificates for websites they do not control.

At 22:59 UTC, Mozilla completed the process of blocking the affected certificates in Firefox using OneCRL , Mozilla’s centralized list of revoked certificates which we introduced in 2015. OneCRL allows us to deliver this protection without requiring users to update or even restart Firefox.

We have since been working with the issuing CA, other root programs and downstream trust store operators to investigate the root cause, responsibly disclose the incident and help protect the wider ecosystem.

Today, 20th October, we are also releasing an update to the trusted certificates list in NSS which removes the root certificate used to sign these intermediates. Although this change is not necessary for Firefox, this helps protect other users of our trust store or third party derivatives who do not benefit from the protection of OneCRL. This change will impact the availability of some servers for those non-Firefox users until those servers move to new certificate chains.

We recommend all trust store operators take steps to protect their users. Mozilla cannot advise on the response suitable for any particular operator, but notes:

If clients will reliably check revocation information and fail-closed (reject) if it is absent, no action is needed. The CA has marked these certificates as revoked.

If clients will reliably check revocation information and fail-closed (reject) if it is absent, no action is needed. The CA has marked these certificates as revoked.

If the operator has a mechanism for blocking trust in particular intermediate CAs, the operator should block the certificates identified in the attached JSON impacted-intermediates.json and distribute that update to clients immediately.

If the operator has a mechanism for blocking trust in particular intermediate CAs, the operator should block the certificates identified in the attached JSON impacted-intermediates.json and distribute that update to clients immediately.

Otherwise, the operator should consider whether removing trust in the roots which signed these intermediates is suitable. Mozilla has done so in its latest update to NSS (above). The roots which are known to chain to these certificates are listed in roots.json .

Otherwise, the operator should consider whether removing trust in the roots which signed these intermediates is suitable. Mozilla has done so in its latest update to NSS (above). The roots which are known to chain to these certificates are listed in roots.json .

We believe transparency is essential to trust and will provide more information in this thread as soon as circumstances allow.

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?

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

Arvid Vermote schrieb am Dienstag, 20. Oktober 2026 um 15:10:58 UTC+2: 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?

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?

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?

Adrian Mueller hat über Gmail reagiert

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

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 further updates as our review progresses.

- Chrome Root Program Team

To view this discussion visit .

To view this discussion visit .

To view this discussion visit .