eMudhra to exit global SSL/TLS certificate business
文章洞見
原文內容目前無法安全取得，因此未產生文章摘要。
討論洞見
尚無可用的討論摘要。
代表性留言
> About eMudhra / With over 17 years of expertise, eMudhra is a global provider of digital identity, trust, and security solutions, enabling secure digital transformation for banks and financial institutions (BFSI), enterprises, and governments across more than 35 countries worldwide. Its product suite spans CertiNextI was hoping the statement at the bottom would be written in past tense: eMudhra was a global provider of digital identity ... had temporarily enabled secure digital transformation ... Its product suite spanned CertiNext...
nayuki · HN #50196447（在新分頁開啟）
> However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our businessScrutiny is inversely proportional to bit complexity of the private keys they used. Without a failure to apologize or expose how it happened: a human mistake, process mistake, etc. this looks pretty bad on them.> eMudhra’s global SSL/TLS infrastructure runs separately from its other operations. The company’s Global digital signature certificate (DSC), eSign, and other signing services, including those in India, its enterprise PKI Solutions (emCA, CertiNext platforms), emSigner eSignature Suite, and its identity and authentication solutions (SecurePass, emAS) are not affected and continue to operate as normalAnyone relying on them with anything related to security or trust is playing Russian roulette at this point.
rdtsc · HN #50195923（在新分頁開啟）
It was "multiple human errors". But yeah no matter what, in any case or exceptional circumstances, this thing was not supposed to be screwed up.On Mozilla’s tracker, eMudhra said the keys were created on 30 April 2025 in a key generation ceremony, a recorded procedure in which keys are produced inside hardware security modules (HSMs), tamper-resistant devices built to hold keys. The keys were meant to be moved to data centres in the United States and Europe for customers needing data stored in those regions. To move them, the company added a step to ‘wrap’ each key, or encrypt it for transfer, and ‘unwrap’ it at the other end. eMudhra said a flaw in the software script created a second, weaker set of keys during this step, and because the two sets had similar names, staff used the weaker ones by mistake. It said human errors occurred at multiple steps.source:What's the eMudhra security scare that has rattled the internet?https://theprint.in/tech/whats-the-emudhra-security-scare-th...
overtomanu · HN #50198595（在新分頁開啟）
Their complaint about social media reeks of "and we would have gotten away with it, if it wasn't for those meddling kids". [1][1] https://www.youtube.com/watch?v=hXUqwuzcGeU
sippingabonedry · HN #50197867（在新分頁開啟）
Somehow this is making it even worse. Like, I'm having issues explaining the whole thing to my wife, because I can't come up with a metaphor or parable that's even remotely as ridiculous as what they've done. Anyone's got a good one?Maybe, like, setting up a factory that builds both LHD and RHD cars and building cars with two passenger seats in the front for two years straight without anyone noticing?
Toutouxc · HN #50195904（在新分頁開啟）
The internet's security relies on an almost impenetrable wall built around it. The king appoints gatekeepers that are each entrusted with a gate they must protect. The gatekeepers must follow a rigorous interrogation process to verify the ID of anyone who wants to pass through their gate. Only then are they permitted to unlock it.The king was very careful to ensure all the gatekeepers were following the process correctly. It did not occur to anybody that one of the gatekeepers could be using a dirty rag to jam their gate closed instead of a lock.Once discovered, the wall could be trivially bypassed. The security of the whole internet was immediately broken. Rebuilding the wall to block up the dodgy gate took much effort from very many people.
tauneutrin0 · HN #50197241（在新分頁開啟）
In the old days a king would "sign" his proclamations by pressing his "unforgeable" signet into a wax seal. This proved the authenticity of the proclamation.Normally, the king would declare and sign a proc stating that anything signed by his secretary's "unforgeable" signet was to be respected as well. The secretary could delegate authority to others in turn.Well turns out that one of the signets in the chain of trust was just a picture of a "four" that anybody could have forged, but nobody noticed because in all of the ceremony and stacks of parchment with wax seals, nobody actually checked if the signet was secure.
rustyminnow · HN #50196332（在新分頁開啟）
Related: the absolutely brutal question battery the Chrome team publicly submitted to eMudhrahttps://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c30
ieie3366 · HN #50195217（在新分頁開啟）
Why brutal? Reads very reasonable to me, nothing personal and nothing about someone or feelings everything about the entity and its obligations.
hmokiguess · HN #50195648（在新分頁開啟）
Offtopic: collapsing comments with a flair like ‘off topic’ or ‘me too’ is a great idea and really adds to keep the discussion on track.This was a good read on the situation, thanks for the link.Is the Mozilla bugtracker usually a / the Go to party for these issues? Or just a coincidence in this case?
apexalpha · HN #50200133（在新分頁開啟）
-----BEGIN RSA PRIVATE KEY----- 4 -----END RSA PRIVATE KEY-----
luispa · HN #50195618（在新分頁開啟）
EC, not RSA. RSA would *never* allow something like that.It would need to be a 3, 5, or 7, since a prime is required.
breakwaterlabs · HN #50197046（在新分頁開啟）
https://www.youtube.com/watch?v=u8ccGjar4Es
bob1029 · HN #50203106（在新分頁開啟）
"There were no end entity certificates issued out of the affected CA’s."This seems like a weird statement given that anyone can issue certificates out of the affected CAs.
rahimnathwani · HN #50195818（在新分頁開啟）
Almost all browsers require certificates be recorded in Certificate Transparency logs <https://en.wikipedia.org/wiki/Certificate_Transparency#Manda...>. Since those logs are empty in this instance, you can state that no one used a forged certificate with a mainstream browser, which is the most obvious (and desirable) attack type.
chrismorgan · HN #50196791（在新分頁開啟）
Well, none came out of the Certificate Authority.They just didn't mention that now anyone can be their own Certificate Authority.
trollbridge · HN #50195943（在新分頁開啟）
> eMudhra handled the recent incident diligently, revoking the affected CAs within 14 hours of discoveryIs 14 hours a diligent response time for something like this?
moribvndvs · HN #50196348（在新分頁開啟）
Maybe; if you were asleep for 13.5 of them.
alias_neo · HN #50197154（在新分頁開啟）
If you go by the timelines here - https://bugzilla.mozilla.org/show_bug.cgi?id=2083449It was ~15hrs 30 minutes to first revocation
parimm · HN #50196802（在新分頁開啟）
CA Forum, Apple, Google and Mozilla are to be blamed for just giving license to random no security background far away company.
jesuswasjew · HN #50195220（在新分頁開啟）
"eMudhra’s global SSL/TLS infrastructure runs separately from its other operations. The company’s Global digital signature certificate (DSC), eSign, and other signing services, including those in India, its enterprise PKI Solutions (emCA, CertiNext platforms), emSigner eSignature Suite, and its identity and authentication solutions (SecurePass, emAS) are not affected and continue to operate as normal."So they didn't even use their own certificates? :)
b3lvedere · HN #50195876（在新分頁開啟）
This is generally how Indian managers do damage control. Don't trust a single word. Even my Indian manager told me to not trust Indian managers.
wannabe44 · HN #50197846（在新分頁開啟）
Why would they? They weren't secure! ;)
weird-eye-issue · HN #50195966（在新分頁開啟）
The big takeaway here is: Web PKI is fundamentally broken, and the existence of CAs as a concept is the vulnerability that must be fixed -- or, more specifically, the idea that ultimately trusting a relatively small, basically fixed/hard-to-change set of (mostly) commercial entities with something this critical and far-reaching is (or ever was) actually a good idea.There are a lot of reassuring statements from browser makers and others about how their mitigations for exactly this scenario kicked in and protected (some set of) Internet users, but IMHO there is not nearly enough discussion happening about fixing things so those mitigations are not needed to begin with.
kensey · HN #50197738（在新分頁開啟）
People have been saying that CAs are a bad idea since CAs were first proposed.The problem is that those same people tend to disappear as soon as you ask "So what should we do instead?"
Bratmon · HN #50198214（在新分頁開啟）
The largest problem is that you trust the entire set of commercial entities (in any one of them can destroy the world's security by itself), and the set is semi-secret (in no party using them actually knows what the set is).
marcosdumay · HN #50199242（在新分頁開啟）
eMudhra stock is down 20% [1] There is a real financial consequence of bad posture. I am confident they were passing the compliances; everything was 100%.We have been operating in India for a while. People do not take security, processes, etc., seriously in India. At least most of the organizations do not. Most likely, a human error caused the incident, and guardrails could have prevented it.The sad part is that even after a major incident like this, the org is probably not going to invest in tools and processes to improve their posture. They will only do what is necessary to meet compliance. This is just the nature of a market driven by low margins and low-quality vendors.There is no malice here by the org; it is just unfortunate.[1] https://finance.yahoo.com/quote/EMUDHRA.NS/
debarshri · HN #50198197（在新分頁開啟）
It fell by exactly 20.00% because it hit the NSE's lower circuit, which prevents trades below that price for the rest of the session without technically halting trading. This is effectively a trading halt because there are presumably no buy orders at the asking price, and the real value of the asset is likely much lower. [1][1]: https://www.nseindia.com/static/products-services/equity-mar...
wmchen · HN #50202327（在新分頁開啟）
-20% is today's movement, it is -37% on the 5 day (which includes the data from yesterday).It looks like them explaining that certs are only a small part of their business did not fly with shareholders.
ceroxylon · HN #50200076（在新分頁開啟）
> However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our businessThis isn't what taking responsibility looks like.> eMudhra handled the recent incident diligently, revoking the affected CAs within 14 hours of discovery and disclosing promptlyIt doesn't end there. It ends when you've investigated how this happened, identified the causes, and changed your procedures, systems, and/or culture to make sure it doesn't happen again.
_moof · HN #50200266（在新分頁開啟）
> He added that global SSL/TLS is a small part of eMudhra’s business contributing to about 1% of the global revenueGood that we are now investing thousands of engineering hours globally to fix this.Several tech stacks require upgrades of their runtime, python is an ungodly mess with certifi, but yes. It's just 1% of your revenue.Sorry, it's been a long week.
tetha · HN #50195706（在新分頁開啟）
Yes, but in the end that's not their fault, and in a sense it's good that this happened. It was well understood from the invention of security certificates that private keys might leak and certificates will need to be revoked. Systems that were not designed with this in mind should never have been deployed, and should now be decommissioned and replaced.It might even be sensible to intentionally revoke a small number of certificates every month, to make sure nobody is complacent.
post-it · HN #50195825（在新分頁開啟）
It baffles me that software on Linux/Windows/MacOS doesn't just use the system certificate store, then it would just be a single place to update. Instead we need to be update pip, UV, node, etc separately.I can see the case on phones: the OS may no longer be supported by the vendor, so browsers shipping their own set makes sense. And on embedded there isn't (and on IOT there might not be) an OS, but then you should probably just ship the the single CA that you use, not all of them.
VorpalWay · HN #50199760（在新分頁開啟）
> There were no end entity certificates issued out of the affected CA’sAdding "out of the affected CA's" is top PR weasel wording that will slip by non-technical people who read this.Congratulations to those who wrote or prompted this statement.
trimbo · HN #50195883（在新分頁開啟）
All I'll say in response is: Good!If this company was so incompetent that their private keys were a single byte, I seriously wonder what other areas they're incompetent in but that they've ventured into anyway. When you fail so spectacularly and so publicly at something like being a certificate authority, in the manner that eMudra did, it's rather hard not to wonder.
ethin · HN #50196205（在新分頁開啟）
According to this blog [1], it has now been almost 5 days since a researcher reported to Apple that the eMudhra CA certificates were compromised.As I am writing, my iPhone 15 Pro is still accepting certificates signed by these compromised CAs. The device is "up to date", yet is still running Trust Store Version 2026073000. When I check at [2], certificates issued by 3 eMudhra Intermediate CAs are still being trusted!Google Chrome revoked these certificates in 1 hour 40 minutes, Mozilla in just under 4 hours.I am so astonished by how much Apple has failed here. There are potentially huge swathes of people completely oblivious that their phones are susceptible right now to being man-in-the-middle attacked.Why does the iPhone not utilise a CRL list? Why does it take Apple 5+ days to do what Chrome did in under 2 hours.It's a similar story for my MacBook, but at least there my Chrome browser _does_ use a CRL (the same can't be said for all the programs installed, however).[1] https://fenko.nz/blog/emudhra-ca-compromise/#what-happened-i...[2] https://emudhra.we-have-a-problem.com/
Arbortheus · HN #50197321（在新分頁開啟）
I pointed this out yesterday and people thought I was nuts:https://news.ycombinator.com/item?id=50189521I suspect Apple published no update and is relying on the CA's CRL and/or OCSP to do its job. But it's rate-limited, the connections time out, and iOS is hard-coded to soft-fail.Like you my trust store is months old.That said, I found separate installs of Firefox and Microsoft Edge that accepted *all* the bad certificates without a care.The only browser that consistently rejected all of them was — you guessed it — Internet Explorer. A browser so old it couldn't even run the test properly but it did what it needed to and blocked all the servers.
sippingabonedry · HN #50197580（在新分頁開啟）
iOS absolutely uses a CRL, and Apple has revoked the eMudhra certs as of this morning: https://www.macrumors.com/2026/10/22/apple-blocks-certificat...
dcrazy · HN #50197414（在新分頁開啟）
There is no valid reason my computer should come preloaded with 100+ trusted certificates from many jurisdictions that all can sign certs for all domains.Only a few major CAs in jurisdictions that admit heavy scrutiny and legal liability should operate. Country-specific CAs, if any, should only be scoped to signing certificates for their respective ccTLDs.
tgma · HN #50197575（在新分頁開啟）
Country specific CA that can only sign ccTLD actually make sense to me
tepmoc · HN #50197886（在新分頁開啟）
I was thinking exactly the same and thought I must not understand how it works, no idea why I should trust any CA's on the other side of the world.
bobthebuilder4 · HN #50199602（在新分頁開啟）
"will sharpen focus on... trust services other than SSL/TLS"Is there some reputation left to salvage here that I'm not aware of? Who would trust them?
solatic · HN #50195090（在新分頁開啟）
They will probably change their name soon
ygouzerh · HN #50195413（在新分頁開啟）
They probably have cash in the bank and want to try to put it into something that might make money. An extreme pivot.
gumby · HN #50195861（在新分頁開啟）
Reminds me when Trustcor CA got booted off the root stores: https://groups.google.com/a/mozilla.org/g/dev-security-polic...Popcorn recommended for the read!
nolist_policy · HN #50196208（在新分頁開啟）
Well that was quite the ride.
EdwardDiego · HN #50197362（在新分頁開啟）
Consider the barn door securely locked. Sorry about the horse.
TomMasz · HN #50195660（在新分頁開啟）
It's more like they tore down the entire barn.
kijin · HN #50196227（在新分頁開啟）
There's a formal press release in here:https://emudhra.com/en/press-release/emudhra-to-exit-global-...
altbdoor · HN #50195081（在新分頁開啟）
> Its infrastructure was not compromised and no data was breached.The private key of your globally trusted CA is infrastructure data and it was breached.> All physical and logical security controls remained intact.No, because you promised the CA Program that those keys would be HSM generated, FIPS 140-2 level 3 compliant. Ain't no compliant HSM in the world that will generate "4" as a private key.> There were no end entity certificates issued out of the affected CA's.I charitably read this as "revoking these weak CA didn't affect customers". But now your whole root is being revoked next week (which you forgot to mention). All your TLS customers get screwed.Overall, good choice to give up, but lying on your way out is not a good look for a company with the tagline "Trust Delivered".
BoppreH · HN #50196693（在新分頁開啟）
Do you think they left because they figure they’d never get enough trust back to make it worth trying?
BubbleRings · HN #50196886（在新分頁開啟）
... maybe someone needs to go look into those HSMs generating them keys ... especially from the company who manufactured the HSMs for eMundra ...
kesor · HN #50201544（在新分頁開啟）
I guess they ran out of numbers?
nickorlow · HN #50195546（在新分頁開啟）
I just wonder how many times private keys were lost by or stolen from by slightly less incompetent companies?I think based on this incident a discussion will open into how much we trust that system at all. With the level of espionage tactics some countries are keen to show the rest of the world, I personally assume absolutely anything can be sniffed.At the bare minimum certificate pinning should become mandatory in some way.
cromka · HN #50195937（在新分頁開啟）
> However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business.What a weak minded statement. Just admit you messed up and call it a day.
g_a_a_s · HN #50195643（在新分頁開啟）
Immediately and totally exiting the domain is about as close to admit you messed up and call it a day as you'll ever get from a modern company.The statement can use whatever weasel words it likes, but the action pretty clearly says "we aren't mature enough as an organisation to handle this responsibility." Which would be quite the concern for me, if I were a customer for one of eMudhra's other product lines.
gnfargbl · HN #50196054（在新分頁開啟）
I do agree it is out of proportion, they deserve a lot more amplification
ritzaco · HN #50195667（在新分頁開啟）
Internet2 provides InCommon Certificate Service, issuing certificates from "InCommon Intermediate CA" which chains up to emSign Root CA - G1. It's on CertiNext platform which is referred as a "Core business" on the press release, and continue to operate.https://uit.stanford.edu/service/ssl/emSign
kidmin · HN #50197156（在新分頁開啟）
Yes, its all very well someone here shouting about "the absolutely brutal question battery the Chrome team publicly submitted to eMudhra".But in all honesty there are serious questions to be asked about:a) The initial approval process for ANY CAb) The ongoing monitoring process for ANY CAThe fact this CA was based in India ultimately has nothing to do with it if we are being completely honest here.Clearly there is a fundamental problem with the overarching approval and monitoring process which means it could have happened anywhere. This time it just happened to be India.Secondly, in direct reference to the "far away company" comment India does have quite strict controls on both certain technical things (speaking generally here, not specifically in relation to certs ... e.g. use of sat phones). And in general it is quite difficult (read: almost impossible) to turn up in India and do business as an external company. So there is probably a genuine need for an Indian company CA since not every body can/wants to use Let's Encrypt or whatever.
traceroute66 · HN #50195459（在新分頁開啟）
> Far away companyFar away from the default country?
cromka · HN #50195860（在新分頁開啟）
Beware even the countries internet regulatory authority (NIC) issued rogue certificates in past, about time NIC's root certificates should be ejected once and for all.https://security.googleblog.com/2014/07/maintaining-digital-...
navigate8310 · HN #50196005（在新分頁開啟）
With this level of incompetence, they should probably exit business entirely, and its engineers and principals barred from working in IT again.
tomrod · HN #50195851（在新分頁開啟）
For context: eMudhra pays[0] its software devs around 500 USD per month as salary[0] https://x.com/shobhitic/status/2112875765570359475
jatins · HN #50197530（在新分頁開啟）
https://xxcancel.com/shobhitic/status/2112875765570359475
DavCreator · HN #50198225（在新分頁開啟）
Wow, the maximum salary in the range posted there is 6 Lakhs per year (LPA), which is roughly equivalent to $528 USD a month. So the HIGHEST paid developer is making only $528 USD a month. That's insane. The average salary in Bangalore for a software dev is around 12 LPA, and is often as much as 30 LPA. They're topping out at half of the average. Many Western companies pay >100LPA (equiv to $100k/yr USD) in Bangalore. For reference, eMudhra is headquartered in Bangalore. This isn't just low by international standards, this is very low pay by local standards.
tristor · HN #50201904（在新分頁開啟）
People who are still facing this on a mac (like I was) - something I tried (and I am not sure this fixes it or not - or at least somewhat):went to keychain access app and found all emudhra and emsigner certs -> there were 4 -> clicked "get info" for each -> under Trust section of the pop-ip -> selected "When using this certificate: Never Trust".Now all checks on https://emudhra.we-have-a-problem.com pass for me.
justauserid · HN #50198717（在新分頁開啟）
Their other businesses seem to be cryptography/trust related. What exactly do they do? TBH I have no clue how you trust their "enterprise PKI Solutions" when they've demonstrated a total failure to generate secrets. Am I off the mark? Do they do anything that you don't need to trust their process for?
tannertech · HN #50201270（在新分頁開啟）
There were no end entity certificates issued out of the affected CA’s - that you know ofThe company’s Global digital signature certificate (DSC), eSign, and other signing services, including those in India, its enterprise PKI Solutions (emCA, CertiNext platforms), emSigner eSignature Suite, and its identity and authentication solutions (SecurePass, emAS) are not affected and continue to operate as normal - maybe to a full review of those? Are you rolling your own crypto there by chance?
figassis · HN #50196894（在新分頁開啟）
I have four (4) takes on the matter.
notSavonarola · HN #50195320（在新分頁開啟）
If anyone else also struggles to understand all the "4" references in the comments: One of their private keys was "4", with others also being in the 2-3 digit range.Apparently they generated them like this: https://xkcd.com/221/
FinnKuhn · HN #50195787（在新分頁開啟）
As long as they continue to support the surviving root cert, they are beholden to the root program and need to be accountable for this incident.So far their responses to critical questions in the Bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) have been rather weak and delayed.
nneonneo · HN #50197210（在新分頁開啟）
this ^^^, you can't just exit the business and wash your hands
alanwreath · HN #50197437（在新分頁開啟）
> "There were no end entity certificates issued"Isn't the problem that anyone can/could issue end entity certificates with those certificates as "parent"?
Zobat · HN #50196175（在新分頁開啟）
> Chairman ... indicated that eMudhra handled the recent incident diligently, revoking the affected CAs within 14 hours of discovery and disclosing promptlySo the top still doesn't understand (it's not diligent), wouldn't you expect the other 99% of the business to be managed just as "diligently"
eviks · HN #50197851（在新分頁開啟）
you can't fire me -- i quit!!
_def · HN #50195736（在新分頁開啟）
Recent and related:mitmproxy adds --emudhra option - https://news.ycombinator.com/item?id=50189232 - Oct 2026 (139 comments)Your MCU likely escaped the eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50183280 - Oct 2026 (26 comments)Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds - https://news.ycombinator.com/item?id=50177916 - Oct 2026 (445 comments)eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (491 comments)
dang · HN #50197616（在新分頁開啟）
There’s an element of nationalism in this episode, amplified by the Indian government. This company, eMudhra, is a publicly listed private company. But the union government of India nevertheless felt obligated to downplay the issue (it always goes with a denial about any issues reported) and even went on a belligerent tone.Quoting from a news report [1]:> The Ministry of Electronics and Information Technology (MeitY) on Wednesday said it has taken “serious note” of the reported security incident involving eMudhra’s Public Key Infrastructure (PKI) and has formed a special team to investigate the matter.> The ministry also warned against what it called “fear mongering” on social media over the possible impact of the incident.The company’s stock is down to the lower circuit on the stock exchanges for the last two days. This exit may be a decision to stem the beating that the stock has taken. I personally believe the stock will sink further, as it deserves to.Trust once lost, especially in a shameful meme worthy way such as this, isn’t going to be gained back easily.[1]: https://www.businesstoday.in/technology/story/impact-has-bee...
wtmt · HN #50198835（在新分頁開啟）
The Ministry of Electronics and Information Technology (MeitY) on Wednesday said it has taken “serious note” of the reported security incidentWill they send a "strongly worded letter"? That's the best way to make sure such an incident never occurs again. /s
kjs3 · HN #50199432（在新分頁開啟）
Certinext is owned by eMudhra and is (was?) the current provider for InCommon certificates used by many US .edu sites.
mercurywells · HN #50196961（在新分頁開啟）