Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software

An intermediate certificate authority, or CA, is allowed to sign certificates that websites present to browsers. Its private key is the secret needed to create those signatures. If that key is compromised, someone else can create certificates that appear to come from the CA. The danger reaches every website covered by that intermediate.

For example, a person holding one of eMudhra’s TLS keys could issue a certificate for a different website. A browser might accept it if the certificate chains to a trusted root and meets the browser’s rules. The same incident involved two code-signing intermediates, which could affect trust in signed software.

The eight keys were blocked quickly by Chrome and Firefox. eMudhra revoked the certificates, and Apple and Microsoft also blocked them. It remains unknown how the keys left eMudhra or whether anyone besides the researcher held them.

The incident involved eight intermediate CA certificate keys belonging to eMudhra. Six were for TLS certificates used by websites. They covered domain validation, organization validation, and extended validation. The other two were organization-validated code-signing certificates.

The TLS certificates were EM DV TLS CA - G3B and G3C, EM OV TLS CA - G3B and G3C, and EM EV TLS CA - G3B and G3C. The code-signing certificates were EM OV CS CA - G3B and G3C. Each also had a cross-signed copy issued through Sectigo.

The six TLS certificates were issued by emSign Root TLS CA - G3 and chained to emSign ECC Root CA - G3. Chrome blocked all eight by matching their public keys, while its TLS verifier did not need a separate block for the code-signing certificates.

A certificate tells a browser which public key belongs to a website and is backed by a trusted CA. If someone controls an intermediate CA’s private key, that person can sign a new certificate for another domain. The browser may then treat the fraudulent certificate as part of a valid trust chain.

An attacker could use such a certificate to impersonate a website, potentially supporting phishing or interception of connections. The incident also included two code-signing intermediates. A certificate made with one of those keys could make software appear to have been signed by a trusted organization, weakening users’ ability to identify genuine software.

The article does not report that any fraudulent website or software certificate was successfully trusted. No TLS certificate chaining to the six website intermediates had been logged to Certificate Transparency before Chrome blocked them.

Chrome and Firefox maintain browser-specific revocation systems. Chrome used a CRLSet update, and Firefox pushed a OneCRL block. These lists are fetched by the browsers, so users did not need a browser update or restart. Chrome’s block matched the public keys, catching both original and Sectigo cross-signed certificates.

Many other programs work differently. The article says Go binaries and software using Python’s certifi bundle often do not check revocation data. They can continue trusting a certificate chain until their program, standard library, or root certificate bundle changes. Go therefore published a code fix that rejects chains containing the eight keys.

This creates an uneven response. Browsers received rapid protection, while operators of other software had to apply updates or remove trust in affected roots. Mozilla advised blocking individual intermediates where possible.

Certificate Transparency, or CT, records many TLS certificates so browsers and others can inspect what CAs issue. Before Chrome blocked the keys, no TLS certificate chaining to the six website intermediates had been logged. That meant no such certificate could be trusted by default in Chrome or another browser requiring CT logging.

The browser revocation response added another barrier. Chrome placed the six TLS intermediates on a CRLSet, while Firefox added them to OneCRL. Chrome matched the public keys, so its protection also covered Sectigo’s cross-signed copies. The researcher had also sent signed messages made with all eight keys to the root programs.

These controls reduced the chance of successful website abuse, but they did not prove the keys were never used. The article says it remains unknown how the keys left eMudhra or whether anyone else held them.

eMudhra was the CA whose eight intermediate keys were compromised. It revoked all eight certificates. The company’s certificates were distributed under the emSign brand, and the affected intermediates connected to roots trusted by major platforms.

Chrome and Firefox root programs verified the report and pushed blocks within hours. Apple blocked the certificates on October 19, and Microsoft did so on October 20. Other trust stores were notified. Chrome checked its other CA certificates and found no other instance of this failure mode, while Mozilla said it did not currently believe other CAs were affected.

Software developers had a separate job. Go added filtering that rejects chains containing the eight keys, including paths using system verifiers. Operators of other trust stores must block the intermediates, update bundles, or consider removing trust in the signing roots.

A website presents a certificate containing its identity and public key. An intermediate CA signs that certificate, and the intermediate itself is linked to a root CA trusted by the browser. The browser checks these signatures to confirm that each certificate was authorized by the next certificate in the chain.

In this incident, the six TLS intermediates were issued by emSign Root TLS CA - G3 and chained to emSign ECC Root CA - G3. That root was trusted in Chrome and Apple stores, and until October 20, in Mozilla’s. A browser could therefore recognize certificates below that root, subject to its other rules.

Trust is not automatic in every situation. Browsers also apply policies such as Certificate Transparency and revocation lists. Chrome blocked the affected public keys, while Firefox used OneCRL. Those checks prevented the compromised intermediates from continuing to authorize connections.