Pratidin
Science and technology22 October 2026The Hindu, NewsGS3

Eight eMudhra certificate keys found trivially weak, and browsers pull their trust

In one line: Eight intermediate certificates of eMudhra, an Indian certifying authority, had private keys smaller than 256, so browsers blocked them and Mozilla moved to distrust one of its roots.

Published 22 October 2026. Written by Pratidin from the reports linked at the end; every fact checked by a separate review before publishing. How we work

Eight intermediate certificates issued under eMudhra, a Bengaluru-based certifying authority (CA), were found to have private keys so weak that anyone could recover them. Mozilla received the report from an external researcher, forwarded by the Chrome Root Program, on 17 October 2026, and independently recovered the keys within hours. The keys were P-384 elliptic-curve keys, which should be random 384-bit numbers; each of the eight was an integer below 256, and one was the number 4. Six of the certificates could sign website (TLS) certificates and were trusted by Chrome, Mozilla, Microsoft and Apple; two were code-signing intermediates trusted by Microsoft.

The response was quick. Mozilla blocked the certificates on 17 October through OneCRL, its revocation list, and Chrome acted the same day. eMudhra revoked all eight on 18 October, Apple added protections on 19 October and Microsoft on 20 October. Mozilla then announced the emergency removal of trust in eMudhra's emSign ECC Root CA - G3. eMudhra told Mozilla that a flaw in the code used during its key generation ceremony on 30 April 2025 created a second, weaker set of keys that was used by mistake. It stopped issuing certificates from its G3 intermediates and estimated that about 30,000 certificates would need to move to another root.

The risk was that an attacker could issue fraudulent HTTPS certificates for websites they do not control. eMudhra said that, according to Certificate Transparency records, only one affected intermediate was in production, and that its Indian digital signature certificate and eSign services were working normally. In India, the Controller of Certifying Authorities (CCA) licenses CAs under the Information Technology Act, 2000; eMudhra is one of them, and the UIDAI website lists it as its certificate issuer. Researchers noted that CERT-In and the CCA had not issued public statements by 21 October, and experts warned that rarely updated devices may keep trusting the revoked certificates.

Practise this in the app: flashcards, quiz and a timed answer
Prelims

Prelims facts

  • Eight eMudhra intermediate certificates had P-384 private keys smaller than 256, recoverable by trying at most 256 values.
  • Six were website (TLS) intermediates trusted by Chrome, Mozilla, Microsoft and Apple; two were code-signing intermediates trusted by Microsoft.
  • Mozilla and Chrome blocked them on 17 October 2026; eMudhra revoked them on 18 October, and Mozilla moved to distrust the emSign ECC Root CA - G3.
  • In India, certifying authorities are licensed by the Controller of Certifying Authorities, appointed under Section 17 of the IT Act, 2000.

Quick recall

How many eMudhra intermediate certificates had compromised keys?
Eight: six for websites (TLS) and two for code signing.
What was wrong with the eMudhra keys?
They were integers below 256 (one was 4) instead of random 384-bit numbers.
When did Mozilla receive the report?
17 October 2026; Mozilla and Chrome blocked the certificates that day.
Which eMudhra root did Mozilla move to distrust?
emSign ECC Root CA - G3.
Under which section of the IT Act is the CCA appointed?
Section 17 of the Information Technology Act, 2000.
Under which provision was the Root Certifying Authority of India set up?
Section 18(b) of the IT Act, 2000.
What does Section 3 of the IT Act, 2000 do?
Gives legal sanctity to digital signatures (authentication of electronic records).
CERT-In's 2022 reporting deadline for cyber incidents?
Six hours from noticing the incident, under directions of 28 April 2022 (Section 70B(6)).

Prelims practice question

