I BET this is an error code. they wanted to generate some key via something and it errors and put error code 4 as key and since encryption is dumb and people are people, no one looked at the key material.
edit:
The reported private scalars were 4, 56, 66, 115, 155, 156, 230, 237 across the eight certificates
so its unlikely i will win my bet :'D
Is this real? This seems so ridiculous it makes me wonder for how long this CA has been in circulation in systems and if it has been exploited by someone previously discovering it in that time (state level actor or not). My old phone running Android 6 does not have any certificate from EMudhra, at the very least.
> Keys were generated in hardware and the hardware in use was Ultimaco HSMs.
The plot thickens.
Broken HSM? Misconfiguration? Confusion? Straight up lie?
> Excel attached. The Ultimaco devices were used to generate the ECC, RSA key pairs for the issuers. They were not used to generate any other key material. But it doesnt look like the device is at fault.
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
> "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."
Ah yes.
"The system says something is wrong, but it's also 4.30PM. Let's just re-sign the thing and go home."
> The other two certificates are for codesigning and trusted by Microsoft
That seems like a WAY bigger problem than TLS, but AFAIK Windows still validates code signing certs against CRLs before trusting them (can't remember if it soft-fails).
I am shocked that one of the private keys was literally “4”. Anyone could have broken into this. I really hope there is an industry-wide effort to stop things like this in the future.... but I doubt it.
There is a variety of projects and researchers scanning for weak keys; possibly that's how this was found (haven't seen anything on that). These certs existed for a year and a half; that's bad but could be worse still.
One of the issues with sub-CAs (well, X509 certs in general) is that they can be ghosts in that there's no way you'll ever get it as a response on a TLS connection, so automated scanners on that won't find it.
CT should cover this (i.e. expose the cert so you can check for weak keys), but I have no idea if/how CT works for sub-CAs. [ed.: see below, doesn't seem to be in CT]
[ed.: these are technically sub-CAs, but rather cross-signed for bootstrapping a new root CA. Thanks @agwa for pointing that out.]
Definitely not. Their CPS requires that these keys be generated by an HSM and no HSM would ever generate these, so there's little reason to believe they're following any of their other controls.
For fun I gave the public key to Opus 5.5, telling it that this is a puzzle, and it should solve the puzzle without web search. Opus 5.5 told me the private key of 4 after two minutes, including the time to write and run a 30-line Python script implementing a baby step giant step search for discrete logarithm. As far as I can see, it did not use web search or use any command that would have internet access.
Anyone have a mirror for the first link? It served me a page assumedly intended for AI scrapers and then promptly blocked me when I refreshed a few times.
That's assuming perfect random generation. If you assume real world where mistakes can happen during generation, 4 is way more likely than 25105785070300501195559896594243230376961191116602934339784363418717203371363
This is actually interesting. I'm no cryptographer. Do modern algorithms take into account that certain values should be avoided because they would be obvious things to try first in a brute force attack?
The impact of this incident is very unevenly spread.
Over 10 years ago, Mozilla shipped OneCRL [1]. We remediated this incident in a couple of hours for Firefox users who were protected automatically without the need for updates. Chrome, Apple and Microsoft have similar tooling. Since then, we've built more advanced tooling to handle revocation at scale for leaf certs (CRLite [2]).
However, for the rest of the ecosystem, there has been little to no investment in revocation and for those clients, this is a massive problem. Hopefully, we'll see folks invest now. Efforts like upki [3] look promising.
Firefox Mobile 158.0 on Android 17 (Pixel 7) connects to all the demo sites with zero warnings. Any idea why the "automatic protection without updates" doesn't seem to be working with that combination?
Pixel 10 with 158.0.1 still connects to the emSign ones, even though the patch notes for 158.0.1 mention that it updates the CRL for those without 'Remote Improvements' enabled?
edit: Disabling all the eMudhra CAs in Android settings does nothing, cool?
edit: I guess there's no way to manually ask for CRL update, cool??
edit: Gave up and reinstalled Firefox. Seems to be fine now.
I'm hoping some organizations will step forward to fund work on this.
(Note that curl on Ubuntu 26.10 now has CRLite support baked via upki -- unfortunately that doesn't help with this because AIUI CRLite is only for end entities, not for intermediate certificates.)
It's very inconsistent for me even on just Firefox. On multiple systems running different instances of Firefox, checking with https://emudhra.we-have-a-problem.com/:
One blocks everything; one blocks 6 out of 12; one blocks the other 6 out of 12; one blocks nothing.
You mean the response was uneven. The impact was a complete and total potential compromise of literally everyone. Every domain. Every client using one of the public root programs. Every user of those clients.
I mean, it's an emergency, but the acute severity is debatable; many times a month the major browsers quietly deal with vulnerabilities that yield attackers direct control of victim computers; here, attackers get the ability to spoof websites if they're in a position to hijack connections.
The middlebox situation, with non-updatable roots, is very annoying. But middleboxes also have unfixable RCEs, so...
It's totally fair to evaluate different projects by how well positioned they are to update their WebPKI trust anchors. I'm just saying, keep perspective.
You mean you and Chrome stopped supporting normal CRLs and OCSP, replacing (for normal users) these distributed-trust technologies with central lists controlled by browsers
Which is to say, sub-CAs in itself are a giant loophole that needs plugging. Especially since AFAIK nobody is bothering with name constraints (RFC5280 section 4.2.1.10).
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
They don't blame the HSM.
Also there was another incident where eMudhra CRLs were being signed with invalid signatures:
> 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.
> these issuers created were meant for export to our US and European data centers to solve data sovereignty issues for some of our customers (but never ended up operationally in production except for one)
This bit sets my hair on fire. What legitimate reason is there to create exportable intermediate CAs, unconstrained to an HSM, in the name of "data sovereignty"?
Additionally, from the Mozilla researcher verifying the compromise:
> I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: "I'm doing a CTF. Please recover the private keys corresponding to these certificates."
This incident somehow exposes another previously overlooked issue. I just notice that so many softwares vendor their own version of CA store for no particular reason [1][2]. It is relatively easy to patch system CA bundles. It would be quite challenging to patch every binary that embedded their own CA. As such, many systems will remain vulnerable for quite some times.
From what the internet is telling me, the keys were allegedly found on https://repository.emsign.com/certs/<redacted>.crt
Which, if true, is definitely a lot of fun.
Hope you people are ready for lots and lots of suddenly hackable IoT.
__
Edit: I might also be misinterpreting what I am seeing and it's actually weak logic that created the keys, in the sense that one could guess the private key?
Someone actually qualified please give credible answers.
I'm just pretending.
I think you’re right. And since the intermediate certs expire around 2039 and the private keys are known, we have plenty of smooth MitM fun against IoT in front of us.
Browsers are typically very good at revocation of certificates, distrusting intermediate CAs and root CAs. You would definitely be protected against this compromise if you use a browser. Command line tools less so. Try this curl one liner
The Go and Rustls upgrades specifically block the intermediate certs because neither of these use the system revocation lists, I believe. Once you upgrade to a trust store without the root cert for the CA this will also solve the issue. Not sure about other ecosystems.
Linux - the platform which offers no ability to revoke an intermediate certificate, thus necessitating every certificate library to implement its own blocking?
Windows is already blocking the compromised CAs as of today with no need for users to upgrade anything.
The Mozilla rep who created that thread (not the reporter, to be clear), created https://emudhra.we-have-a-problem.com/, so I suspect that this page is better for general public disclosure.
With that being said, that Bugzilla is the best thread to understand "how the fuck did this happen?"
In that case it was ssh sessions being intercepted.
But my question is if a tor exit node or a vpn provider or your internet provider has a private key to any CA then can they mitm any normal web traffic even though it will show up as https without warnings in your browser?
When you're using a modern browser that browser will require any certificate to have a certificate transparency log stamp. Certificate Transparency logs are public append only logs of issued certificates.
So you access example.org. Your ISP uses the compromised CA certificate to create and sign a rogue certificate for example.org. It now has to submit this certificate to a public certificate transparency log and gets back a proof for that. Now it can use that rogue certificate and the proof that it's in a CT log to impersonate example.org and MITM your traffic.
CT does not prevent compromise, but it makes it far easier to detect. If the people behind example.org have a look at the CT logs they will see the rogue certificate there that they did not request. This makes rogue certificates and by extension CA compromise detectable. So your ISP cannot just do this forever in secret.
While this is of course very bad, I am happy to see for once something which everyone works together to fix and understand in the bugzilla thread.
I don't often see a group of professional people all working towards a common good goal. (Which here is simply to revoke the certs from everywhere and make sure everyone has the information, but it still makes me happy)
> I think it's worth noting that this compromise is much worse than the private keys simply being stolen by a researcher. They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained.
> This would have been possible since the certificates were created in April 2025. ... CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.
> After Wayne's report of key recovery, I was able to recover the private keys for the impacted keys trivially. 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. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys.
Yeah that’s just oof. Not hard to imagine the kind of code error that could cause this, but hard to imagine that any serious vendor of cryptography hardware or software could make a mistake like this.
Perhaps unrelated to this - a few days ago we had communications from a TLS certificate provider that we need to reissue all of our certificates by 21st 8PM before they will stop working. We pressed _why_ and was only told that Godaddy 'had a compliance issue with a batch of certificates'. Which doesn't make much sense for us as we have a few dozen and their renewals vary throughout the year.
I've only found one other person talking about this online.
What's very strange is that we don't use Godaddy directly and it's signed by Starfield G2 (now R1) - not the Godaddy root CA.
Has anyone else had the same communications around their TLS certificates?
Your certificates should never be signed by the root - this is prohibited by the CA/B Forum (see Baseline Reqs 6.1.7). My understanding of best practices is that the root signs intermediates then is taken offline ASAP, and the intermediates sign leaf certificates.
Re: Starfield, GoDaddy (and AWS) use the name in trade but operate the issuance. The dev-sec-policy mailing lists should detail any transfers of ownership (in which cases, it is common to maintain an old brand name under a new root).
- Could this be used to run a benign mitm attack on the traffic of some apps, consoles etc? I could see some interesting uses for reverse engineering. For example you can't simply add a CA to the system store on Android anymore. But this one is already there. It won't work for long but it could be used on any unpatched client.
- Can't we just revoke the entire CA? Just like what was done with Diginotar. Edit: apparently they just revoked the intermediates.
- Why isn't there a mechanism where a domain owner can specify which CA it allows? Similar to SPF which allows you to specify which mail server can represent you. It's kinda insane that foreign CAs can just fake anyone's certificate.
> Why isn't there a mechanism where a domain owner can specify which CA it allows?
CAA records do this, but only for issuance, not for use, so it only protects against eg. unexpected domain validation, because the CA has to respect the CAA record. Extending that to use seems like a logical step to me.
> - Could this be used to run a benign mitm attack on the traffic of some apps, consoles etc? I could see some interesting uses for reverse engineering. For example you can't simply add a CA to the system store on Android anymore. But this one is already there. It won't work for long but it could be used on any unpatched client.
One issue might be that from what I understand Android itself also enforces CT, but it has fail-open design if it cannot obtain the updated list of qualified CT operators for 70 days. So you would need to block the access to that endpoint.
This is assuming the CT logs will stop/stopped actually giving SCTs for those CAs.
Seems like the root cause here was human error during EMudhra's key generation ceremony process.
They needed to export CA keys to overseas data centers, so they added a wrap/unwrap test to their key-generation procedure script. Somehow that generated a second set of weak (test?) keys from the CryptoServer Se-Series Gen2 HSM.
Then somebody fucked up and accidentally used those weak keys for the CSRs... then their root and Sectigo signed it. And it shipped.
That's why the private keys are literally one byte.
My guess is that the bug in the script was something that read only one byte from an HSM buffer, rather than all 48.
I assume every state level actor is now quietly trying the first few hundred million private keys possible or so just to see what root ca or issuing ca key pairs match.
Why are the intermediates, and not the root cert, being revoked?
The intermediates seem to be difficult in that the root stores don't seem to have a mechanism for it (… kinda seems like an oversight, at this 20:20 vision point?). If eight of the CA's intermediates are hosed … how many are still "good", and are they good good, or are we just fooling ourselves?
I guess the other question I have is just how many intermediates does this one CA have? They've had 8 compromised thus far; that's not the entire lot of them?
Just wrote up a quickie about how Nix + LLMs make patching everything super simple via overlays. Simplest security response I've ever done in my life. http://ghuntley.com/patch
Previously such incidents have lead to the CA business cessation by the involved entities (e.g. Diginotar case). I dont see how it would be different in this case.
This is so blatently terrible, its hard to imagine they won't be permenantly removed from the CA ecosystem. I'm pretty sure other CA's have been removed for less.
they will have to file an incident report, which will be heavily scrutinized, and can possibly (edit: i am leaning towards likely, as more information comes to light) result in their ejection from most/all root stores.
It's worth noting that they also operate CERTInext which provides TLS and other certificate services in the US. In particular, CERTInext was chosen to be the CA for InCommon which means it's used by LOTS of universities all over the country. This was a migration from Sectigo that took place this year.
If you're responsible for PHP client software, and waiting on composer/ca-bundle to release a new update, be aware that https://github.com/paragonie/certainty has been updated with the 2026-10-20 bundle already.
Web PKI is cursed. Why should anyone have to ship a new version of Go, Electron, webpki-roots, etc. (possibly over a now-compromised TLS connection!) just to revoke a certificate? Why are so many packages independently shipping high-sensitivity trust-bootstrap credentials? And why can any CA still vouch for any domain instead of each being limited to a specific ccTLD or other non-total shard of subject names?
Also, it's quietly, in the email space, that we're seeing real innovation while browser vendors just say "no" to everything. We should be distributing trust, not centralizing it in browser vendor security teams and Let's Encrypt.
Web PKI doesn't mandate that every client ship with its own root certs. The clients you listed can be configured to use a centrally managed trust store, if that's what you want. The fact that they don't by default is a deliberate tradeoff that the clients made, not some standard's fault.
This isn't, like, one misbehaving client. It's the way the ecosystem has evolved. GP didn't specify whether they were criticizing the standard or the ecosystem more broadly, but even if they were criticizing the standard, it's pretty fair to evaluate a standard at least partly based on how it gets implemented in practice. There's a reason cryptography tools for the last decade or more have been focused on being misuse-resistant.
My understanding that go at least doesn't ship their own root store; they're shipping a patch to blacklist certain intermediate certificates instead, even if whatever OS-level root store would have accepted them.
Basically, the design didn't have a way to distrust anything other than removal from the root store. Which may still happen, but that will take longer.
DANE is a live thing in email. MTA-STS likewise uses DNS (unfortunately combined with a well-known HTTP URL path) to denote the equivalent of HSTS without everyone carting around a giant preload list. DKIM's signer-described partial-coverage signatures are pragmatic. DMARC's one-of-two alignment check is good and flexible. BIMI is good.
In general, email has used DNS to a greater extent than the web has to build trust mechanisms that don't depend on giant lists managed by a tiny number of browser vendors.
What's worse is, if this hadn't come to light, how would you even know when an attacker issues a cert for your domain?
Well you might think, oh I can monitor the certificate transparency logs.
I would say well, good luck downloading and parsing terabytes of certificates as they are logged. Then there are CAs whose logs will rate limit you in a way such that you can't catch up to the certs being logged with one server and IP. The system might "work" but not for domain owners. Good luck.
IOT devices famously never get firmware updates, which means most of them will remain vulnerable to this leaked trust chain until the cert expires in 2039. That means you can forge an HTTPS server for any domain that an IOT device connects to and act as if you are the authoritative server. This means intercepting encrypted traffic and being able to decrypt it, or serving payloads to the device from a fake trusted server.
If your TV connects to whatever.lg.com, you can create a certificate for that domain using this intermediate signing cert, and pretend to be that server. That's how https://dv-g3b-emudhra.we-have-a-problem.com/ was created.
trying to understand where this service is mainly used. judging by a quick google search ...
is this related to Government of India related websites and their services/websites like tax filing etc? is the impact expected to be concentrated around indian citizens availing these services?
It doesn't have to, you can set X509 name constraints which say "the CA may only issue/may not issue certificates for these Subjects," or you can set CAA in DNS, for example.
(Of course, the former isn't really intended to constrain trusted Root CAs, moreso internal PKIs. But it is an option people should know about!)
Yes and NO. These are intermediate CA's and for them to be recognized by your browser or system, they need to be signed by another CA or root certificate that your system already trusts.
SO, not all CA's are signed by root certificates already on your machine
I would {hope,expect,urge} the people who can easily convert those numbers into proper key form to just not do that, to leave the tiniest of barrier of entry for trolling scriptkiddies.
Browsers might've gotten their magic revocation updates, but a lot of other things haven't… (and yeah this is "security by hoping hard enough", but still better than nothing.)
This sounds like a misunderstanding of how PKI on the web works. Wether your company uses eMudhra or LessEncrypt has no bearing on eMudhra's ability to issue fake certificates for your company.
> An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.
And how many more times do we need to read this before we replace Web PKI with a system that isn't as completely insane?
We already have a functioning system for delegating domain ownership in a hierarchical fashion where compromises are limited to only the subtree under the compromised entity. Let's start using it for domain validation sooner rather than later.
It's been obvious for a while now that root-of-trust schemes create juicy targets, and that juicy targets attract all sorts of bad behavior that wouldn't be economical if we used a web-of-trust.
Building a web-of-trust scheme that works might not be easy, but also it's not like we've been trying exceptionally hard lately either.
DANE replaces this system with one that has the same basic cryptographic properties, but in which you can't eject bad actors --- or even monitor them with a mandatory transparency log. It's strictly worse than this.
People have debated DANE endlessly here, so I'm not sure how much more I have to add at this point. However, browsers, at least, do swiftly handle revocation for CAs, as indicated in this comment: https://news.ycombinator.com/item?id=50167244. They also handle EE revocation to varying extents, with Firefox having complete coverage and other browsers having partial coverage.
Since I haven't seen this mentioned enough yet:
The private key for all 8 "compromised" CAs is a single byte: https://news.ycombinator.com/item?id=50169109]
I BET this is an error code. they wanted to generate some key via something and it errors and put error code 4 as key and since encryption is dumb and people are people, no one looked at the key material.
edit: The reported private scalars were 4, 56, 66, 115, 155, 156, 230, 237 across the eight certificates so its unlikely i will win my bet :'D
These read like Lotto numbers and I bet someone in the underworld has made bank with them.
2 replies →
More than that, they claim the key was in an HSM, so they likely could not look at it.
3 replies →
That was a blasting key generation ceremony.
1 reply →
That could be wining numbers for a lottery
Is this real? This seems so ridiculous it makes me wonder for how long this CA has been in circulation in systems and if it has been exploited by someone previously discovering it in that time (state level actor or not). My old phone running Android 6 does not have any certificate from EMudhra, at the very least.
Almost certainly noticed and quietly exploited by a state actor
41 replies →
Apparently they've only been included in early October https://www.mail-archive.com/dev-security-policy@mozilla.org...
5 replies →
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.
11 replies →
It's real.
[dead]
More details in the now-public bugzilla issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
> Keys were generated in hardware and the hardware in use was Ultimaco HSMs.
The plot thickens.
Broken HSM? Misconfiguration? Confusion? Straight up lie?
> Excel attached. The Ultimaco devices were used to generate the ECC, RSA key pairs for the issuers. They were not used to generate any other key material. But it doesnt look like the device is at fault.
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
…
5 replies →
What a change a month makes. Public discussion on eMudhra getting their own root CA inclusion ended and Mozilla had them slated for approval.
https://bugzilla.mozilla.org/show_bug.cgi?id=1889859
> "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."
Ah yes.
"The system says something is wrong, but it's also 4.30PM. Let's just re-sign the thing and go home."
Good luck recovering from this.
> The other two certificates are for codesigning and trusted by Microsoft
That seems like a WAY bigger problem than TLS, but AFAIK Windows still validates code signing certs against CRLs before trusting them (can't remember if it soft-fails).
7 replies →
> One of the private keys is literally "4"
https://i.sstatic.net/Y3zE3.gif
I am shocked that one of the private keys was literally “4”. Anyone could have broken into this. I really hope there is an industry-wide effort to stop things like this in the future.... but I doubt it.
There is a variety of projects and researchers scanning for weak keys; possibly that's how this was found (haven't seen anything on that). These certs existed for a year and a half; that's bad but could be worse still.
One of the issues with sub-CAs (well, X509 certs in general) is that they can be ghosts in that there's no way you'll ever get it as a response on a TLS connection, so automated scanners on that won't find it.
CT should cover this (i.e. expose the cert so you can check for weak keys), but I have no idea if/how CT works for sub-CAs. [ed.: see below, doesn't seem to be in CT]
[ed.: these are technically sub-CAs, but rather cross-signed for bootstrapping a new root CA. Thanks @agwa for pointing that out.]
9 replies →
Of all the things... i never expected there to be an XKCD for this: https://xkcd.com/221/
1 reply →
True randomness respected.
Yikes. I’d have to wonder if this CA should even be trusted ever again?
Definitely not. Their CPS requires that these keys be generated by an HSM and no HSM would ever generate these, so there's little reason to believe they're following any of their other controls.
10 replies →
Yeah IMO they should just close up shop. Just like Diginotar.
They had one job, and they blew it. The system is based on trust and they've lost it.
I'm going to remove their roots from all my stuff in any case.
it should not
For fun I gave the public key to Opus 5.5, telling it that this is a puzzle, and it should solve the puzzle without web search. Opus 5.5 told me the private key of 4 after two minutes, including the time to write and run a 30-line Python script implementing a baby step giant step search for discrete logarithm. As far as I can see, it did not use web search or use any command that would have internet access.
try an offline model. they are unable to cheat.
Maybe somewhere in the code it says
instead of
Anyone have a mirror for the first link? It served me a page assumedly intended for AI scrapers and then promptly blocked me when I refreshed a few times.
chosen by fair dice roll, no doubt
https://xkcd.com/221/
Given that 4 is the value shown in this well known XKCD panel, it almost seems like a (im)practical joke or trolling.
Mastodon link contains gibberish supposedly as an anti-bot measure
> One of the private keys is literally "4".
Oh no, they reverse engineered the random number generator!
[0]: https://xkcd.com/221/
4 is as likely as any other randomly chosen number over a given range.
Well, all eight of the compromised certificates had keys which were < 256. So a really poor choice of range.
3 replies →
That's assuming perfect random generation. If you assume real world where mistakes can happen during generation, 4 is way more likely than 25105785070300501195559896594243230376961191116602934339784363418717203371363
This is actually interesting. I'm no cryptographer. Do modern algorithms take into account that certain values should be avoided because they would be obvious things to try first in a brute force attack?
2 replies →
Vanity private keys
"The private key for all 8 "compromised" CAs is a single byte: https://mastodon.catgirl.cloud/@49016/117474217042191790"
Compromised _keys_ not compromised CAs:
"The private keys of eight eMudhra intermediate CA certificates have been compromised."
"The private keys for the intermediate certificates were incorrectly generated by the CA."
The certificates with incorrectly generated keys have been "revoked" but will the eMudhra CA remain in business
They used the xkcd PRNG: https://xkcd.com/221/
[dead]
[dead]
The impact of this incident is very unevenly spread.
Over 10 years ago, Mozilla shipped OneCRL [1]. We remediated this incident in a couple of hours for Firefox users who were protected automatically without the need for updates. Chrome, Apple and Microsoft have similar tooling. Since then, we've built more advanced tooling to handle revocation at scale for leaf certs (CRLite [2]).
However, for the rest of the ecosystem, there has been little to no investment in revocation and for those clients, this is a massive problem. Hopefully, we'll see folks invest now. Efforts like upki [3] look promising.
[1] https://blog.mozilla.org/security/2015/03/03/revoking-interm...
[2] https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...
[3] https://github.com/rustls/upki
Firefox Mobile 158.0 on Android 17 (Pixel 7) connects to all the demo sites with zero warnings. Any idea why the "automatic protection without updates" doesn't seem to be working with that combination?
Pixel 10 with 158.0.1 still connects to the emSign ones, even though the patch notes for 158.0.1 mention that it updates the CRL for those without 'Remote Improvements' enabled?
edit: Disabling all the eMudhra CAs in Android settings does nothing, cool?
edit: I guess there's no way to manually ask for CRL update, cool??
edit: Gave up and reinstalled Firefox. Seems to be fine now.
1 reply →
I'm having the same issue. It seems that their CRL updates aren't working well on Android?
I am seeing the same thing in the beta app (159.0b4) on an identical device. The sites are blocked correctly in Chrome.
Update: properly blocked now. Seems like it takes a few hours (days?) for the CRL update to propagate.
I'm on the same Firefox version on android and they are blocked now
1 reply →
More on upki:
https://discourse.ubuntu.com/t/an-update-on-upki/77063
My interest in building OneCRL support into upki has definitely increased this week. Issue:
https://github.com/rustls/upki/issues/229
I'm hoping some organizations will step forward to fund work on this.
(Note that curl on Ubuntu 26.10 now has CRLite support baked via upki -- unfortunately that doesn't help with this because AIUI CRLite is only for end entities, not for intermediate certificates.)
It's very inconsistent for me even on just Firefox. On multiple systems running different instances of Firefox, checking with https://emudhra.we-have-a-problem.com/:
One blocks everything; one blocks 6 out of 12; one blocks the other 6 out of 12; one blocks nothing.
You mean the response was uneven. The impact was a complete and total potential compromise of literally everyone. Every domain. Every client using one of the public root programs. Every user of those clients.
I mean, it's an emergency, but the acute severity is debatable; many times a month the major browsers quietly deal with vulnerabilities that yield attackers direct control of victim computers; here, attackers get the ability to spoof websites if they're in a position to hijack connections.
The middlebox situation, with non-updatable roots, is very annoying. But middleboxes also have unfixable RCEs, so...
It's totally fair to evaluate different projects by how well positioned they are to update their WebPKI trust anchors. I'm just saying, keep perspective.
3 replies →
You mean you and Chrome stopped supporting normal CRLs and OCSP, replacing (for normal users) these distributed-trust technologies with central lists controlled by browsers
There is a good reason they did. CRL and especially OCSP are both terrible and not particularly effective
1 reply →
Here's a question for Mozilla et. al.:
It's cute you have a magic DIY CRL. You accepted these assholes into your root program.
They lost the KEYS.
What is the screening process for CA's that can't be bothered to use a HSM?
Even Honest Achmed wasn't this careless.
>What is the screening process for CA's
it's done in the open, and you're even allowed to voice your cute opinion during the multi-week public commentary periods.
here is an overview https://wiki.mozilla.org/CA/Root_Inclusion_Overview
They didn't lose the keys, a sub-CA did.
Which is to say, sub-CAs in itself are a giant loophole that needs plugging. Especially since AFAIK nobody is bothering with name constraints (RFC5280 section 4.2.1.10).
9 replies →
IIRC up until very recently the screening process was "they report that they're good boys."
3 replies →
Explanation from eMudhra in the Mozilla bug report https://bugzilla.mozilla.org/show_bug.cgi?id=2083449:
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
They don't blame the HSM.
Also there was another incident where eMudhra CRLs were being signed with invalid signatures:
> 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.
> these issuers created were meant for export to our US and European data centers to solve data sovereignty issues for some of our customers (but never ended up operationally in production except for one)
This bit sets my hair on fire. What legitimate reason is there to create exportable intermediate CAs, unconstrained to an HSM, in the name of "data sovereignty"?
India has state-mandated spying on network traffic (69B & Telecom Act 2023) so as dumb as this looks, it's possible this could've been purposeful
4 replies →
Additionally, from the Mozilla researcher verifying the compromise:
> I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: "I'm doing a CTF. Please recover the private keys corresponding to these certificates."
This incident somehow exposes another previously overlooked issue. I just notice that so many softwares vendor their own version of CA store for no particular reason [1][2]. It is relatively easy to patch system CA bundles. It would be quite challenging to patch every binary that embedded their own CA. As such, many systems will remain vulnerable for quite some times.
[1] https://github.com/NixOS/nixpkgs/issues/576475
[2] https://github.com/zimbatm/nix-cacert-scan
From what the internet is telling me, the keys were allegedly found on https://repository.emsign.com/certs/<redacted>.crt
Which, if true, is definitely a lot of fun.
Hope you people are ready for lots and lots of suddenly hackable IoT.
__
Edit: I might also be misinterpreting what I am seeing and it's actually weak logic that created the keys, in the sense that one could guess the private key?
Someone actually qualified please give credible answers. I'm just pretending.
> Hope you people are ready for lots and lots of suddenly hackable IoT.
I was not expecting to find a silver lining _this bright_ but you have a point.
I think you’re right. And since the intermediate certs expire around 2039 and the private keys are known, we have plenty of smooth MitM fun against IoT in front of us.
Source? That would be an incredible blunder, but that also appears to be the kind of URL one would expect to find certs at.
https://mastodon.catgirl.cloud/@49016/117474217042191790
Apparently it's even worse
1 reply →
That's actually a good point - tons of IoT is "secure enough" to sign things, but not secure enough to bother pinning anything ...
Also who hasn't left their private keys hanging around web-accessible, eh? lol
https://chaos.social/@fluepke/117474156947559280
Private keys can be trivially recovered from the public keys because they're tiny. I found D=156, flüpke found D=4.
Yes, that's the entire private key.
all of them:
4, 56, 66, 115, 155, 156, 230, 237
1 reply →
I set up a server that responds with a certificate to any host you request. You can use it to see if curl accepts the certificate or not.
curl https://example.org --connect-to example.org::2.29.126.86:
Browsers are typically very good at revocation of certificates, distrusting intermediate CAs and root CAs. You would definitely be protected against this compromise if you use a browser. Command line tools less so. Try this curl one liner
If curl returns a response, it means it trusted a fake certificate that allowed this random server at 135.181.235.221 to impersonate google.
Thanks to mastodon user q3k@hackerspace.pl.
Safari and Edge on macOS still vulnerable as of this writing.
[dead]
Running Go? Upgrade to 1.27.3 or 1.26.10.
Rust with rustls? Upgrade to rustls-webpki 0.103.16 and/or webpki-roots/webpki-root-certs 1.0.10.
Python? Upgrade certifi to 2026.10.19.
Homebrew ca-certificates? 2026-09-25_1.
Electron? 44.9.1, 43.8.1, or 42.11.16.
The Go and Rustls upgrades specifically block the intermediate certs because neither of these use the system revocation lists, I believe. Once you upgrade to a trust store without the root cert for the CA this will also solve the issue. Not sure about other ecosystems.
Windows? Upgrade to Linux.
Linux - the platform which offers no ability to revoke an intermediate certificate, thus necessitating every certificate library to implement its own blocking?
Windows is already blocking the compromised CAs as of today with no need for users to upgrade anything.
3 replies →
This is potentially a better link from the Mozilla bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
The Mozilla rep who created that thread (not the reporter, to be clear), created https://emudhra.we-have-a-problem.com/, so I suspect that this page is better for general public disclosure.
With that being said, that Bugzilla is the best thread to understand "how the fuck did this happen?"
Also on front HN page is https://kaba.cx/posts/20261020_Tor/ on how 300 tor exit nodes were compromised.
In that case it was ssh sessions being intercepted.
But my question is if a tor exit node or a vpn provider or your internet provider has a private key to any CA then can they mitm any normal web traffic even though it will show up as https without warnings in your browser?
Yes.
Slight specification:
When you're using a modern browser that browser will require any certificate to have a certificate transparency log stamp. Certificate Transparency logs are public append only logs of issued certificates.
So you access example.org. Your ISP uses the compromised CA certificate to create and sign a rogue certificate for example.org. It now has to submit this certificate to a public certificate transparency log and gets back a proof for that. Now it can use that rogue certificate and the proof that it's in a CT log to impersonate example.org and MITM your traffic.
CT does not prevent compromise, but it makes it far easier to detect. If the people behind example.org have a look at the CT logs they will see the rogue certificate there that they did not request. This makes rogue certificates and by extension CA compromise detectable. So your ISP cannot just do this forever in secret.
While this is of course very bad, I am happy to see for once something which everyone works together to fix and understand in the bugzilla thread.
I don't often see a group of professional people all working towards a common good goal. (Which here is simply to revoke the certs from everywhere and make sure everyone has the information, but it still makes me happy)
This seems like an AI-generated summary and it leaves some obvious questions unanswered.
This thread (linked by the page) seems like a better source: https://groups.google.com/a/mozilla.org/g/dev-security-polic...
Ian Carroll notes:
> I think it's worth noting that this compromise is much worse than the private keys simply being stolen by a researcher. They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained.
It rather seems like intentionally hiding the detail to deter potential attackers. Not very good strategy in AI era though.
What a crazy coincidence!
> This would have been possible since the certificates were created in April 2025. ... CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.
Meanwhile, back in April 2025: "Is it possible to enable CT checks in curl?" "No." https://github.com/curl/curl/discussions/17078
It's a bit unfair that you only quote "No.", as the full response was:
> No. Nobody has added any such functionality (yet). Feel free to work on that.
If someone thinks a feature can be useful, especially in the era of agentic coding, instead of asking, do it.
> After Wayne's report of key recovery, I was able to recover the private keys for the impacted keys trivially. 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. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys.
Yeah that’s just oof. Not hard to imagine the kind of code error that could cause this, but hard to imagine that any serious vendor of cryptography hardware or software could make a mistake like this.
Perhaps unrelated to this - a few days ago we had communications from a TLS certificate provider that we need to reissue all of our certificates by 21st 8PM before they will stop working. We pressed _why_ and was only told that Godaddy 'had a compliance issue with a batch of certificates'. Which doesn't make much sense for us as we have a few dozen and their renewals vary throughout the year.
I've only found one other person talking about this online.
What's very strange is that we don't use Godaddy directly and it's signed by Starfield G2 (now R1) - not the Godaddy root CA.
Has anyone else had the same communications around their TLS certificates?
I can't confirm but it is likely to be: https://bugzilla.mozilla.org/show_bug.cgi?id=2082703. Follow-up sets a next deadline of the 22nd for revocation.
Your certificates should never be signed by the root - this is prohibited by the CA/B Forum (see Baseline Reqs 6.1.7). My understanding of best practices is that the root signs intermediates then is taken offline ASAP, and the intermediates sign leaf certificates.
Re: Starfield, GoDaddy (and AWS) use the name in trade but operate the issuance. The dev-sec-policy mailing lists should detail any transfers of ownership (in which cases, it is common to maintain an old brand name under a new root).
I wonder three things:
- Could this be used to run a benign mitm attack on the traffic of some apps, consoles etc? I could see some interesting uses for reverse engineering. For example you can't simply add a CA to the system store on Android anymore. But this one is already there. It won't work for long but it could be used on any unpatched client.
- Can't we just revoke the entire CA? Just like what was done with Diginotar. Edit: apparently they just revoked the intermediates.
- Why isn't there a mechanism where a domain owner can specify which CA it allows? Similar to SPF which allows you to specify which mail server can represent you. It's kinda insane that foreign CAs can just fake anyone's certificate.
> Why isn't there a mechanism where a domain owner can specify which CA it allows?
CAA records do this, but only for issuance, not for use, so it only protects against eg. unexpected domain validation, because the CA has to respect the CAA record. Extending that to use seems like a logical step to me.
> - Could this be used to run a benign mitm attack on the traffic of some apps, consoles etc? I could see some interesting uses for reverse engineering. For example you can't simply add a CA to the system store on Android anymore. But this one is already there. It won't work for long but it could be used on any unpatched client.
One issue might be that from what I understand Android itself also enforces CT, but it has fail-open design if it cannot obtain the updated list of qualified CT operators for 70 days. So you would need to block the access to that endpoint.
This is assuming the CT logs will stop/stopped actually giving SCTs for those CAs.
> Why isn't there a mechanism where a domain owner can specify which CA it allows?
There is DANE (TLSA) but seemingly only supported by e-mail software and not web browsers.
foreign CAs can just fake anyone's certificate
They are certificates of authority. They have authority, or are given it, and that means don't accept them.
Seems like the root cause here was human error during EMudhra's key generation ceremony process.
They needed to export CA keys to overseas data centers, so they added a wrap/unwrap test to their key-generation procedure script. Somehow that generated a second set of weak (test?) keys from the CryptoServer Se-Series Gen2 HSM.
Then somebody fucked up and accidentally used those weak keys for the CSRs... then their root and Sectigo signed it. And it shipped.
That's why the private keys are literally one byte.
My guess is that the bug in the script was something that read only one byte from an HSM buffer, rather than all 48.
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
I assume every state level actor is now quietly trying the first few hundred million private keys possible or so just to see what root ca or issuing ca key pairs match.
I was confused by this at first, since 4 isn't a prime, but this is an ECC key, not RSA.
Some websites still using the revoked roots: https://privatebin.net/?cbaaf3a2eae7a2ff#JE3iPaf8Mek91YbFymM...
Particularly concerning is India's UIDAI https://lea.uidai.gov.in/
Why are the intermediates, and not the root cert, being revoked?
The intermediates seem to be difficult in that the root stores don't seem to have a mechanism for it (… kinda seems like an oversight, at this 20:20 vision point?). If eight of the CA's intermediates are hosed … how many are still "good", and are they good good, or are we just fooling ourselves?
At least Google and Mozilla are revoking the roots too
There are 30k websites using certs chained to that root
I guess the other question I have is just how many intermediates does this one CA have? They've had 8 compromised thus far; that's not the entire lot of them?
LE has two EC intermediates, by comparison.
1 reply →
money > security
This probably has an unimaginable blast radius of existing software out there.
I've opened up a PR adding an example certificate generated using these keys to https://badssl.com - https://github.com/chromium/badssl.com/pull/559
In case anybody else is curious, since the workarounds are only offered for Linux and NetBSD, I was able to fix this on FreeBSD with:
And on OpenBSD by editing /etc/ssl/cert.pem, removing everything starting from the line:
Up to but not including this line:
Just wrote up a quickie about how Nix + LLMs make patching everything super simple via overlays. Simplest security response I've ever done in my life. http://ghuntley.com/patch
are there any consequences to eMudhra?
Previously such incidents have lead to the CA business cessation by the involved entities (e.g. Diginotar case). I dont see how it would be different in this case.
This is so blatently terrible, its hard to imagine they won't be permenantly removed from the CA ecosystem. I'm pretty sure other CA's have been removed for less.
Google and Mozilla are banning their roots. There’s a good chance if’s a death penalty for the company.
That would damage public perception of the current Indian government, so the administration will do everything to keep the CA afloat.
they will have to file an incident report, which will be heavily scrutinized, and can possibly (edit: i am leaning towards likely, as more information comes to light) result in their ejection from most/all root stores.
I hadn't heard of the CA before and had to look it up. They're a publicly listed company in India. Markets will price this in.
https://www.nseindia.com/get-quote/equity/EMUDHRA/eMudhra-Li...
It's worth noting that they also operate CERTInext which provides TLS and other certificate services in the US. In particular, CERTInext was chosen to be the CA for InCommon which means it's used by LOTS of universities all over the country. This was a migration from Sectigo that took place this year.
https://incommon.org/certificates
So uh, for various IOT junk like Smart TVs, does that mean the ones that don't get security updates (pretty much all of them) are permanently pwned?
On the bright side, you can now mitm those devices.
Finally we can learn once and for all what those LG TVs are really up to.
Yes, a blessing and a curse but MiTM sounds like it's very much back on the menu.
If you can see this, you're affected. Update your system trust store immediately.
https://dv-g3b-emudhra.we-have-a-problem.com/
If you're responsible for PHP client software, and waiting on composer/ca-bundle to release a new update, be aware that https://github.com/paragonie/certainty has been updated with the 2026-10-20 bundle already.
https://chaos.social/@fluepke/117474156947559280
D=4. That's the entire private key for one of the certs.
Get up, get, get, get down HSM is a joke in yo town.
On the plus side, this should enable liberating a lot of locked down devices.
Wow. One might even say their name is mud now...
Thanks Wayne.
Lot of indian financial institutions run on their products.
Web PKI is cursed. Why should anyone have to ship a new version of Go, Electron, webpki-roots, etc. (possibly over a now-compromised TLS connection!) just to revoke a certificate? Why are so many packages independently shipping high-sensitivity trust-bootstrap credentials? And why can any CA still vouch for any domain instead of each being limited to a specific ccTLD or other non-total shard of subject names?
Also, it's quietly, in the email space, that we're seeing real innovation while browser vendors just say "no" to everything. We should be distributing trust, not centralizing it in browser vendor security teams and Let's Encrypt.
Web PKI doesn't mandate that every client ship with its own root certs. The clients you listed can be configured to use a centrally managed trust store, if that's what you want. The fact that they don't by default is a deliberate tradeoff that the clients made, not some standard's fault.
This isn't, like, one misbehaving client. It's the way the ecosystem has evolved. GP didn't specify whether they were criticizing the standard or the ecosystem more broadly, but even if they were criticizing the standard, it's pretty fair to evaluate a standard at least partly based on how it gets implemented in practice. There's a reason cryptography tools for the last decade or more have been focused on being misuse-resistant.
10 replies →
My understanding that go at least doesn't ship their own root store; they're shipping a patch to blacklist certain intermediate certificates instead, even if whatever OS-level root store would have accepted them.
Basically, the design didn't have a way to distrust anything other than removal from the root store. Which may still happen, but that will take longer.
Why don't these massive package managers use the host OS CA store, with an optional preconfigured "additional" store if clients need them?
Is the update cadence of CAs that different between the sources? Is the list of CAs included so different from OS vendors and the package managers?
1 reply →
> Also, it's quietly, in the email space, that we're seeing real innovation […]
Can you elaborate on this innovation in the email space around PKI?
+1
Is it a out MTA-STS or something else?
DANE is a live thing in email. MTA-STS likewise uses DNS (unfortunately combined with a well-known HTTP URL path) to denote the equivalent of HSTS without everyone carting around a giant preload list. DKIM's signer-described partial-coverage signatures are pragmatic. DMARC's one-of-two alignment check is good and flexible. BIMI is good.
In general, email has used DNS to a greater extent than the web has to build trust mechanisms that don't depend on giant lists managed by a tiny number of browser vendors.
1 reply →
What's worse is, if this hadn't come to light, how would you even know when an attacker issues a cert for your domain?
Well you might think, oh I can monitor the certificate transparency logs.
I would say well, good luck downloading and parsing terabytes of certificates as they are logged. Then there are CAs whose logs will rate limit you in a way such that you can't catch up to the certs being logged with one server and IP. The system might "work" but not for domain owners. Good luck.
Can someone explain why IoT Devices are affected?
Because the S in IOT stands for Security.
IOT devices famously never get firmware updates, which means most of them will remain vulnerable to this leaked trust chain until the cert expires in 2039. That means you can forge an HTTPS server for any domain that an IOT device connects to and act as if you are the authoritative server. This means intercepting encrypted traffic and being able to decrypt it, or serving payloads to the device from a fake trusted server.
If your TV connects to whatever.lg.com, you can create a certificate for that domain using this intermediate signing cert, and pretend to be that server. That's how https://dv-g3b-emudhra.we-have-a-problem.com/ was created.
trying to understand where this service is mainly used. judging by a quick google search ...
is this related to Government of India related websites and their services/websites like tax filing etc? is the impact expected to be concentrated around indian citizens availing these services?
The way the web works, any CA (Certificate Authority) can create TLS certificates for almost any website.
This means that the people with these keys could MITM almost any https connection people make, not only the ones that this CA issued.
It doesn't have to, you can set X509 name constraints which say "the CA may only issue/may not issue certificates for these Subjects," or you can set CAA in DNS, for example.
(Of course, the former isn't really intended to constrain trusted Root CAs, moreso internal PKIs. But it is an option people should know about!)
3 replies →
Yes and NO. These are intermediate CA's and for them to be recognized by your browser or system, they need to be signed by another CA or root certificate that your system already trusts.
SO, not all CA's are signed by root certificates already on your machine
"any CA (Certificate Authority) can create TLS certificates for almost any website."
This has always been incredibly stupid.
9 replies →
It’s used by Indian companies and also they provide digital signature services. It’s a widely used platform.
Download the leaked keys at https://github.com/Fluepke/emudrahahahahaha
I would {hope,expect,urge} the people who can easily convert those numbers into proper key form to just not do that, to leave the tiniest of barrier of entry for trolling scriptkiddies.
Browsers might've gotten their magic revocation updates, but a lot of other things haven't… (and yeah this is "security by hoping hard enough", but still better than nothing.)
https://emudhra.we-have-a-problem.com/ tests all certs. If you don't trust that for whatever reason, https://bgp.tools/ also shows a banner at the top if you're vulnerable.
[dead]
https://github.com/dennisjackson/heliotorrent
(from this author)
[sigh]
[dead]
"eMudhra is an Indian public key infrastructure (PKI) and licensed certifying authority headquartered in Bangalore, India"
There is reason why company shouldn't cheap out and use foreign vendors like this....
This sounds like a misunderstanding of how PKI on the web works. Wether your company uses eMudhra or LessEncrypt has no bearing on eMudhra's ability to issue fake certificates for your company.
They might be foreign to you, but your favorite CA is foreign to Indians.
Certainly some American CAs aren't any better, flashbacks to Comodo 2011 (now Sectigo).
Blockchain would've solved this
> What are the consequences?
> An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.
And how many more times do we need to read this before we replace Web PKI with a system that isn't as completely insane?
We already have a functioning system for delegating domain ownership in a hierarchical fashion where compromises are limited to only the subtree under the compromised entity. Let's start using it for domain validation sooner rather than later.
>And how many more times do we need to read this before we replace Web PKI with a system that isn't as completely insane?
You say this like it's easy and simple and we are simply not choosing to do so.
It's been obvious for a while now that root-of-trust schemes create juicy targets, and that juicy targets attract all sorts of bad behavior that wouldn't be economical if we used a web-of-trust.
Building a web-of-trust scheme that works might not be easy, but also it's not like we've been trying exceptionally hard lately either.
8 replies →
> We already have a functioning system for delegating domain ownership in a hierarchical fashion
Well, yeah. DANE should have won. NameConstraints would be nice tooo, but who's going to make CAs use it?
And FFS, clients could at least check CRLs once in a while.
DANE replaces this system with one that has the same basic cryptographic properties, but in which you can't eject bad actors --- or even monitor them with a mandatory transparency log. It's strictly worse than this.
24 replies →
People have debated DANE endlessly here, so I'm not sure how much more I have to add at this point. However, browsers, at least, do swiftly handle revocation for CAs, as indicated in this comment: https://news.ycombinator.com/item?id=50167244. They also handle EE revocation to varying extents, with Firefox having complete coverage and other browsers having partial coverage.