Security • DevSecOps • eMudhra • SSL/TLS • HTTPS • Certificate Authority • PKI • Kubernetes • Docker • Linux

SSL/TLS Certificates Explained, and What the eMudhra CA Key Compromise Incident Means for You

Oct 21, 2026 • 14 min read

In October 2026, security researchers found that the secret keys of eight certificates belonging to eMudhra, an Indian company that the internet trusts to vouch for websites, were so weak that anyone could work them out in a fraction of a second. One of those keys was literally the number 4.

Browsers reacted within hours. But a lot of other software, including servers, containers, and Kubernetes clusters, needs updates too.

To understand why this matters, you first need to understand how the padlock in your browser actually works. So this post starts from zero. No security background needed. Whenever a short form appears, I write the full form next to it.

Note: this story is only a few days old and details are still coming in. Check the sources at the end for the latest.

Part 1: How HTTPS and certificates work

The problem: how do you trust a stranger on the internet?

When you type example.com, your browser connects to a computer somewhere in the world. Two worries come up straight away:

  1. Is this really example.com, or an impostor?
  2. Can someone in between (public Wi-Fi, an internet provider, an attacker) read or change what we send?

HTTPS (HyperText Transfer Protocol Secure) solves both. It uses two ideas:

  • Encryption scrambles the data so only you and the website can read it.
  • Certificates are identity cards that prove who the website is.

The security layer underneath HTTPS is called TLS (Transport Layer Security). Its older name was SSL (Secure Sockets Layer), which is why people still say "SSL certificate" even though modern sites use TLS.

The key idea: public and private keys

Everything rests on one clever piece of maths called a key pair:

  • A private key is a secret number. Only the owner knows it.
  • A public key is calculated from the private key. It can be shared with everyone.

Going from private key to public key is easy. Going backwards, from public key to private key, is practically impossible. But only if the private key was chosen properly. Remember this, because it is the whole story of the eMudhra problem.

With a key pair you can do two things:

  • Sign something using the private key. This creates a digital signature that only the owner could have made.
  • Verify a signature using the public key. Anyone can check that it is genuine.

A simple example: think of a wax seal on a royal letter. Only the king has the seal stamp (private key). Everyone knows what the king's seal looks like (public key). Anyone can check a seal is real, but nobody can fake one without the stamp. And if someone edits the letter after it was sealed, the seal no longer matches.

What is a certificate?

A digital certificate is a small file that says: "This public key belongs to example.com," along with a signature from a trusted organisation. It contains:

  • The website's name
  • The website's public key
  • Start and expiry dates
  • Who issued it
  • The issuer's digital signature

Think of it like a passport: your name and photo (website name and public key), an expiry date, and the stamp of the government that issued it (the signature).

Who issues certificates? Certificate Authorities

A Certificate Authority (CA) is an organisation that checks a website really belongs to the person asking, and then signs a certificate to confirm it. Examples are Let's Encrypt (free and automatic), DigiCert, Sectigo, and eMudhra.

Why does your browser trust them? Because browser makers (Google, Mozilla, Apple, Microsoft) keep a strict list of CAs they trust and audit them. If a CA does something dangerous, it can be removed from the list. That is exactly what is happening with eMudhra.

The chain of trust: Root, Intermediate, and Website

Certificates are arranged in three levels, like a chain of authority:

Root CA certificate           (the ultimate authority)
        |  signs
        v
Intermediate CA certificate   (does the daily signing work)
        |  signs
        v
Website certificate           (belongs to example.com)

Root certificate

  • The top of the chain.
  • Its public key is already installed inside your browser and operating system.
  • Its private key is extremely valuable, so it is kept offline inside a Hardware Security Module (HSM), which is a tamper-proof safe for keys. It is used only on rare, carefully supervised occasions.

Intermediate certificate

  • Signed by the root.
  • Used every day by the CA to sign thousands of website certificates.
  • Why does it exist? If the root key were used daily, one mistake could ruin trust for every certificate under it. An intermediate is a protective buffer: if one has a problem, the CA can cancel it without losing the root.
  • Its private key is also stored in an HSM, but one that is online.

Website certificate

  • Signed by an intermediate.
  • Holds the website's public key.
  • The website's private key stays on the web server (or with your hosting platform).
