Almost certainly noticed and quietly exploited by a state actor

The Web PKI uses certificate transparency, so we’ll have a definitive answer about whether this is/was exploited soon.

(But in any case, CT ensures that it can’t be “quiet.”)

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

Which is good because certificates not in CT logs are treated as invalid/untrusted.

But only by browsers. curl, autoupdaters etc. would still all accept them.

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

That’s why I’m talking about it purely in the context of incident response/forensics.

You claimed CT would “definitive”ly prove whether it has or has not been exploited, which is false.

The lack of CT entries only proves that (most likely) browsers were not MITM’d.

We would still know if certs were issued, though, which is the thing we want to check

How would you know it? If the CA was compromised, why would the attacker publish the fake certificates in CT?

Basically no one outside the major browsers verifies CT logs, so you can still attack a lot of people even without publishing.

The baddies also take a look at the CT logs and look for fresh wordpress instances that haven't yet been configured and will helpfully configure them for you within a few minutes.

No we wouldn’t.

We wouldn’t.

CAs publish to CT logs. If an attacker has the private key, nothing stops them from signing certs without the involvement of the CA or CT logs.

Nothing stops them from doing so, but major browsers and possibly other programs won't trust such certificates. https://en.wikipedia.org/wiki/Certificate_Transparency#Manda...

Yes but a lot of non-browser software doesn't check CT logs, so if an attacker were to target such software they could use an unlogged cert and no one would notice.

This is why there are OS trust stores. Electron - if you use the system CA [0] and cURL[1] apps use it, which are you talking about?

[0]: https://github.com/electron/electron/issues/45674

[1]: https://curl.se/docs/sslcerts.html

The CT log is a property of the individual leaf certificate not a property of the issuing chain. You could have the same CA in the trust store issue an unlogged certificate and non browsers would trust it.

A CT log isn't super relevant (it's not the CRL, it's just a log), but it's maintained/delivered by the CA not the leaf. Never the leaf.

If you mean CRL/Revocation list, everything but the root [you can't revoke a root] is maintained by the tier above. Leaf -> intermediate (these), [Intermediate -> Intermediate*], Intermediate -> Root.

Not sure why you're mentioning transparency logs, they have nothing to do with this (nor help).

Because the thread: "a lot of non-browser software doesn't check CT logs", you replied saying it's a reason to use the OS trust store, not sure how that fixes things? Maybe it would relieve them of the responsibility of pushing out a distrust update?

That's not what woodruff is talking about (I hope). The CT logs allow us to (later) find who/why it happened. CT Logs in no way help you stop something. (Depends a bit on how software reacts to apparently invalid issuance - but since these have the real keys the issuance will look normal).

Revocation lists allow you to stop/block bad issues. Both are maintained/decided (you could post to another service) by the issuer, not the leaf. CRL records would stop this (but some software has decided that's too slow). In general software uses the OS trust-store first (fragmented on Linux). Firefox and Java have their own independent paths. Chrome ignores CRLs

CT logs only tell you something happened if the certificate was registered in the log. But if you are attacking software that doesn't check if the cert was registered, then you don't need to register the cert, and there won't be anything in the log.

My point is you can forge a cert, without putting it in the log, and a lot of software will still be vulnerable to it.

Curl does not check that certificates have a valid SCT attached. Thus it will accept a certificate that isn't in the CT logs. That's mostly independent of the OS trust stores.

I'm not following. Browser or no browser, every cert eMudhra issues has to generate an SCT.

Sure, but a client that doesn't do CT wouldn't care if they don't include a SCT promise. [ed.: this said "break the SCT promise", that doesn't quite make sense] Which you'd only notice if you see the certificate somewhere else afterwards…

It's all rather hypothetical and unlikely, but you could certainly try attacking something like downloads.openwrt.org¹ like that — especially if you can tell apart the TLS client in opkg from a normal browser.

(¹ luckily, OpenWRT and most other package repos don't actually rely on HTTPS for package integrity and authenticity. And OpenWRT would be the most susceptible due to the "exotic" TLS client stack, if any.)

I’m surprised to see this username above this comment.

No, the cert can be issued with no (or invalid/junk) SCT and will work fine with clients who don’t check SCT, which is most non-browser interaction.

To spell it out a bit further, an attack strictly in a non-browser context that is reasonably well targeted will most likely go undetected since what the attacker is up against is the chance of inadvertently running into a paranoid user who goes out of his way to perform verification.

No, it doesn't. A certificate may or may not include CT info, or include fake CT info. Most TLS clients accept certificates without checking for CT.

SCT enforcement falls to the client though, yeah? What's stopping someone from signing a rogue cert silently which is accepted by CT-lenient clients?

Right, but you don't have to wait for some hapless random browser to check; you can write your own monitor, and people do that.

I hold eMudhra's private key. I generate a cert signed by their intermediate on my box. eMudhra didn't issue the cert, so it is not sent to any CT logs, and I have no SCT to put in the cert.

Am I missing what you mean by monitor?

I think I might just be talking past you. If your point is "anyone with these broken eMudhra keys can attack users without caring about CT", that's totally true --- it's just that browser/no-browser doesn't factor into it. I'm really only on this subthread because of the notion that CT enforcement requires browsers.

Right, I think I'm with you that browser/no browser shouldn't be a factor. I think I'd like to hear from Rust and Go webpki people on whether we could help the ecosystem enforce CT.

My point is more that as a user of a high-level library like reqwest, I'd like to talk safer defaults when root CAs are in use

Right, OK, I was misunderstanding the point you were making. Thanks!

Every cert an attacker issues with eMudhra's private key has to appear in the CT logs if they want it to validate in a modern browser.

But if you only want to MITM the connection used by 'pip' to install python wheels - that doesn't check for CT records at all.

Seems like we need to upgrade all software to start using CT records then?

CT is enforced in Android 17 by default.

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

“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”

I don’t think you can get the SCT from a log without the log publishing it? That would defeat the purpose.

“Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).[4][3] At some point within the maximum merge delay, the log operator adds the certificate to their log.”

> I don’t think you can get the SCT from a log without the log publishing it?

Well you can, but only if the log cooperates.

That is, the SCT is merely a promise to add the certificate to the log by some particular deadline. Nothing technically stops the log from disregarding that promise. But if it does fail to log the certificate, the SCT itself is proof of its misbehavior.

And it's not enough to subvert a single log, because browsers require SCTs from multiple distinct operators in order to consider a certificate valid.

The SCT may be proof that a log was supposed to be issued, but browsers don't submit every SCT they see (did you know "anonymizing" proxies send CT log companies a sampling of all your TLS traffic? fun stuff!), so in practice these logs aren't audited. As far as multiple operators, almost all of them are based in the US, so just pray the USG doesn't want to target you.

I feel somewhat confident in speculating that a bunch of people at large companies will, in fact, be auditing the logs following this. That’s their main value; they’re not really an online/active prophylactic.

A grumpy state actor today.

Nope. You can find this from the Chrome Root Program.

> Because no TLS certificates chaining to these six intermediate CAs were logged to CT prior to our CRLSet block on October 17, no fraudulent certificates issued by these CAs could have been trusted by default in Chrome or other CT-enforcing browsers.

Not all TLS traffic involves a browser.

organized crime is generally as or more capable these days. they have bigger budgets than most nation states.

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.

truu, thanks for the addition. some nation states are indeed known to do this. definitely not all, but where access can be bought i'd be surprised they wouldnt do it if they needed it.

I admittedly don't know much about how CAs work but why would a state actor care about such an exploit? Wouldn't they just ask any local cert issuer and receive a "legitimate" cert?

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

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.

Apparently they've only been included in early October https://www.mail-archive.com/[email protected]...

I'm not exactly sure which of the roots from eMudra were compromised, but the "emSign ECC Root CA - G3" which is mentioned in the OP site as one you should blacklist, is present on my phone which is running Android 12 with the last security update from three years ago. Having a better timeframe for when the impacted certificates appeared really would have been nice.

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.

Yeah, in Android 14 they separated it out so that the CA store can be updated from Google Play. Versions below that you're reliant on the manufacturer to ship updates.

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?)

