EMudhra Intermediate CA Compromise

An intermediate certificate authority, or intermediate CA, is a certificate-issuing authority below a trusted root CA. The root delegates authority to it through a certificate chain. This arrangement keeps the root’s own signing key separate while allowing intermediates to issue certificates at scale. The article concerns eight compromised eMudhra intermediate CAs.

An intermediate CA can sign certificates for websites or services. A browser follows the chain from that website certificate through the intermediate to a root already trusted in its certificate store. If every link is valid, the browser can treat the website certificate as trusted. The article says the affected intermediates chain to roots trusted by major platforms.

The danger is broad. Someone holding an intermediate CA’s private key could create certificates that appear authorized for any website or service. Mozilla, Microsoft, Apple, and Chrome blocked the certificates, while the CA revoked the compromised intermediates. Other software still needs updates or local trust changes.

The incident involved eight eMudhra intermediate CA certificates whose private keys were compromised. A private key is the secret signing credential associated with a certificate authority. Losing control of it can undermine certificates issued under that authority. The article identifies eight affected intermediates and says they chain to trusted roots.

Those roots were trusted by the Mozilla, Microsoft, Apple, and Chrome root programs. They were also trusted by many downstream trust stores. That reach matters because trust stores provide the starting points that browsers, operating systems, and other software use when checking certificate chains. The article also mentions Sectigo cross-signs for the eight intermediates.

Protections were introduced across major platforms. Firefox and Chrome blocked the certificates from 17 October, Apple devices from 19 October, and Microsoft from 20 October. Many other clients require software updates because they do not consume revocation information automatically.

The article states that an attacker with the private key of any compromised intermediate CA could impersonate any website or service. The private key is the secret credential used to sign certificates issued by that authority. Once exposed, it can let an attacker produce apparently valid certificate signatures for domains or services they do not control.

For example, an attacker could create a certificate naming a target website and sign it with a compromised intermediate key. A browser or other client would examine the certificate chain. If the chain reached a root in its trust store and no effective block applied, the certificate could appear trustworthy. The attacker could then present it while posing as the target service.

The major root programs acted quickly. Firefox and Chrome blocked the certificates on 17 October, Apple devices on 19 October, and Microsoft on 20 October. The CA also revoked the intermediates, but software updates remain necessary for clients that do not consume revocation data.

A certificate chain links a website certificate to an intermediate CA and then to a trusted root. The root is a built-in trust anchor in a browser or operating system. The intermediate’s certificate shows that the root delegated signing authority to it. This structure lets software evaluate a website certificate through a recognized authority.

When connecting, the browser checks the chain’s signatures, names, and validity details. It verifies that each certificate was signed by the authority above it and that the final root is trusted locally. In this incident, the eight intermediates chained to roots trusted by Mozilla, Microsoft, Apple, Chrome, and many downstream stores. A valid-looking chain could therefore be accepted.

That acceptance is not permanent. Firefox and Chrome blocked the affected certificates starting 17 October. Apple and Microsoft followed on 19 and 20 October. The CA revoked the intermediates, while clients without revocation support need software updates or trust-store changes to stop accepting them.

Mozilla, Microsoft, Apple, and Chrome used their revocation-distribution tools to stop users trusting the compromised intermediates. The article names OneCRL, CRLite, and CRLSets as examples. Firefox and Chrome blocked the certificates on 17 October, Apple devices on 19 October, and Microsoft on 20 October.

The CA also revoked the compromised intermediate certificates. Revocation tells compatible clients that certificates should no longer be trusted, even if their dates have not expired. The original reporter, Wayne, supplied proof on 17 October by signing the message “We have a problem here - Wayne” with each intermediate’s private key. The certificates and signatures were provided for verification.

The issue was responsibly disclosed to downstream trust stores on 19 October. Many released updates or were preparing them. However, revocation is not universal. Programs that do not consume revocation information need updated software or certificate stores. Expert users can block affected roots manually, but the article does not recommend that for ordinary users.

Revocation is a warning that a certificate or authority should no longer be trusted. It does not automatically reach every program or device. The article says many other clients do not consume revocation information, even though Mozilla, Microsoft, Apple, and Chrome distributed protections through OneCRL, CRLite, and CRLSets.

For example, a browser may receive a block through its update or revocation system, while another program relies on a local certificate store and never checks that information. That program could continue trusting a compromised chain until its software or certificate package changes. The CA’s revocation alone therefore cannot guarantee universal protection.

The article advises users to update browsers and operating systems as soon as possible. Many downstream trust stores had released updates or were preparing them. Expert users could distrust affected roots manually on several operating systems, but this is specifically not recommended for ordinary users. Until distributions ship updated packages, exposure can remain in unsupported clients.

Public-key cryptography uses a related pair: a private key kept secret and a public key shared in a certificate. A digital signature created with the private key can be checked with the matching public key. If verification succeeds, the data was signed by the holder of that private key and was not changed afterward.

For a website, the certificate contains its public key and identifies the site. During a connection, the website proves control of the corresponding private key by producing a signature that the browser verifies. The browser also checks the certificate’s chain, including the intermediate CA and trusted root. The article’s proof used each compromised key to sign a message, then verified the signatures with the supplied public keys.

This mechanism does not make a compromised key safe. An attacker who obtains an intermediate CA private key can sign certificates for other websites. Blocking, revocation, and software updates are therefore needed to prevent clients from trusting those fraudulent chains.