With reference to the Controller of Certifying Authorities (CCA) in India, consider the following statements:
1. It is appointed under the Information Technology Act, 2000.
2. It set up the Root Certifying Authority of India, which signs the public keys of licensed certifying authorities.
3. It functions under the Ministry of Home Affairs.
Which of the statements given above are correct?

  1. 1 and 2 only
  2. 2 and 3 only
  3. 1 and 3 only
  4. 1, 2 and 3
Show answer

Answer: (a) 1 and 2 only. Statement 1 is correct: the CCA is appointed under Section 17 of the IT Act, 2000. Statement 2 is correct: the Root Certifying Authority of India was set up under Section 18(b) and signs CAs' public keys. Statement 3 is incorrect: the CCA is under the Ministry of Electronics and Information Technology.

Use this in UPSC Mains: previous-year questions

Recurring theme: Cyber security and digital trust: certifying authorities, digital signatures and incident response

  1. 2022 · GS3 · 15 marksCovers one partUse it in the example

    What are the different elements of cyber security? Keeping in view the challenges in cyber security, examine the extent to which India has successfully developed a comprehensive National Cyber Security Strategy.

    How to use this

    Use the eMudhra case to show that trust infrastructure is an element of cyber security and that India's incident communication remains weak.

    • Eight eMudhra intermediate certificates had private keys below 256; browsers blocked them on 17 October 2026, before any Indian agency spoke publicly.
    • India's certifying authorities are licensed by the CCA under the IT Act, 2000, yet CERT-In and the CCA had issued no public statement by 21 October 2026.
Prelims
  1. 2019 · Prelims

    Consider the following statements: A digital signature is 1. an electronic record that identifies the certifying authority issuing it 2. used to serve as a proof of identity of an individual to access information or server on Internet 3. an electronic method of signing an electronic document and ensuring that the original content is unchanged Which of the statements given above is/are correct? (a) 1 only (b) 2 and 3 only (c) 3 only (d) 1, 2 and 3

Mains practice question

What is the role of certifying authorities in securing digital transactions? In the light of the recent compromise of certificate keys at an Indian certifying authority, suggest measures to strengthen India's digital trust infrastructure. (250 words)

Model answer

Certifying authorities (CAs) vouch that a public key belongs to a particular website or person. In October 2026, eight intermediate certificates of eMudhra, an Indian CA, were found to have private keys smaller than 256, recoverable by anyone.

Role of certifying authorities

  • Identity: they bind identities to public keys through certificates, making HTTPS, code signing and digital signatures trustworthy.
  • Legal basis in India: Section 3 of the IT Act, 2000 recognises digital signatures; the Controller of Certifying Authorities (Section 17) licenses CAs, and the Root Certifying Authority of India (Section 18(b)) signs their keys.
  • E-governance: digital signature certificates and eSign support filings and authentication; the UIDAI website lists eMudhra as its certificate issuer.

What the eMudhra case reveals

  • Process failure: eMudhra blamed flawed key generation code; a P-384 key should be a random 384-bit number.
  • Global dependence: browser root programmes, not Indian regulators, acted first: Mozilla and Chrome on 17 October 2026, Apple and Microsoft by 20 October.
  • Long tail: rarely updated devices may keep trusting revoked certificates.
  • Communication gap: CERT-In and the CCA had issued no public statement by 21 October.

Measures

  • Independent audits of key ceremonies, with keys generated inside certified hardware security modules.
  • Mandatory, prompt public disclosure of CA incidents, coordinated by CERT-In and the CCA.
  • Trust-store update rules for government systems and connected devices.
  • Use of Certificate Transparency logs to detect misissued certificates early.

Digital trust is only as strong as its weakest key, so India's CA ecosystem needs audit, transparency and fast response.

The basics

Why this matters

Every time a browser shows a padlock, it is trusting a chain of digital certificates. If the secret key behind one link in that chain leaks, anyone holding it can issue certificates that browsers accept, and so pretend to be a bank, a ministry or an email provider. In October 2026 eight such keys belonging to eMudhra, a Bengaluru-based certifying authority, were found to be so weak that they could be guessed in moments.

