eMudhra incident: eight CA keys were trivially easy to guess – what TLS certificate holders need to check now

6 November 2026  |  Certificates  |  IT security

In October 2026, it emerged that the Indian certificate authority eMudhra had issued eight intermediate CA certificates with virtually worthless private keys. The private keys were integers below 256; one was literally the number 4. Anyone who knows such a key can sign certificates for any domain on behalf of the certificate authority. Browser vendors therefore responded within hours, blocking the intermediate certificates and removing the associated root CA, emSign ECC Root CA – G3, from their trust stores.

This article explains exactly what happened, why a key of ‘4’ is a complete security failure, who is affected – and who is not – and what operators of websites, mail servers and firewalls should check now. We stick strictly to what the primary sources substantiate. Some accounts circulating in early coverage and on social media are inaccurate. More on that shortly.

At a glance: what is true and what is not

The timeline

• 17 October 2026: The incident is reported to Mozilla (received at 18:05 UTC according to Bugzilla). By 22:59 UTC, the block on the intermediate certificates has been distributed through Mozilla's OneCRL, less than three hours after Mozilla received the report.
• 18 October 2026: eMudhra revokes the eight intermediate certificates.
• 19 October 2026: Sectigo revokes the cross-certificates it had used to cross-sign the eight intermediate CAs.
• 20 October 2026: Mozilla releases Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1, along with NSS 3.131.1. These remove the root emSign ECC Root CA – G3. Between 20 and 21 October, 107,107 certificates signed with six of the eight weak keys also appear in the Certificate Transparency logs (see below).
• 22 October 2026: eMudhra announces its withdrawal from the public TLS certificate business. Code signing and S/MIME continue under separate roots.
• 27 October 2026: Chrome also removes the root CA.
• 16 and 30 November 2026: Deadlines for the older G1 certificates (Chrome/Mozilla and Apple respectively), which eMudhra says are relevant to the transition for the affected US customer consortium.

Why a private key of ‘4’ is a complete security failure

A certificate authority (CA) uses its digital signature to confirm that a certificate belongs to a domain. Browsers trust this signature as long as the CA is in their trust store. Security depends on only the CA knowing the private key.

For certificates using elliptic curves (ECDSA), the private key is a very large number d. The public key is a point Q = d · G on the curve (G is the specified base point). Working backwards from Q to find d is practically impossible for a randomly chosen 384-bit number. But if d is small, such as 4, all it takes is to calculate 1·G, 2·G, 3·G, 4·G … in turn and compare the results with the public point. This takes seconds and requires no specialist knowledge.

The public key is included in every certificate, so anyone can see it. Anyone who performs this calculation can therefore generate apparently valid certificates on behalf of the CA for any domain, as long as a browser still trusts the CA. This is precisely why Mozilla and others blocked them immediately.

We downloaded the eight intermediate certificates listed in Bugzilla from the public transparency logs (crt.sh), using their SHA-256 fingerprints. For each one, we compared k · G with the public point for k = 1 to 1000. All eight certificates use a P-384 key, and all eight produced a match:

The values match those reported in Bugzilla and in the coverage (including The Register, which described one of the keys as ‘literally 4’). We have not signed or issued anything using these values; the calculation is solely a check of public certificates.

The cause, according to eMudhra

According to eMudhra's account in Bugzilla, the weak keys originated during a key ceremony on 30 April 2025. A wrap/unwrap test was performed as part of an approved deviation from the standard procedure. A coding error reportedly caused a second key pair with weak keys to be generated inside the device. This was then accidentally used to create the certificate request because the key labels were similar. The certificates were subsequently issued, added to trust stores and remained there for over a year before the error came to public attention.

According to The Register, security researcher Scott Helme discovered the key ‘4’. The primary sources we reviewed do not describe how the flaw was discovered; however, anyone can check for small key values using public certificates.

Who is affected – and who is not?

The chain has three levels: the root CA, the intermediate CA and the website's or server's end-entity certificate. The middle level was affected. This means:

