eMudhra quit the CA business today. I checked your trust store — its roots are still in it.
Leaving the business means eMudhra will stop operating as a globally trusted SSL/TLS certificate provider. It does not mean every eMudhra root certificate disappears instantly. Trust changes gradually because websites may still depend on certificates chaining to those roots. The article found three eMudhra roots still present in Ubuntu's bundle: emSign ECC Root CA - C3, emSign Root CA - C1, and emSign Root CA - G1. The company said G1 RSA roots will continue serving customers during the transition. Customers are promised free replacements through partners, while revocation and status services remain available. This creates an important distinction between a business announcement and a technical change. The roots remain trusted for now, so the web's practical trust state is unchanged. Mozilla's revocation list already blocks six affected TLS intermediates, while eMudhra still owes browser root programs a full root-cause report.
What does it mean for eMudhra to leave the global SSL/TLS certificate business, and why are its root certificates still in trust stores?
Leaving the business means eMudhra will stop operating as a globally trusted SSL/TLS certificate provider. It does not mean every eMudhra root certificate disappears instantly. Trust changes gradually because websites may still depend on certificates chaining to those roots.
The article found three eMudhra roots still present in Ubuntu's bundle: emSign ECC Root CA - C3, emSign Root CA - C1, and emSign Root CA - G1. The company said G1 RSA roots will continue serving customers during the transition. Customers are promised free replacements through partners, while revocation and status services remain available.
This creates an important distinction between a business announcement and a technical change. The roots remain trusted for now, so the web's practical trust state is unchanged. Mozilla's revocation list already blocks six affected TLS intermediates, while eMudhra still owes browser root programs a full root-cause report.
What is a certificate authority (CA), and why does a browser trust certificates issued by one?
A certificate authority, or CA, is an organization that verifies certificate requests and digitally signs certificates for websites or other uses. Its signature links a website's identity to a public key. That gives browsers a way to decide whether a presented certificate came through an accepted authority.
The trust begins with a root certificate. Browser and operating-system vendors place selected CA roots into trust stores after evaluating their operations and security controls. A CA can then issue intermediate certificates, which sign end-entity certificates used by websites. Browsers verify those signatures and the chain leading back to a trusted root.
The article shows why that trust carries responsibility. eMudhra's affected intermediates had dangerously weak private keys, yet its roots remained trusted during migration. Mozilla blocked six intermediates by public key, limiting their use without immediately removing every eMudhra root or disrupting unrelated certificates.
How serious was the key failure: how many intermediate private keys were affected, and how small were the possible key values?
The failure was severe because private keys are supposed to be unpredictable secrets. These eight intermediate keys were instead tiny integers. A key value smaller than 256 can be searched almost instantly, making the corresponding public key and certificate authority identity effectively exposed.
The article reports eight affected eMudhra intermediate private keys. Every value was below 256, and the largest was 237. The writer recovered all eight in 11 milliseconds. The affected set included six TLS intermediates and two code-signing intermediates. The six TLS names ended in G3B or G3C across DV, OV, and EV types.
That weakness made the intermediates' signing authority unsafe. The article says no end-entity certificates were issued from the affected CAs, and eMudhra said its infrastructure was not compromised. Even so, the keys were public knowledge, so revocation, browser blocking, customer replacement, and investigation became necessary.
What happens when Mozilla blocks a compromised intermediate CA by its public key, and why can Firefox reject certificates even when the root remains trusted?
Blocking an intermediate by public key tells Firefox to distrust certificates that chain through that key. This is more targeted than removing an entire root. It stops the compromised signing authority while preserving trust for other, unaffected certificates under the same root.
Mozilla's OneCRL contained six eMudhra intermediate entries by subject, covering DV, OV, and EV TLS certificates in the G3B and G3C groups. The article explains that these entries are blocked by public key. Firefox therefore rejects anything chaining to those keys, regardless of which certificate presents them.
The root can remain in a trust store because trust is checked through multiple controls. A certificate must form a valid chain, and its intermediate must not be revoked or blocked. Here, the eMudhra roots still appeared in Ubuntu's bundle, but Firefox's key-based OneCRL entries stopped the six compromised intermediate keys from being accepted.
What is the difference between a root certificate, an intermediate certificate, and an end-entity certificate in the chain that browsers verify?
A root certificate is the top trust anchor. It belongs to a CA and is placed directly into a browser or operating-system trust store. Because the store already trusts that root, a browser can use it as the endpoint for checking a certificate chain.
An intermediate certificate sits below the root and normally signs other certificates. This limits direct use of the root's private key. An end-entity certificate is the certificate presented by a website, connecting that site's identity to its public key. The chain can therefore run from the website certificate, through an intermediate, to the root.
The eMudhra incident illustrates the layers. The roots remained in Ubuntu's bundle, while six TLS intermediates were blocked by Mozilla because their public keys were compromised. A website certificate using one of those intermediates could therefore fail verification even though its ultimate root was still trusted.
Why are the compromised TLS intermediates listed in Mozilla's OneCRL, while the compromised code-signing intermediates require different trust stores and revocation processes?
TLS and code signing are separate trust systems. TLS certificates help browsers evaluate website connections, while code-signing certificates help software platforms evaluate signed programs. Because they serve different purposes, their trusted roots, revocation records, and enforcement tools can differ.
Mozilla's OneCRL is a TLS mechanism. It contained six eMudhra TLS intermediates: DV, OV, and EV certificates in the G3B and G3C groups. It also contained 20 issuer-and-serial entries for individual certificates, though the article does not attribute all 20 to this incident. The two compromised code-signing intermediates, OV CS G3B and G3C, were absent.
Their absence does not mean they were safe or ignored. It means OneCRL is not the relevant control for code signing. That trust runs through different stores and revocation processes. The article gives no further details about those systems, while the six key-blocked TLS intermediates are identified as the incident's clearest OneCRL fingerprint.
How do public-key cryptography and certificate-chain verification let a browser determine that a website's private key is authorized by a trusted CA?
Public-key cryptography uses related public and private keys. A CA signs a certificate with its private key, while browsers use the matching public key to verify that signature. The private key stays secret; the public key can be distributed in certificates and trust stores.
A website presents an end-entity certificate, usually with intermediate certificates. The browser checks that each certificate was signed by the next authority, that names and dates fit the connection, and that the chain ends at a trusted root. This establishes that the website's public key was authorized through the CA hierarchy. The article's eMudhra case shows why secret-key quality matters: eight intermediate private keys were tiny integers.
If an intermediate key is compromised, attackers could potentially create signatures that appear authorized by that intermediate. Mozilla therefore blocked the six affected TLS keys in OneCRL. A valid-looking chain can still fail when its signer is explicitly revoked or distrusted.
This brief was written by AI from the original reporting and checked by other models. Names, figures and quotes come from the source; read it for full context.
Read more in the JupiteX app
Pulse is free. New stories every 4 hours, each one broken into the questions that explain it.
Or read more news on the web