Who owns which key, and where is it?

This is the part most people find confusing, so here it is plainly.

Root

  • Private key: owned by the CA, kept offline in an HSM.
  • Public key: pre-installed in your browser and operating system.

Intermediate

  • Private key: owned by the CA, kept in the CA's HSM.
  • Public key: inside the intermediate certificate, which the website's server sends to your browser when you connect.

Website

  • Private key: owned by the website owner or hosting provider (Vercel, AWS, Cloudflare, or your own server). Stays on the server.
  • Public key: inside the website certificate, which the server sends to your browser when you connect.

The important rules:

  • Private keys never leave their owners. Nobody ever sends a private key to a browser.
  • Your browser already has the root public key before you visit anything.
  • The server stores the website certificate and the intermediate certificate, and hands both to the browser at the start of every connection. They only contain public information, so there is no secret in them.
How a website gets a certificate

Say you own example.com and want HTTPS. Here is what happens:

Step 1: Create a key pair. Your server creates a private key and a matching public key, using a method such as ECDSA (Elliptic Curve Digital Signature Algorithm, modern and fast) or RSA (Rivest–Shamir–Adleman, older but still common). The private key must be created with proper randomness.

Step 2: Create a CSR. A Certificate Signing Request (CSR) is a file containing your public key and domain name, signed with your private key. It says: "Please certify that this public key belongs to example.com."

Step 3: Send the CSR to a CA. For example Let's Encrypt or eMudhra.

Step 4: Prove you control the domain. Anyone can write someone else's domain into a CSR, so the CA must check. Two common ways:

  • HTTP challenge: the CA gives you a random code and asks you to place it at a special address on your website, like http://example.com/.well-known/acme-challenge/some-code. The CA visits that address. If the code is there, you control the website. This is the most common method.
  • DNS challenge: the CA asks you to add a special TXT record to your domain's DNS (Domain Name System) settings. DNS is the internet's phone book, which turns names into addresses. If the CA finds the record, you control the domain. This is needed for wildcard certificates like *.example.com.

Step 5: The CA signs. Once satisfied, the CA signs your certificate using its intermediate private key.

Step 6: Install. The CA gives you back your website certificate plus the intermediate certificate. You install both on your server, next to the private key you created in Step 1. The CA never sees your private key.

If you host on Vercel, Netlify, or Cloudflare, all of this is automatic. Vercel talks to Let's Encrypt using a protocol called ACME (Automatic Certificate Management Environment), completes the challenge, installs the certificate, and renews it before it expires. You never touch a key.

Some certificates need more checking than others:

  • DV (Domain Validation): checks that you control the domain.
  • OV (Organization Validation): also checks the company behind it.
  • EV (Extended Validation): the strictest identity checks.
What happens when you open https://example.com

Here is the whole journey in order:

  1. DNS lookup. Your browser asks, "What is the IP (Internet Protocol) address of example.com?" and gets a numeric address back.
  2. Basic connection. The browser connects to that address using TCP (Transmission Control Protocol), the standard way computers make a reliable connection. This connection is not secure yet.
  3. Certificates are sent. The server sends its website certificate and the intermediate certificate. It does not send the root, because your browser already has it.
  4. The browser checks the chain, using public keys only. It confirms that the website certificate was really signed by the intermediate, that the intermediate was really signed by a root it already trusts, that the name matches example.com, that the dates are valid, and that the certificate has not been cancelled.
  5. The server proves it owns the certificate. A certificate is public, so anyone could copy one. The server therefore signs a piece of handshake data with its website private key, and the browser checks that signature using the website public key. Only the real owner can do this.
  6. Session keys are created. Both sides agree on temporary secret keys for this visit.
  7. Encrypted browsing. Everything from now on is encrypted. The padlock appears.

If any check fails, you see the "Your connection is not private" warning.

Which private key is used when?

  • Root private key: only to sign intermediates. Rarely used. Not used when you browse.
  • Intermediate private key: only when the CA issues a new website certificate. Not used when you browse.
  • Website private key: used in every secure connection to prove the server owns the certificate.

The golden rule: checking needs only public keys. Signing needs the private key.

