The key
was 4.

That is not a typo. Let's build up, from zero, why this one number put the whole web at risk.

The internet is a chain of machines that pass your data along, like a bucket brigade.

Your message hops from machine to machine before it reaches the bank.

Every machine on the path can read it, copy it, or change it.

And any one of them could be an attacker. You cannot see which.

Encryption gives the first two. Certificates give the third. eMudhra's mistake broke the third, for every website.

You and the bank both hold the same secret key.

The key scrambles your message into nonsense.

Mallory sees only nonsense on the wire.

The bank uses the same key to unscramble it. This is fast and strong.

But how did the bank get the key? It had to travel over this same wire…

…and Mallory copied it. To share a secret safely, you first need a secret. Chicken and egg.

The bank makes two linked keys: a private key it keeps, and a public key that works like an open padlock.

It hands copies of the padlock to anyone who asks. Even Mallory. That is fine.

You put your message in a box and snap the bank's padlock shut.

The box crosses the wire. Mallory's padlock copy cannot open it.

Only the private key opens it. Public key locks; private key unlocks.

A signature proves who wrote something. The proof is only as safe as the private key.

If every atom in the universe were a computer guessing a billion keys a second since the Big Bang, together they would still not finish.

Unless the key is a small number. Then a laptop finishes before you blink.

You ask the bank for its public key (its padlock).

Mallory keeps the bank's padlock and sends you her own instead. They look the same.

You lock your message with Mallory's padlock, believing it is the bank's.

Mallory opens it with her own private key and reads everything.

She re-locks it with the real bank padlock and passes it on.

Nobody notices. Encryption to the wrong person is worthless. We need proof that a public key really belongs to the bank.

The officer never met you, but trusts whoever made your passport. Your browser never met bank.com, but trusts whoever signed its certificate.

1. The server makes its own key pair. The private key never leaves the server.

2. It writes a request (a CSR): "Please certify that this public key belongs to www.bank.com."

3. The request goes to a certificate authority.

4. The CA sets a test that only the real owner of bank.com can pass.

5. The server passes the test. The CA's machines check it from outside.

6. The CA signs the certificate with the CA's private key and sends it back.

7. The server installs it and shows it to every visitor. With ACME automation, all of this takes seconds.

CAs sell this as a business. Website owners pay (or use a free CA like Let's Encrypt). Browsers decide which CAs to trust.

eMudhra failed at job 3: the keys were not created correctly.

Google buys its certificate from one CA. But that is not a rule the browser checks…

…every trusted CA is technically able to sign a certificate for every website name.

So the whole web is only as strong as the weakest CA on the list. One broken CA key is a master key.

Each device ships a list of trusted "root" certificates. To stay on it, a CA must follow shared rules (the CA/Browser Forum Baseline Requirements) and pass audits every year. eMudhra's emSign ECC Root CA - G3 was on these lists.

The browser checks maths, not honesty. Anyone holding the intermediate's private key can make these checks pass.

First the browser asks DNS, the internet's phone book, for bank.com's address.

Then TCP opens a reliable pipe with three tiny packets. Nothing is secret yet.

The very first TLS message is the ClientHello. Here the security conversation begins.

With HTTP/3, the pipe uses QUIC instead of TCP, but the same TLS 1.3 messages travel inside it.

Start with a paint colour everyone knows. It is public.

Each side secretly picks its own colour. Secrets never leave home.

Each side mixes its secret into the public paint. Mixing is easy.

They swap the mixtures in public. Mallory sees both.

Each adds its own secret to what it received. Both get the same brown!

Un-mixing paint is hard. Mallory saw everything but cannot make the brown.

In real life: paint = point G · secrets = a, b · mixes = A = a×G, B = b×G · brown = a×b×G. This is Diffie–Hellman key exchange.

Same number on both sides, and it never crossed the wire.

A key-derivation function stirs the shared secret with a fingerprint of the conversation.

Out come the session keys: one for each direction.

Mallory has only A and B. To get the secret she must go backwards from A to a. With real-size numbers, she can't.

Your browser wants to send a normal web request.

It encrypts the request with the browser → server session key.

On the wire it is noise, plus a short "tag", a tamper seal made with the key.

The server decrypts it and checks the tag. ✓

If anyone changes even one bit, the tag check fails and the connection is closed.

Secrecy ✓ Integrity ✓. Symmetric keys do the heavy lifting because they are very fast.

Your ClientHello reaches Mallory instead of the bank.

She answers with her own key share M, as if she were bank.com.

You now share a perfect secret… with Mallory. She makes a second one with the bank.

Key exchange gives secrecy with whoever answered. It says nothing about who answered. This is where certificates come in.

The server sends its certificate chain. This is the first moment the CA's work enters the conversation.

Then it signs the whole conversation, including the key shares, with its private key.

The browser checks all three. So the key share B really came from whoever holds bank.com's private key.

Finally, each side sends "Finished": a checksum of the whole handshake. Then the padlock appears.

Mallory can't sign as bank.com… unless a trusted CA gives her a certificate for bank.com with a key she owns.

{ } = encrypted with handshake keys · [ ] = encrypted with session keys · about 50 ms in total.

Everything secret was set up by the key exchange. Everything about who rests on two violet lines, and they rest on a CA.

A small part of their business. But inside your browser's trust list, a small CA has exactly the same power as the biggest one.

eMudhra's weak keys: 47 bytes of zero, then one small byte.

Values published by researchers. Every one is below 256: it fits in a single byte.

One byte = 256 possibilities. A combination lock with 256 settings, guarding certificates for the whole web.

Each intermediate also had a twin certificate, cross-signed in May 2025 by Sectigo's older "AAA Certificate Services" root. Same key.

None of these sites ever used eMudhra.

It does not matter. These intermediates had no name limits, so one key could sign a certificate for any of them.

For about 17½ months, anyone who looked could have computed these keys.

eMudhra and India's IT ministry say Indian digital-signature and eSign services are separate and were not affected.

eMudhra revoked the eight intermediates and listed them in its cancelled list (CRL).

Software can also ask the CA live (OCSP): "is this certificate still good?"

But an attacker in the middle can simply block the question.

Most software "fails open": no answer means carry on. And many apps never ask at all.

So browser makers built their own block lists, pushed straight into the browser.

Browsers: protected within hours to days, mostly without users doing anything.

Browsers update themselves. Everything else waits for someone to ship, and someone else to install, an update.