eMudhra CA Compromise: Browsers Are Fixed, Your Images Are Not

Eight intermediate certificate authorities were issued last year with private keys anybody could work out. CERT-In's advisory puts it plainly: the P-384 elliptic-curve private keys "had values smaller than 256 and could be recovered almost instantly from their corresponding public keys". Firefox users were protected within three hours.

That is where most coverage of the eMudhra CA compromise stops, and where the work in a regulated AWS account starts. Browsers look after their own trust lists. The CA bundle baked into your container images does not, nor the cacerts file in a Java base image, nor a certifi wheel pinned in March.

So the position. Treat this as an inventory job rather than a patch. By Friday you want two lists: what you serve that chains to emSign, and what you still run that trusts it.

What did the eMudhra CA compromise actually expose?

Not a weakness in P-384, and not the root keys. A script.

eMudhra's own statement on the incident says "private keys associated with eight of our emSign G3 intermediate TLS CAs were recoverable", traced to a key generation ceremony where a wrap and unwrap step "produce[d] a second set of weak keys". That ceremony was on 30 April 2025. The certificates were revoked on 18 October 2026, inside fourteen hours of the company confirming the problem.

Hold those two dates next to each other. Eighteen months, and the detection came from outside. Mozilla's account of the response opens "On Saturday, October 17, at 20:06 UTC, Mozilla received a report". The public incident thread logs the blocking at 22:59 UTC the same evening, with Chrome covering "the Subject Public Key Info (SPKI) hashes of all six affected TLS-issuing intermediate CAs".

What the keys would have allowed is the ordinary nightmare: anyone holding one could, in Mozilla's words, "issue fraudulent HTTPS certificates for websites they do not control". Your domain as readily as anybody's. Nothing suggests it happened, and CERT-In says the disclosures "do not establish confirmed malicious exploitation".

Why did the whole root come out, and not just the intermediates?

Because a blocklist is a patch and a root removal is a decision.

NSS 3.131.1, released on 20 October, removes trust in three roots: emSign Root CA - C1, emSign ECC Root CA - C3 and emSign ECC Root CA - G3. It ships in Firefox 158.0.1 and in ESR 115.43.1 and 153.5.1. Chrome's message in the incident thread says it is removing the root too, and evaluating eMudhra's remaining CA certificate. eMudhra confirms it: "the browser root programs have also distrusted that one ECC root", while "Our G1 root certificates remain active".

The uncomfortable part is who pays. A certificate issued legitimately under that root, to a company that did nothing wrong, stops validating when the root goes. If that is you there is one move, a replacement from a hierarchy the root programs still trust, and eMudhra is covering the cost with Sectigo-issued certificates.

Does anything you serve chain to emSign?

Probably not at the front door, and that is worth establishing in ten minutes rather than assuming for a fortnight.

If your public endpoints run on certificates from AWS Certificate Manager they chain to an Amazon hierarchy, and the serving half of this is not your problem. It is your problem in the places nobody looks at: a certificate bought in 2023 and imported into ACM, an appliance in a colocation rack, a payment partner's endpoint you reach over mutual TLS.

What trusts emSign that nobody will update for you?

Three layers, each carrying its own copy of the trust list.

Go. The fix landed in 1.26.10 and 1.27.3, and the reason it exists is the whole point of this post. GO-2026-6809 explains that "Go uses the given system root certificates. However, in some narrower cases, the system trust stores may not be updated without further action", so "a denylist was added in crypto/x509". The Go team could not rely on the host being current, and hardcoded the refusal.

Python. GHSA-6q48-6c7w-9gw2 covers certifi from 2019.03.09 up to 2026.10.18, which is to say every version anyone is running. 2026.10.18 dropped all the emSign roots and 2026.10.19 put back the unaffected ones, so 2026.10.19 is your floor. Anything taking its trust store from certifi inherits this: requests, urllib3 and pip.

The operating system bundle inside your images. Evidence from our own desk, because it is the ordinary case rather than a bad one. A CA bundle on a laptop here, last written in April 2026, still lists four emSign roots including the G3 one. Nothing on that machine is misconfigured; the file is six months old, which is all it takes. Every image you have not rebuilt since 20 October is in the same state, for the same reason patching the host did not patch your images for Node2Shell.

Do the two code-signing CAs matter to your pipeline?

For most teams, no, and the reason is worth knowing.