What if someone edits a certificate?

If an attacker changes the public key, the name, or anything else inside a certificate, the issuer's signature no longer matches, and the browser rejects it. The attacker cannot make a new valid signature without the issuer's private key.

This is why the system is safe even though certificates are public. And it is also why a guessable CA private key is a disaster: it lets attackers create brand-new certificates with perfectly valid signatures.

Part 2: What went wrong at eMudhra

Who is eMudhra?

eMudhra is a technology company from Bengaluru, India, founded in 2008. It is a Certificate Authority that sells certificates under the emSign brand, and it also offers digital signatures, e-signing, code signing, and identity services. Its certificates are trusted by major browsers and operating systems.

Unlike Let's Encrypt, which is a free non-profit focused on website HTTPS, eMudhra is a commercial company with a wider range of products, including enterprise and government work.

What happened

On 17 October 2026, a security researcher known as Wayne noticed something alarming in public certificate data: eight eMudhra intermediate certificates had tiny, guessable private keys.

A proper private key for this kind of cryptography (the P-384 elliptic curve) is a huge random number with around 10 to the power of 115 possibilities, which is far too many for anyone to search. But these eight keys were numbers below 256. One of them was just 4.

A simple example: imagine a safe that should have a 115-digit combination, but whose real combination is "004". Anyone could open it in seconds. Here, an attacker only needs to try about 255 possibilities until the matching public key shows up, and a computer does that in milliseconds.

What "compromised" means here

The public certificates were visible to everyone, so anyone could work out the private keys from them. With an intermediate's private key, an attacker could sign fake certificates for any website: your bank, Google, a government portal. To a browser that trusted the chain, those fakes would look real.

The eight certificates

Six of them issue website (TLS) certificates, and two issue code-signing certificates (used to prove software really comes from its publisher):

  • EM DV TLS CA - G3B and G3C
  • EM OV TLS CA - G3B and G3C
  • EM EV TLS CA - G3B and G3C
  • EM OV CS CA - G3B and G3C (code signing)

They were created in April 2025, so the weakness existed for roughly 17 months before anyone noticed. The six website ones chain up to a root called emSign ECC Root CA - G3. Each also exists as a second version that was cross-signed by another CA, Sectigo.

How did it happen?

Reporting so far says this was a mistake in how the keys were created, not a hacker breaking in. eMudhra has pointed to a bug in the script used during its April 2025 key ceremony, which is the formal, supervised event where CA keys are created. Exactly how the bad values came about is not fully public yet.

It is also important to know that the maths itself was not broken. The P-384 curve is fine. The keys were simply chosen terribly.

How serious is it, and who is affected?

What could go wrong: someone holding these keys could create fake certificates that vulnerable software would trust, allowing impersonation and "man-in-the-middle" attacks (secretly sitting between you and a website).

What reduces the danger:

  • Chrome reported that no website certificates chaining to the six affected website-issuing intermediates had been recorded in Certificate Transparency (CT) logs before it blocked them. CT is a set of public logs where issued certificates are recorded, and major browsers require it. So browsers that require CT would not have trusted forged certificates by default.
  • The researcher reported the problem responsibly, and browsers blocked the certificates within hours.
  • Chrome checked every other CA in its list and found no other cases like this.

Who still carries risk: software that does not get cancelled-certificate updates and does not require CT. That includes many things outside the browser: programs written in Go, Python scripts, command-line tools, containers with old certificate bundles, and internal services. This is why the cleanup is bigger than "the browsers fixed it."

Who is directly affected: anyone holding certificates issued by eMudhra (including code-signing certificates) will need to move to new ones. eMudhra has reportedly said about 30,000 certificates need to migrate, though that number has not been independently confirmed.

What companies did

Timeline (all in October 2026):

  • 17 Oct: The researcher reports the problem. Chrome and Firefox block the certificates within hours. eMudhra cancels (revokes) them.
  • 19 Oct: Apple blocks them. Other operating system and browser teams are notified.
  • 20 Oct: Microsoft blocks them. Mozilla and Chrome publicly confirm the problem. Go and other projects release fixes. Mozilla removes the whole emSign ECC Root CA - G3 root from its trusted list.