• Certificate holders' keys (your server key) are not affected, according to all the sources available to us. They do not need to be replaced on the grounds that they are ‘known’.
• Zertifikate, die unter der entfernten Root laufen, werden von Browsern nicht mehr akzeptiert. Sie müssen ersetzt werden, weil die Vertrauenskette weg ist, nicht weil der Server-Schlüssel schwach ist. Laut der Analyse des Chrome-Root-Programms (Stand 21.10.2026) betrifft das rund 30.800 noch gültige Zertifikate. 30.791 davon wurden von Unter-CAs von Internet2/InCommon ausgestellt, einem US-Verbund, der vor allem Hochschulen und Forschungseinrichtungen bedient. eMudhra spricht von einem einzigen Kundenverbund in den USA.
• All other eMudhra customers are unaffected, according to eMudhra. Digital signatures, eSign, emSigner, CertiNext, SecurePass, PrivaTrust and emCA continue to operate on separate infrastructure.

Customers in Germany, Austria and Switzerland are therefore unlikely to be using a certificate under this root. The only way to know for certain is to check. It takes just a few minutes; see the checklist.

The 107,107 certificates in the transparency logs

According to Bugzilla, after the revocation, 107,107 certificates signed with six of the eight weak keys appeared in the Certificate Transparency logs between 20 and 21 October 2026. These demonstrably include proof-of-concept certificates, for example with google.com as the name. Most chain through Sectigo's cross-certificates, which have since been revoked.

This shows two things: first, the flaw was immediately exploitable by anyone with a basic knowledge of cryptography; second, it demonstrates the value of transparency logs, which make such certificate issuance visible to everyone. The sources available to us do not establish whether any of these certificates were misused outside testing, and we make no such claim.

What browser vendors and CAs have done

In the discussion on dev-security-policy, Mozilla states that it does not believe other certificate authorities are affected.

Checklist: what you should check now

1. Identify the issuer of your certificates. On any computer with OpenSSL:

   openssl s_client -connect ihre-domain.example:443 -servername ihre-domain.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

   If the issuer is listed as eMudhra or emSign (e.g. ‘EM DV TLS CA – G3B’ or ‘G3C’), use -showcerts to check the entire chain and the root. If it chains to emSign ECC Root CA – G3, the certificate must be replaced.
2. Review all services, not just the website. Mail servers (SMTPS, IMAPS), VPN gateways, firewall interfaces, load balancers, internal services, devices and appliances with their own certificates.
3. View public certificates for your domain. Using crt.sh (search for %.ihre-domain.example), you can see all certificates issued for your domain, including any you are unaware of. This is a good opportunity to spot unwanted certificate issuance.
4. Replace affected certificates. Use another established CA or ACME (e.g. Let’s Encrypt). Generate a new server key at the same time. This incident does not make that mandatory, but it is good practice when switching CAs.
5. Check the trust stores on your own devices. If you have explicitly added the eMudhra root to your own devices, Java keystores, containers or certificate bundles, you should remove it from them. Browsers update their trust stores automatically; these stores do not.
6. Update Firefox. The blocks are included from version 158.0.1 and ESR 115.43.1 / 153.5.1 onwards. On managed workstations, check that updates are being delivered.
7. Automate. If you manage certificates manually, switch to automatic renewal (ACME). Changing CAs then becomes a configuration change rather than an emergency operation.

What we can learn from this

• Choosing a CA is a risk decision. What matters is transparency, process quality and membership of root programmes. A price tag tells you nothing about these. The incident reveals a process failure during a key ceremony that could happen at any CA.
• Certificate Transparency works. The publicly accessible logs made it possible to quickly establish the scope of the incident and identify the 107,107 certificates.
• Cryptographic agility pays off. If you renew certificates automatically and can switch CAs without manually changing dozens of systems, incidents like this take a day's work to resolve rather than a week.
• Monitor your domains. Monitoring the transparency logs (e.g. through crt.sh or services offering email notifications) alerts you when someone issues certificates for your domain.
• Use multiple layers of protection. TLS certificates are just one layer. CAA records in DNS (which specify which CA may issue certificates for your domain) and two-factor authentication provide additional protection. Read more in our article Securing Odoo 19: Firewall, 2FA & Web RBL.