Chrome's note in the incident thread is blunt about the split. Its update covered the six TLS issuers, and "The two compromised Code Signing CAs did not require blocking." Code signing is not a browser's trust decision. It belongs to Windows and Authenticode, to a package manager, or to whatever your own pipeline checks before it promotes an artefact.

So the question is narrow. Does anything in your release path verify an Authenticode signature, and would it accept a certificate from those two issuers? If you ship Windows agents or desktop installers, find out this week. If your pipeline checks container digests and nothing else, this part is a non-event, and the broader question of who can publish into it is what the LiteLLM compromise did with one stolen token.

What do CERT-In and the RBI expect you to have done?

CERT-In's advisory lists the mitigations, and one line in it is the entire job: "Review separate CA bundles in applications and embedded systems". The others are to verify that affected chains are rejected by clients, to replace certificates from a trusted source, and to monitor Certificate Transparency logs. None of it is new practice. It is simply the first time most teams will be asked whether they know where their trust store comes from.

For a regulated entity there is a second reading. The RBI's Outsourcing of Information Technology Services Directions, 2023 allow you, at Para 19(5), to "rely upon globally recognised third-party certifications made available by the service provider in lieu of conducting independent audits", then close the door behind it: "this shall not absolve REs of their responsibility in ensuring assurance on the controls and procedures required to safeguard data security". A publicly trusted CA is among the most audited suppliers you have, and it still generated keys smaller than 256. A certification is evidence. It is not assurance.

Reporting depends on what you find. A stale bundle is a vulnerability you fixed. A fraudulent certificate issued for your domain and used against your customers is an incident, and the six-hour clock runs from detection, not confirmation. The logging obligations underneath it are in our read of the 2026 directions.

What can you run on Monday?

Three jobs, about an hour, and not one of them changes anything.

First, read the chain of what you serve and what you call:

echo | openssl s_client -connect api.example.com:443 -showcerts 2>/dev/null \
  | grep -E '^[[:space:]]*[0-9]+ s:|^[[:space:]]*i:'

That prints the subject and issuer of every certificate the server sent. Run it across your public names, then every partner endpoint in your outbound allowlist. For certificates you uploaded to AWS rather than requested from it:

aws acm list-certificates --certificate-statuses ISSUED \
  --query 'CertificateSummaryList[?Type==`IMPORTED`].CertificateArn' --output text

aws acm describe-certificate --certificate-arn <arn> \
  --query 'Certificate.{domain: DomainName, issuer: Issuer, until: NotAfter}'

Second, ask each base image what it trusts:

openssl storeutl -noout -text -certs /etc/ssl/certs/ca-certificates.crt \
  | grep -i "Subject:.*emSign"

On Amazon Linux and other RPM distributions the bundle is /etc/pki/tls/certs/ca-bundle.crt. For the JVM, run keytool -list -cacerts -storepass changeit and grep the same way. Output means the image predates the removal. Fix it by rebuilding with an updated ca-certificates package, not by editing the file, because a hand-edited bundle is reverted by the next base image bump.

Third, put floors in the build: Go at 1.26.10 or 1.27.3, certifi at 2026.10.19, and a rebuild of anything that bakes a bundle into a layer. Then the part worth more than the fix: write down, per service, where its trust store comes from.

When is doing nothing the right answer?

More often than this week's headlines suggest.

If your public certificates come from ACM, your services talk to AWS endpoints and partner APIs on other hierarchies, and your images rebuild weekly from a maintained base, you will check all of the above and change nothing. Good outcome, one hour. Record it, so the next advisory also costs an hour.

Do not pin a CA bundle to a known-good copy, which is the instinct an incident like this produces. A pinned bundle never hears about the next revocation, so you have traded a problem browsers solve for you for one nobody solves. A hand-removed root is the same trade in miniature.

And resist the conclusion that a CA in one country is riskier than one somewhere else. eMudhra published a clear statement, revoked inside fourteen hours and is paying for replacements from a competitor. Larger authorities have handled worse with less candour. What failed was a generation script and a key label that looked right.

The short version

• Read the chain of every public name you serve and every partner endpoint you call. An emSign issuer is a certificate to replace this week, not next quarter.
• Rebuild images instead of editing bundles, and set floors in the build: Go 1.26.10 or 1.27.3, certifi 2026.10.19.
• Check the JVM keystore and any appliance with its own trust store, because no host patch covers them.
• Write down where each service's trust store comes from. That page is what makes the next one cheap.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.