How the chain of trust works

The system is called Public key infrastructure. Browsers ship with a short list of trusted root certificates. Roots sign intermediate certificates, and intermediates sign the certificates that websites present. A certificate is only as safe as the Private key that signs it.

The web's chain of trust
  1. 1Root certificateKept offline and built into browsers and operating systems as a trust anchor.
  2. 2Intermediate certificateSigned by the root; does the day-to-day signing of website certificates. eMudhra's eight compromised keys were at this level.
  3. 3Website (TLS) certificatePresented by a website to prove its identity and set up an encrypted connection.
  4. 4Root programmesMozilla, Google Chrome, Apple and Microsoft decide which roots their software trusts.

What went wrong

The eight keys were P-384 keys, a type of elliptic-curve key that should be a random 384-bit number. Instead, each was an integer below 256. One was the number 4. Anyone could recover such a key by trying at most 256 values.

A proper key and eMudhra's eight keys
What a P-384 private key should be
  • A random 384-bit number
  • Far too many possibilities to guess
vs
What the eight keys were
  • Integers smaller than 256, one of them 4
  • Recoverable by trying 256 values

How the system responded

Mozilla received the report on 17 October 2026 and blocked the certificates the same day through OneCRL, its revocation list. Chrome also acted on 17 October, eMudhra revoked the eight certificates on 18 October, Apple followed on 19 October and Microsoft on 20 October. Mozilla then announced the emergency removal of trust in eMudhra's emSign ECC Root CA - G3.

The eMudhra key compromise, 2025 to 2026
  1. 30 April 2025Eight weak intermediate keys generated in a batch of 24
  2. 17 October 2026Mozilla receives the report; Mozilla and Chrome block the certificates
  3. 18 October 2026eMudhra revokes all eight certificates
  4. 19 to 20 October 2026Apple and Microsoft add protections
  5. 21 October 2026eMudhra says its Indian digital signature and eSign services are working normally

The Indian frame

In India, digital signatures get legal force from the Information Technology Act, 2000, and certifying authorities are licensed by the Controller of Certifying Authorities. The weakness raised a wider Cyber security question: how many systems that rarely update their trust lists will keep accepting the bad certificates.

Go deeper

Why it matters for UPSC

Digital certificates underpin online banking, e-governance and digital signatures. The episode is a ready example for GS3 questions on cyber security and digital trust, and for Prelims questions on digital signatures and certifying authorities under the IT Act, 2000.

The core idea

Web security rests on Public key infrastructure: browsers trust a few roots, roots vouch for intermediates, and intermediates vouch for websites. Each link depends on a secret Private key. eMudhra's eight keys, generated on 30 April 2025, were tiny numbers, so anyone could recover them and issue certificates browsers would accept. In India, certifying authorities are licensed by the Controller of Certifying Authorities, and the incident adds to the country's Cyber security agenda.

Numbers and dates to remember

  • 8 intermediate certificates compromised: 6 for websites (trusted by Chrome, Mozilla, Microsoft and Apple), 2 for code signing (trusted by Microsoft).
  • Keys were integers below 256; one was 4. A P-384 key should be a random 384-bit number.
  • 17 October 2026: report to Mozilla; Mozilla and Chrome block. 18 October: eMudhra revokes. 19 October: Apple. 20 October: Microsoft.
  • About 30,000 certificates to migrate, by eMudhra's estimate.
  • CCA office set up on 1 November 2000.

Where to go next

Go deeper: a single weak link and the limits of trust

How serious was it? By eMudhra's account, based on Certificate Transparency records, only one affected intermediate was in production use, and it found no evidence that the weak keys issued certificates to end users. The risk was that anyone holding the keys could issue fraudulent certificates that browsers would accept. Because the keys were recoverable by anyone, Mozilla said multiple people had independently recovered them.

