eMudhra intermediate CA compromise

There were no certificates from the compromised intermediates logged to CT prior to remediation by the browsers.

CT is great for browsers. Largely irrelevant for anything being fetched outside of a browser.

There are plenty of ways you would never be able to tell if a fake cert had been generated and used via this attack vector (let's ignore validation attacks):

1. CT does not do anything if a state actor demands a CA in its borders generate a cert without publishing to the CT logs (or a three-letter-agency doing this illicitly). They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees.

2. Browsers won't check for SCTs in certs if they come from a private CA. you can MITM any domain through ZScaler all day long and nobody will notice

3. Wildcard certs make it easy to make/renew a cert that looks normal but hides requests on new/different hosts

4. Non-Browsers do not validate SCTs

If FBI went to Godaddy and said, “We need a cert for www.google.com”, Godaddy would most likely refuse. Issuing that cert would leave a trail that would be extremely undesirable for both FBI and Godaddy.

You could cloak where it's coming from more easily this way.

They are not exclusive to each other. The most successful criminal organizations work with, and from within, nation states, their intelligence agencies and law enforcement. Oh hi, we see you.

Not all TLS traffic involves a browser.

I believe Android updates things like CA certs independently of their monthly security patch. I'm not sure Android 12 uses the same system, but on newer Android I think those are shipped via Google Play system updates, which don't require waiting for the phone vendor.

None of the roots were compromised. (Some of) Their own sub-CAs for TLS certs, which are also cross-signed by Sectigo (since their own roots are rather recent), are affected.

How you have that root cert on your phone with a 3 year old CA set I have no idea, presumably something updated your CAs in the meantime? (Also, aren't you incredibly exposed to the general onslaught of vulnerabilities from the past 3 years?)

To be clear, emSign is another name for EMudhra, and Comodo is now known as Sectigo. (You can't just look at the organization name in a certificate subject; you have to consult the CCADB: https://www.agwa.name/blog/post/the_certificate_issuer_field...)

  2026-10-17 20:18 - Full CCADB check finds the cross-signs by Sectigo are also affected

Yup. I think they literally think a 256-bit key is just a random number between 1 and 255.

An elliptic curveball even

Wrapping/unwrapping means the HSM would generate the private key and then encrypt it with a key only known to the other HSMs. Those other HSMs would then decrypt the key on import. The private key should still have been impossible to examine outside the HSMs.

Doesn't even seem to be all that random within that range. For example all digits within each number go left to right on a keyboard.

Hey that's a byte of entropy! And one of the rare cases where choosing a larger value might offer you better "protection" against serialized brute force attacks

If my career was ever exciting enough to let me participate in a key ceremony, you'd bet I'd go all in on the Seriousness and Gravity. Hell, I'd come in a monk's habit.

I was once the annoying person who refused to participate in a ceremony when it went off script.

What was more troubling was the other people involved couldn't understand why I did it.

They used the "correct" key for signing the CRLs (which of course was then an invalid signature):

> The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.

And THAT is where I'm drawing the line between "honest mistake" and "gross negligence". For that to not raise giant red flags is an unacceptable failure in process and work culture.

> Windows will happily run unsigned binaries

This is absolutely false, it's a simple policy change to enforce code signing, any organization that is serious about security can do it.

I'll give you the benefit of the doubt and assume you're another Linux guy who doesn't understand Windows security.

The concern of course is with malware being signed, which is far more likely to be abused than some TLS MITM fantasy.

Y'know… let's just check…

https://ctlogs.io/search?mode=fingerprint&q=42c4accd12c4f595...

https://ctlogs.dev/search?q=42C4ACCD12C4F59597925E1A08A7A901...

https://ctlogs.io/search?q=EBED6475C2C2D80FCB199F3FE8DD6E6B3...

https://ctlogs.dev/search?q=EBED6475C2C2D80FCB199F3FE8DD6E6B...

Nothing for "CN=EM DV TLS CA - G3B,O=eMudhra BV" (not sure which sha256 this uses, 2nd is the spki sha256)

I should be clear here my understanding is/was these are sub-CAs. Apparently they're (trying to be?) roots themselves? The point of logging a root cert in CT is somewhat moot… though tbh I would argue anything issued by a CA should be in CT logs, even cross-signing another CA that is becoming a root itself.

In the most extreme case, you can just issue a certificate and not use it anywhere. If it leaks, it's still a security issue, because it's valid.

More realistically, especially with sub-CAs, they might only be used on e.g. corporate networks. TLS scanners may not be able to reach any of the hosts that uses such a cert. As the sibling post points out, clients checking for the cert in Certificate Transparency logs counters that (adding a requirement that the cert be publicly known, which TLS/X509 by itself very much does not have) — but of course this only helps if your client does CT…

If you're doing a MITM attack, you can selectively intercept certain clients, and only serve the compromised certificate in those cases only. Automated scanners won't pick that up. None of this actually works though, because browsers started mandating certificate transparency.

My vague and inexperienced read on their description boils down to "we were doing something weird and non-standard as part of our key ceremony because we intended these keys to be exported, and because of that process weirdness we blundered and gave the HSM faulty instructions."

The most likely explanation is that they generated the weak key externally, imported it into the HSM, generated the CSR from it, and finally had Root CA sign it.

A FIPS HSM does not forbid one to import keys into it.

I think I'd prefer open source hardware built from off the shelf components glued into a secure enclosure. That way you can destructively audit a few at random if the application matters enough to justify the cost.

While you are right in that it is impossible to verify they work as advertised, it is not impossible to detect certain categories of failures. Like only generating values 0-255.

It's not within the realm of believability. The chance of "human screwed up" astronomically exceeds this being fairly randomly chosen, and the Firefox bug states, (I think this is supposition, not known fact, but IDK)

> The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order.

That is within the realm of believability.

Regardless of the probability that this cosmically unlikely occurrence naturally happened 8 times in a row, we all know what the privkeys are now so the certs can't be trusted anymore.

When you have multiple selections you can show that the probability of selecting a set with a range much smaller than the population range is exponentially unlikely, strong evidence to reject the hypothesis that the subset was chosen at random. But when N=1 you can't conclude anything.

> now that number is interesting precisely because it was cited as the smallest non-interesting number

This made it click for me, thanks!

Ok, now do that same paragraph, but for drive-by RCE vulnerabilities.

Nobody thinks this is a good thing. It's bad. Hopefully, eMudhra gets distrusted. We've done that to bigger CAs.

OSCP stapling is better than normal OSCP by miles, but still, with shorter cert lifetimes it seems like it doesn't help that much.

Didn't Let's Encrypt have to jump through all sorts of hoops to prove they were competent and trustworthy before that happened?

Now it's coming out these guys used "4" as a private key. That's a crazy amount of incompetence and malfeasance. Did they vibe-code a CA? HOW DOES THIS HAPPEN? I am dumbfounded.

You couldn't even do this if you installed Microsoft Small Business Server 2008 today, unpatched, with the CA on default settings.

> But that's not something we can really save in the Web PKI's current state.

I agree with your assessment but it's not an excuse to give up without trying. I hope this is just because I'm not looking in the right places, but I don't see people trying.

What really makes me salty is that there was enough energy to mess with the rules around EKU, the primary effect of which is that non-browser software is now starting to just ignore the EKU bits. Even if it would've amounted to nothing, I'd really rather that effort had gone into NCs.

If you mean Comodo and Setigo, they're the same company, pre- and post-rename.

Let's just say they've had issues with signing sub-CAs before where those sub-CAs went on to misuse them before… looks like it was around 2011?

This CA business is a scam. You cannot buy trust with money.

circa 2007 I was looking over a college textbook on computer networking that I saw at a family member's house. It still said "While networks are inherently unreliable, it's not a stretch to imagine a future where one can stream video on-demand over a WAN like the Internet"

> rolling out a dramatic infrastructure change for "data sovereignty" just to pull off a SIGINT heist that is almost certain to get your CA distrusted seems like a poor risk/reward calculation

Well, meet the Indian government that does these calculations all the time.

Some examples:

https://www.thehindu.com/news/national/neet-ug-re-exam-teleg...

https://www.medianama.com/2026/07/223-india-bitchat-ban/

https://www.drishtiias.com/daily-updates/daily-news-analysis...

https://vajiramandravi.com/current-affairs/bill-to-curb-inde...

Yep, but it was an easy zero-touch MITM vector for billions of devices that's only now being closed down

In any case, not much sovereignty to gain from only 8 bits :^(

Well, I honestly believe it is rank incompetence. Speaking as someone who's monthly electronic GST filings, commercial authentications, and digital payments, i.e. continued livelihood, is beholden to cert and PKI authorities like eMudhra having their shit together...

As for the odds of this being state-sponsored... It depends on the state's incentive, weighed against its continued behaviour, over the last 10-odd years. Everything below is easy to substantiate with citations. There are too many to cite... I put myself at real risk just by stating any of the following under my real name.

  ---My take: Never attribute to malice, what one can to (rank) incompetence.---

I expect eMudhra-esque collossal gaffes, as a normal course of life, stemming from the apathetic, insular, feudal-minded, shoddily run bureaucracies that the majority of our government and quasi-government organisations are.

Basic day-to-day operations being unavailable, because "Sorry sir, site is down." is a normal everyday life experience of their own staff, not to mention the common person. eMudhra is one of that tribe, and I'd say they are not the worst offenders of the lot, by a wide margin. I'd probably give the "best of the worst" title to our national Employee Provident Fund.

Of course, one can't totally rule out nation-state-level stupidity, such as BGP poisoning by the Pakistanis.

  ---Nation-state action: Wither sufficient incentive? ---

If our current federal administration has incentive to do it, they will... And, given their track record, if it does turn out to be nation-state-engineered for short term tactical gains (to hell with the consequences for anyone else), all I will do is sigh and move on with my day. Cornered politicians can go to any length to save their own skin (usually, just to save face)... Collateral damage be damned. Popular examples include world superpowers bombing distant nations, for whatever gain or goal (usually short-term, because well you most probably won't be President a second time (and never a third)), using whatever pretext they can sell to get others to also get behind (the individual's psychological cover in a firing squad, scaled up to many allied powers).

In India, absolute majority governments have amply demonstrated the same failure mode as US heads of state empowered with de-facto fatwa powers, as of the US PATRIOT act. Given motive and incentive, they easily turn the full might of their uncheckable wrath and ire at our constitution, as well as directly at the common public.

You know, like sending out military forces to "calm down" the pesky student protesters acting against "the national interest".

As we speak, massive nationwide student protests have been bringing shame and angst to the government of our ruling party at the centre (BJP and allies), as well as their various governments across states. Many protests have happened at this scale in the last decade+ of the same ruling party's unbroken streak as a majority power in the centre (federal government). Those other protests were like water off a duck's back. The ongoing student protests, for reasons I've not dug into, appear to be a clear and present existential threat to the incumbents.

My gut feeling is... the incumbents aren't passing the electoral vibe check any more.

The sentiment on the streets of the national capital, and large urban centres nationwide---almost entirely comprised of a new crop of young voters (18 y.o. up to early 30s)----is that they feel robbed of an economically viable future. They've organised at scale (millions on the street) with persistence (they are literally owning the "Cockroach" epithet thrown at them by the powers that be). And in short order, material consequence---unprecedented in its decade-long winning streak so far---befell the incumbent party's administration. The Education Minister had to resign, and they've generally lost face with that whole voting-age cohort. Brand-name loss of key leadership is further disrupting their internal party cohesion. Plenty of hopefuls in there, salivating after the top dog position, but thus far too weak to sway the cult following of the public faces of the party. Even an hint of weakness gives the wannabes a real opening to try. Textbook demagoguery.

If that is indeed true, then in their place, I too would seriously worry about losing even more ground in the next national election... It's not far now. Because? "Winning by overwhelming majority" has been the one and only priority of the incumbents, driving all their work post-election (where work includes constitutional shenanigans)... Being a populist party borne of, and cultivated by far-right nationalist ideologues (the RSS and "Sangh" community), with a longstanding desire for religious supremacy (Hindutva and Sanatan dharma), they publicly and loudly dream of a hundred-year golden age. Uh, no, now I think it's become a thousand-year era (really!). That's not totally insane if you're suddenly goated at winning electoral politics, because our head of state can enjoy unlimited tenure. Yes, you heard that right, India has no constitutional limits to number of re-elections to the Big Chair, whether successive or alternating.

Without looking at absolute numbers, I feel confident that the influx of new voters (lots of people can turn 18 in a single government tenure) far outstrips the older ("whatsapp uncle / aunty") voter base that the incumbents pander to. This has been a lucky break for the fumbling Congress party because their legacy name is finally regaining some cachet... The much-mocked Rahul Gandhi presents like someone the young'uns can actually talk to, like a human being.

But the Gandhi-brand Congress were once an absolute majority power too. At which time they suspended our constitution, and weaponised federal agencies, and created the playbooks that all future governments have been able to deploy at various scales. I expect nothing less from any other party that grabs absolute majority. Currently it's the BJP. Tomorrow, it could be anybody else. Thus far, it's been the secular-presenting Congress, followed by the Hindutva-majoritarian BJP. Woe betide us if next the Communist Party of India gets a bite at that juicy apple. 'cause, like, I don't have to explain what that sort of government can do with absolute power. <shudders>

  ---Nation-state action: Whither evidence of having the means and using them with impunity?---

Ref: our liberally interpretable Information Technology Act. Among other things, it enables and empowers arbitrary blanket Internet Shutdowns and Blackouts, by local states as well as national authorities, to "protect the peace". In some deeply conflicted areas, like Jammu and Kashmir, censorship measures under martial law would give both, the Great Firewall of China and the Stasi a run for their money.

Ref: at-scale weaponisation of Pegasus, as of 2021. Federal and even state authorities like police departments have weaponised nation-state electronic warfare technology with impunity. Usual suspects / targets are politically inconvenient individuals and groups... opposition politicians, bureaucrats with a spine or conscience, students, media, artists, NGOs etc...

All this mixes badly with pre-existing supercharged Sedition laws. These effectively obviate habeus corpus, and are routinely used to prosecute speech interpreted as anti-national / seditious under the generous ambit of our IT laws (we don't have a real privacy law). Mere suspicion and/or fear and/or dislike + Pegasus + garbage IT laws = authority can brazenly plant incriminating evidence on your device... it's reportedly been done multiple times.

People have been held in prison for less (just inconvenient speech), without possibility of bail, for months and years on end, without trial. The main goal is to cause irreparable reputational damage, to create future deterrence... It's pretty effective. A secondary goal is to take the stubborn ones off the board, with no legal recourse, until they break. And of course, to permanently defang the truly outspoken and indomitable few... Some of those people have been in high-security federal prison for years on end now.

In conclusion:

I'm confident all federal administrations of India, current and future, will hold the lawful means to act wilfully, crudely, with impunity, at scale against India's own citizenry.

I'm not sure whether they currently have enough incentive to have used the eMudhra cudgel, to disrupt the protestors. Sure they could MITM the protestor websites, but it's so much easier to block them and takedown their socials. And for more specific work, they already have field deployments of Pegasus and other MITM / spyware technologies.

The state would rather it was none of us (except themselves, they have non-backdoored tech)

It's uncommon on Windows for applications to use a third party certificate verification library because Windows provides an API that does it. On Linux, you have no choice because all the platform provides is a bundle of PEM certificates.

I'm not making an argument for a single centrally-managed trust store. The thing that seems most obviously bad to me here, as a non-crypto-expert, is that any CA can issue a certificate for any domain. This is probably made worse because there are hundreds of CAs, and AFAICT functionally every trust store trusts all of the same ones.

I don't know how we fix this, but it does seem like a big problem.

> Many web clients have chosen to default to trust stores within their own ecosystem for usability and reproducibility reasons. When I as a user run "pip install requests", I expect to be able to issue HTTPS requests. I do not expect an implicit system dependency on ca-certificates - that might not even exist on my system!

But this is the kind of DevEx decision to improve usability that goes against security, in the case of a shitstorm like this one. I mean, yes obviously everybody should be updating and refreshing all the systems running in all the environments daily/weekly but the reality in many (most) places is very different. So, it's an engineering decision with its trade-offs, as every decision. And OP was criticizing that decision(s) since this eMudhra issue happened now.

As as thought experiment: if no language were to distribute its own copy of root certs, we would have either docker images embedding them (which would be the same for dockerized workloads) or maybe some system would have been created to easily share a set of root certs within a cluster of applications.

> The design intent is still bad though: we should never have given CAs universal issuance privileges.

This is sort of right and sort of wrong. It's true that you could have a DNSSEC-style regime where only one entity could issue for a given domain, but as long as you're going to allow third party issuance at all, then you have to contend with the fact that most CAs want to issue in the big gTLDs (.com, .org, etc.) and so narrowing issuance doesn't help that much in many cases.

> Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.

This is ahistorical. By the time that DANE was designed, the WebPKI model was well entrenched and there was a huge population of browsers that couldn't really be upgraded and also only supported the WebPKI. If you wanted something that was acceptable to those browsers, it had to be WebPKI and it had to be cross-signed, hence Let's Encrypt.

I suppose you could argue that at some point after that one could have tried to deploy DANE and phase out LE and the rest of the WebPKI. I don't think that's true for the reasons that have been discussed on HN about DNSSEC, but that's really not the same as you wouldn't have needed LE in the first place.

> Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.

Had we been using DANE instead of WebPKI, the response to this sort of compromise would be "aw, shucks, someone proved to be untrustworthy and they're in such a critical role in the ecosystem that there's no way to route around this DNS provider being untrustworthy."

That's an issue primarily with the hyperscalers, who're refusing DANE. Anything outside of Gmail, Outlook and the likes, you're much more likely to see DANE than MTA-STS.

(Most open source SMTP stacks don't integrate an HTTP client and are completely unable to do MTA-STS without hacks, patches or other fragile bolt-on bits.)

Rare in public PKIs, yes; not so much in private ones, I would imagine.

From my limited experience (using them at home) they seem to be fairly well supported in client libraries, actually!

- OpenSSL has full support, https://docs.openssl.org/master/man5/x509v3_config/

- GnuTLS has full support, https://www.gnutls.org/manual/html_node/X509-certificate-API...

- go (crypto/x509) supports everything except DirectoryName constraints, https://pkg.go.dev/crypto/x509#Certificate.Verify

- Python (pyca/cryptography) has full support, https://cryptography.io/en/stable/x509/reference/#cryptograp...

- Windows/Schannel has full support, https://learn.microsoft.com/en-us/windows/win32/seccertenrol...

- Java has full support, https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

- I know that NSS also supports them from experience but (sorry!) couldn't find the docs in a few seconds of searching

- I know that Strongswan supports them well because I actually opened an issue about it a few years back and got it fixed :-)

(Just a few off the top of my head)

> and half the world that does pin is probably pinned to Let's Encrypt

To be fair, unless I'm misunderstanding, wouldn't this be a good move?

LE has a good security record and takes itself seriously, versus these smaller CAs that seem to mess up regularly.

You can pin in software you distribute. If you're big enough (top 100 websites mostly), you can ask browsers to pin certs and they may included it in their preloads.

> And what happens when you want to switch?

You have to update your pins and then wait long enough that you don't mind losing users who never update their software. When it's just in software you distribute, you can change hostnames in new versions and use the new CA for new versions and the old CA for old versions...

For web browsers, there's not a reasonable way to make a nicer transition. You have to serve old certs for old pins, and TLS handshakes from browsers don't include enough information to know if the client has an old pin or a new pin; or at least, mostly they don't --- if you get your pins changed and the browser TLS stack changes so the handshake changes after that, maybe you can use that... when sha1 certs were phased out, it was somewhat popular on high volume sites to look at the TLS Client Hello to decide to serve a sha256 cert or a sha1 cert.

DNS CAA only pins issuance, not acceptance; clients can not check if the CA that issued a cert was listed in DNS CAA at the time of issuance, and they do not check if it's listed at time of presentation. I'm pretty sure issuing a cert contrary to a CAA record is a mississuance and would result in sanctions from the CA/Browser forum, but clients would still accept the cert until it's revoked.

There was briefly browser support for site initiated pin on first user (HTTP Public Key Pinning), but it got dropped as mostly no one was using it and it was easy to get wrong and break your site.

https://kagi.com/search?q=dns+CAA CAA is one way, but you can also pin the actual certificate or certificate chain (which has its downsides, mind you).

Because it makes you only as secure as the the LEAST secure CA. Such as the really bad ones that don't use Hardware Security Modules.

"It doesn't solve anything because they don't monitor the logs" feels like a completely different thing than "It doesn't solve anything".

PGP is indeed a problematic implementation, but it's just one of many possible ways to do a web of trust. It's not 1991 anymore. How many more of these failures must we endure before we consider alternatives to trees as a data structure for handling trust?

> Even before the PGP web-of-trust broke down several years ago

I'm not sure I'm familiar with what moment this is referring to; can you elaborate?

Web of trust has been working between humans for over a million years. If we've failed to make computers do it, it's probably just for lack of trying.

To your second point, that might be true in a world where the consequences of making a bad trust decision was some kind of hassle related to changing passwords or reporting your cards stolen. But we seem to be moving towards a world where it lands you in a detention facility or some other dire consequence. I think that sooner or later, users are going to realize that they want that control and will be willing to do the corresponding trust hygiene work. Besides, isn't making that kind of work easy the point of technology? We just need to do better re: making it usable rather than investing in systems we know to be unsafe.

The WebPKI semi-routinely kills certificate authorities. The point is that you can't kill a TLD operator.

Name constraints are intended for organizations which want to issue publicly-trusted certificates for their own domains. Name constraints are already widely supported and name constrained sub-CAs exist for this purpose in the WebPKI.

eMudhra is not such a case. They are a root CA that issues certificates to the general public all over the world. In fact, they are now the preferred vendor for numerous US universities via InCommon[1]. There is no way to meaningfully name constrain them.

[1] https://incommon.org/certificates

I like constraints too, but listen carefully to EKR and 'agwa on this, because a lot of things that seem like straightforward fixes are much more complicated in reality. The most important thing I want from the WebPKI is expensive entry and the death penalty for fuckups, and I think we basically have that now.

Do the words "no discernible reason" just mean something very different to you than they do to me? Because I've written somewhere in the vicinity of 100,000 words about the problems of DNSSEC over the last 20 years. My written DNSSEC critique predates HN itself.

This particular issue has nothing to do with "aligning authentication with the name hierarchy". The exact same thing that happened to EMudhra could happen to any TLD operator. The difference is that we have essentially no recourse when that happens, and far less ability to detect malfeasance.

DNSSEC creates more operational issues than it solves. It's easy to screw up, which means your domain completely stops resolving when that inevitably occurs. None of the FAANGs use it for their main web sites, so what does that tell you?

It can also be disabled at the whim of anyone operating a resolver, as was seen with Cloudflare during the .de TLD DNSSEC snafu back in May.

So... fix them? It's not like it's hard for someone of the caliber of a root server administrator to unhork DNSSEC