How the browsers did it: Firefox and Chrome keep block lists called OneCRL and CRLSet, which are sent to the browser automatically. So browser users did not need to update or restart anything.

What software projects did (as reported on 20 to 21 October 2026):

  • Go (versions 1.27.3 and 1.26.10): now rejects any certificate chain that contains one of the eight keys. This fix is tracked as CVE-2026-111943 (Common Vulnerabilities and Exposures, the public ID system for security flaws). Go programs must be rebuilt with the new version to get the fix.
  • Firefox (158.0.1 and supported ESR releases): includes the block list for setups where automatic updates of block lists are switched off.
  • NSS (Network Security Services, Mozilla's crypto library, version 3.131.1): removes the emSign ECC Root CA - G3 root.
  • Python certifi (2026.10.19): removes that root from its certificate bundle.
  • Rust webpki-roots (1.0.10): removes that root.
  • Homebrew ca-certificates: removes that root plus two related ones.
  • Node.js and Composer ca-bundle: fixes were proposed or still in progress at the time of writing, so check their status.

Removing a whole root is a bigger step than blocking eight intermediates, because it also cuts off legitimate certificates under that root. Some websites may fail for some tools until they move to new certificates.

One more point from the Go maintainers: Linux's system certificate lists are not good at passing "this certificate is cancelled" information down to applications. So for now, putting the bad keys directly into the code, or removing the root, is the only reliable fix for many programs.

Part 3: What you should do

First, check whether you are affected

Ask yourself three questions:

  1. Do I use certificates issued by eMudhra or emSign? (For websites, internal services, or code signing.) If yes, you need to replace them. See the last section.
  2. Do my servers, containers, or apps make outbound secure connections? They all trust some certificate list. If it is out of date, patch it.
  3. Do I build or ship Go programs? They need a rebuild with a fixed Go version.

If your own websites use Let's Encrypt or another unaffected CA, your own certificates are fine. Your job is just to keep your trust lists and software up to date.

Linux servers

1. Check whether your certificate list contains the affected roots:

awk -v cmd='openssl x509 -noout -subject' \
  '/BEGIN/{close(cmd)}; {print | cmd}' /etc/ssl/certs/ca-certificates.crt \
  | grep -i -E 'emsign|emudhra'

On RHEL-family systems the file is usually /etc/pki/tls/certs/ca-bundle.crt.

2. Update the certificate package. Check your distribution's security notices first, because some may take a little while to publish updates.

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

# RHEL / Rocky / Alma / Fedora
sudo dnf update ca-certificates
sudo update-ca-trust

# Alpine
apk add --upgrade ca-certificates

3. Find out which Go version built your programs:

go version -m /path/to/binary | head -n 3

If it is older than Go 1.27.3 or 1.26.10, rebuild with a fixed version. Go 1.25 and older no longer get fixes, so upgrade to a supported release.

4. Update Python's certificates:

pip install -U certifi
python -c "import certifi; print(certifi.__version__)"

You want 2026.10.19 or newer. Also check any app that ships its own bundled certificates.

5. Restart services. A running program may keep using the old certificate list until it restarts.

6. See which certificates your own services use:

openssl s_client -connect yourhost:443 -servername yourhost -showcerts </dev/null 2>/dev/null \
  | grep -E '^( [0-9] s:|   i:)'

Look for names containing eMudhra, emSign, or EM DV TLS, EM OV TLS, EM EV TLS.

Containers (Docker and similar)

Containers are the easiest place to get caught out. The certificate list is frozen inside the image when it is built. Updating the host server does nothing for containers that were already built.

  1. Rebuild your images with fresh base images: 
    docker build --pull --no-cache -t myapp:fixed .
  2. Use updated base images (Alpine, Debian, Ubuntu, distroless, and so on) that contain a fresh ca-certificates package.
  3. Rebuild Go programs inside your Dockerfile using a fixed Go builder image (1.27.3 or 1.26.10 or newer).
  4. Scan your images. Tools like Trivy or Grype can spot vulnerable Go versions inside compiled programs. Look for CVE-2026-111943. 
    trivy image myapp:latest
  5. Check for custom certificate files you copy or mount into containers, and replace them with updated ones.
  6. Redeploy everywhere the image runs. A fixed image that nobody deploys protects nothing.
  7. Update your CI/CD (Continuous Integration / Continuous Delivery) build images too, since your build machines also make secure connections.
Kubernetes (K8s)

Kubernetes spreads certificates and trust lists across many places, so go through them one by one.

1. Your workloads (pods). Same as containers: rebuild images, use updated base images, and roll them out with your normal process, for example:

kubectl rollout restart deployment/your-app

2. Cluster tools written in Go. Kubernetes itself, ingress controllers, cert-manager, service meshes, and operators are mostly Go programs. Check each project's release notes for builds made with a fixed Go version, and plan upgrades. Do not assume they are already updated.

3. Find eMudhra certificates stored in the cluster. TLS secrets hold certificates. This command prints who issued each one:

kubectl get secrets -A --field-selector type=kubernetes.io/tls -o json \
| jq -r '.items[] | "\(.metadata.namespace) \(.metadata.name) \(.data["tls.crt"])"' \
| while read ns name crt; do
    printf '%s/%s: ' "$ns" "$name"
    echo "$crt" | base64 -d | openssl x509 -noout -issuer 2>/dev/null
  done | grep -i -E 'emsign|emudhra|EM (DV|OV|EV) TLS'

4. Check certificate lists you hand out. Look at ConfigMaps and Secrets that hold CA bundles, tools like trust-manager, and any service mesh or sidecar that loads its own list. Replace any that still include the affected roots.

5. Check ingress and load balancers. If your ingress, API gateway, or cloud load balancer uses an eMudhra certificate, plan to replace it. Also check outside services your pods call (partners, payment gateways, government APIs). If they change certificates suddenly, clients with old trust lists may fail.

6. Check your nodes. Each node's operating system has its own certificate list. Update it with your normal node patching, or roll out a new node image.

Things to watch out for
  • Removing a root can break legitimate sites. After updating, test your important outbound connections.
  • "Updated" must mean "running." A patched file on disk does not help a program that is still running with the old list. Restart it.
  • Cancelling a certificate is not enough on its own. Browsers get block lists pushed to them. Much other software does not. That is why library, runtime, and certificate-list updates matter.
  • Never "fix" it by turning off certificate checks (for example curl -k, verify=False, or InsecureSkipVerify). That makes things far worse.
  • Looking back is hard. Apart from searching CT logs (which only cover certificates that were logged), there is no simple way to detect whether the keys were misused in the past.
If you use eMudhra / emSign certificates
  1. List every certificate issued by eMudhra or emSign: websites, internal services, code signing, and document signing.
  2. Contact eMudhra for their reissue and migration guidance, and watch their official notices.
  3. Consider switching CA, or using automatic certificate issuance (ACME) from a CA like Let's Encrypt for ordinary website certificates. Automation makes future CA changes much less painful.
  4. Replace the certificate and chain on servers, load balancers, and Kubernetes secrets, then restart or reload services.
  5. For code signing, ask eMudhra and your platform vendors how software that is already signed will be treated, and re-sign it if needed.
  6. Set up expiry monitoring so a certificate change never turns into an outage.

Key takeaways

  • A certificate is an identity card for a website. A Certificate Authority (CA) signs it. Trust flows down a chain: Root, then Intermediate, then Website.
  • Private keys stay secret with their owners. Public keys are shared. Browsers check certificates using public keys only. The website's private key is used to prove ownership during the connection.
  • The whole system depends on CA private keys being truly random and secret.
  • eMudhra's eight intermediate private keys were tiny numbers (one was 4) because of a key-creation mistake in April 2025, so anyone could work them out. Browsers and software makers blocked them within hours, and Mozilla and Chrome moved to distrust the emSign ECC Root CA - G3 root.
  • Browsers are protected automatically. Servers, containers, Kubernetes clusters, and apps need updates: certificate lists, language runtimes (especially Go, which needs a rebuild), and base images.
  • If you hold eMudhra certificates, plan a migration.

Sources and further reading

All accessed 20 to 21 October 2026:

This post explains the issue for general readers. It is not an official security advisory. For production decisions, rely on your vendors' own notices, since versions and details may change as the investigation continues.

← Back to Blog