What caused it? eMudhra told Mozilla that a flaw in the code used in its key generation ceremony created a second, weaker pair of keys, which was used by mistake. Root programmes have asked eMudhra to explain how the keys were generated and which hardware security modules were used. The investigation was still open when the news broke.

Why the response was fast. The Public key infrastructure has a kill switch: browsers can block certificates centrally. Mozilla and Chrome acted within hours of the 17 October report. The weakness is the long tail: Internet of Things devices, containers and old software that rarely update their trust lists may keep trusting revoked certificates.

The Indian angle. eMudhra says its Indian digital signature certificate and eSign services were not affected, and that the global web certificate business is about 1% of its revenue. Researchers noted that neither CERT-In nor the Controller of Certifying Authorities had issued a public statement by 21 October. The case shows why random Private key generation and independent audit matter for Cyber security.

Public key infrastructure

The system of roots, intermediates and certificates behind the padlock.

In one line: Public key infrastructure (PKI) is the set of certificates, authorities and rules that lets a computer check that a public key really belongs to the website or person it claims to.

How it works

A certifying authority (CA) checks an applicant's identity and signs a certificate binding that identity to a public key. Browsers and operating systems ship with a list of trusted root certificates. Roots sign intermediates, and intermediates sign end-user certificates. A browser accepts a website only if it can trace the website's certificate back to a trusted root.

Why it is in the news

eMudhra's compromised keys were at the intermediate level. Because browsers trusted those intermediates, a stolen key could produce website certificates that browsers would accept. Root programmes run by Mozilla, Google, Apple and Microsoft decide which roots are trusted, and they can revoke trust quickly.

Where to go next

Private key

Why a key must be random and secret, and what tiny keys break.

In one line: A private key is the secret half of a key pair; whoever holds it can sign data that others will accept as genuine.

Randomness is the security

Public key cryptography is safe only if the private key cannot be guessed. A P-384 key, used in elliptic-curve cryptography, should be a random number about 384 bits long, which gives far too many possibilities to try. If the key is a small number, an attacker can simply try every candidate.

The eMudhra case

Each of eMudhra's eight affected keys was an integer below 256, and one was the number 4. They could be recovered by trying at most 256 values, almost instantly. eMudhra blamed a flaw in the code used during its key generation ceremony, the formal process in which a CA creates its keys.

Where to go next

Controller of Certifying Authorities

India's regulator for certifying authorities under the IT Act, 2000.

In one line: The Controller of Certifying Authorities (CCA), appointed under Section 17 of the Information Technology Act, 2000, licenses and regulates the certifying authorities that issue digital signature certificates in India.

Legal basis

Section 3 of the IT Act gives legal recognition to digital signatures. The CCA, under the Ministry of Electronics and Information Technology, set up the Root Certifying Authority of India under Section 18(b) of the Act; it signs the public keys of licensed CAs. The office came into existence on 1 November 2000. It also maintains a repository of certificates issued to CAs.

Why it is in the news

eMudhra is one of the CAs licensed by the CCA. The compromised intermediates belonged to eMudhra's emSign hierarchy that browsers trust, and eMudhra says its Indian digital signature and eSign services were not affected.

Where to go next

Cyber security

The Indian institutions and rules that respond to cyber incidents.

In one line: Cyber security is the protection of systems, networks and data from attack, and in India it rests on the IT Act, 2000, CERT-In and sectoral regulators.

Key institutions

CERT-In, the Indian Computer Emergency Response Team, is the national agency for incident response. Its directions of 28 April 2022, issued under Section 70B(6) of the IT Act, require cyber incidents to be reported to it within six hours of being noticed. The CCA regulates certifying authorities.

Why it is in the news

The eMudhra case shows a supply-chain risk: one weak link in a CA can undermine trust in many websites. Researchers noted that neither CERT-In nor the CCA had issued a public statement about it by 21 October 2026, and the Internet Freedom Foundation said it would write to MeitY, the CCA and CERT-In.

Where to go next

Syllabus

Related stories

Sources used for this summary