Well that makes sense. The "emSign ECC Root CA - G3" root is listed as being originally issued on 18 February 2018, so would have been really concerning if that itself was the compromised certificate.

its well-known , we took certificates from them for our company. its due for renewal, iam pausing this for now.

I believe these intermediates chained up to a third party root.

They chain up to emSign & Comodo:

https://groups.google.com/a/mozilla.org/group/dev-security-p...

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...)

Slightly funny about this: even Wayne (the person who reported it to Chrome & Mozilla) got confused [https://bugzilla.mozilla.org/show_bug.cgi?id=2083449]:

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

(…the "cross-signs" use the same keypair of course.)

Love this quote:

Inclusion in the Chrome Root Store requires that a CA Owner continuously demonstrate the technical competence and operational rigor necessary to protect Chrome users. Due to the seriousness of this incident, the Chrome Root Program is conducting a thorough evaluation regarding the status of eMudhra’s remaining CA certificate to ensure these standards continue to be met. We will share further updates as our review progresses.

from a post on https://groups.google.com/a/mozilla.org/g/dev-security-polic...

It's been a while since there was a good CA death penalty case.

Given Wayne's hints in the timeline that this issue was discovered by an agent, it might be one of the first big corporate death sentences due to AI?

I bet Entrust never made a cert with a private key of 4.

The problem is the death penalty case is aimed at the wrong target: The entire Web PKI system remains dumb and bad, and the correct answer is to dissolve the CA/B and find people with practical security experience.

Entrust (now Sectigo) is involved with this [0] (cross signed an intermediate) [1] Even last year buying a Sectigo cert got you an Entrust cert with no mention of Sectigo/Comodo[2] (maybe more of a Character.AI situation than a sale)

[0] https://emudhra.we-have-a-problem.com/roots.json

[1] https://www.entrust.com/company/newsroom/entrust-sells-publi...

[2] https://www.sectigo.com/comodo

> Entrust (now Sectigo) is involved with this

This is probably a rough definition for "Entrust was banned from being a CA and sold the business off to a competitor". In part, because I also do not think the root programs would just allow Entrust to continue operating the same business under another brand name, unless they are even dumber than I already thought.

The other solution is web of trust. Which works waaaaay better but is really complicated to implement.

I'm not sure there is a 3rd solution to this.

Given the amount of progress the CAB forum has led in the last decade+, I'm not sure I agree with that diagnosis. Plenty of people in the forum I can think of who have forced positive changes due to the strength of their experience.

If anyone should be navel-gazing coming out of this incident, surely it's the trust store maintainers. If there's a big concrete improvement to be made, short of burning down the web PKI ecosystem, I'm not sure it's obvious yet.

Since they are also a root CA, are they allowed to audit themselves, or do the browser root programs require third-party audits?

I can't imagine one part of a business being on the up and up, and the guys down the hall running completely rogue.

Third party audits from a qualified auditor are required, although the CA chooses and pays the auditor, and the auditors are basically just accountants. So it's... not a perfect system.

Argh. Thanks for clearing that up.

It's real.

It's an intermediate certificate, so it doesn't show up in certificate stores. That's why Golang hurriedly and unconventionally patched itself to ignore these specific certs.