Frequently asked questions

What exactly happened at eMudhra?

Acht Zwischenzertifikate der Zertifizierungsstelle eMudhra hatten private Schlüssel, die ganze Zahlen kleiner als 256 waren (einer: die Zahl 4). Dadurch konnte jeder aus dem öffentlichen Zertifikat den privaten Schlüssel berechnen und gültig aussehende Zertifikate unterschreiben. Die Zwischen-CAs wurden widerrufen, die Root emSign ECC Root CA – G3 wurde aus Firefox (20.10.2026) und Chrome (27.10.2026) entfernt.

Did eMudhra issue the private key ‘4’ to customers?

No. The weak keys belonged to the CA's own intermediate certificates. They were not customer keys and were not issued to customers. Claims to the contrary on social media do not change that.

As an eMudhra customer, do I need to replace my certificate immediately?

Only if your TLS certificate chains up to the emSign ECC Root CA – G3 root. According to eMudhra, this affects a single US customer group with around 30,800 certificates. eMudhra says no action is needed for any other customers. Check your certificate’s issuer before taking action.

How can I tell whether my certificate is affected?

Check the issuer and the certificate chain: view the certificate in your browser or use the OpenSSL command in the checklist. Names such as “EM DV TLS CA – G3B”, “EM OV TLS CA – G3C” or “emSign ECC Root CA – G3” indicate the affected chain.

Do I need to replace my server’s private key?

Nicht wegen dieses Vorfalls. Der Server-Schlüssel ist nach den Quellen nicht betroffen. Beim notwendigen Austausch des Zertifikats empfiehlt sich trotzdem ein neuer Schlüssel.

Can attackers create forged certificates for my domain?

The eight keys could technically be used to sign certificates for any domain. This only worked while browsers trusted the chain. Following the blocks introduced by Mozilla and Chrome, this is no longer possible in up-to-date browsers. The risk may persist for longer on devices that are not updated or have the root explicitly configured as trusted. You should therefore monitor certificates issued for your domain.

Are certificates from Let’s Encrypt or other CAs affected?

Not according to the published sources. Mozilla does not believe other CAs are affected.

What does eMudhra’s withdrawal from the TLS business mean?

eMudhra is no longer issuing new public TLS certificates. Code signing, S/MIME, digital signatures and eSign will continue. Anyone who previously obtained TLS certificates from eMudhra will need a new provider.

Is Odoo affected?

Odoo itself is not affected. However, as with any web application, the TLS certificate for your Odoo domain should come from a trusted CA. Check the issuer, especially if certificates are not renewed automatically.

Sources

Accessed on 6 November 2026:

• Mozilla Bugzilla, bug 2083449 (incident report, timeline, certificate fingerprints): bugzilla.mozilla.org/show_bug.cgi?id=2083449
• Mozilla Security Blog, 20.10.2026: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• eMudhra statement: emudhra.com/en/post/certificate-security-incident
• The Register, 20.10.2026: Indian certification authority eMudhra’s private keys compromised, one of them was the number 4
• Mozilla dev-security-policy: Discussion thread about the incident
• Certificate Transparency search: crt.sh

We calculated the eight key values ourselves using publicly available certificates. Statements about the cause, the non-issuance of end-entity certificates and the number of affected customers come from eMudhra or Bugzilla and have not been independently verified by us.

Support from Biricon IT Services

If you are unsure who issued your TLS certificates, we can help you take stock of all certificates on web servers, mail servers, firewalls and appliances, switch to another CA, set up automatic renewal (ACME) and monitor your domains. As an IT service provider, we manage servers, firewalls and web applications for small and medium-sized businesses.

Get in touch today

Last updated: 6 November 2026. The situation may change; refer to the publications from Mozilla, Google, Apple and eMudhra for authoritative information.