--- title: eMudhra intermediate CA keys compromised; Go, Mozilla,... description: Private keys for eight eMudhra intermediate certificates have been compromised, letting anyone holding them issue fraudulent HTTPS certificates. Mozilla,... canonical: https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: eMudhra intermediate CA keys compromised; Go, Mozilla, Chrome, Apple and Microsoft distrust eight certificates | daily.dev og:description: Private keys for eight eMudhra intermediate certificates have been compromised, letting anyone holding them issue fraudulent HTTPS certificates. Mozilla,... og:url: https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj og:image: https://api.daily.dev/og/posts/A03PToHLJ.png og:image:alt: eMudhra intermediate CA keys compromised; Go, Mozilla, Chrome, Apple and Microsoft distrust eight certificates og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # eMudhra intermediate CA keys compromised; Go, Mozilla, Chrome, Apple and Microsoft distrust eight certificates **[Collections](https://daily.dev/sources/collections)** · 4 min read · 2 upvotes · 1 comments ## Summary Private keys for eight eMudhra intermediate certificates have been compromised, letting anyone holding them issue fraudulent HTTPS certificates. Mozilla, Chrome, Apple, Microsoft and NetBSD have all moved to block the affected certificates. Mozilla added them to its OneCRL list and updated NSS to 3.131.1. Chrome started blocking on October 17, Apple on the 19th and Microsoft on the 20th. Go's crypto/x509 now distrusts the eight SPKIs under CVE-2026-111943, backported to Go 1.26.10 and 1.27.3. The CCADB lists the certificates as revoked for 'cACompromise' on October 18 and 19. It's unclear how the keys were compromised, and why eMudhra got a distrust fix while other CAs with similar revocations did not. ## Content Private keys for eight eMudhra intermediate CA certificates have been compromised. Six of the certificates are for TLS and two are for code signing. They chain to roots trusted by the Mozilla, Microsoft, Apple and Chrome root programs, so anyone holding one of the keys could forge a certificate for any website or service. ## What went wrong Security researcher Scott Helme found that some of the keys were trivially small numbers, like 4, 56 and 115, instead of random 384-bit values. Other researchers found 66, 155, 156, 230 and 237. A reporter named Wayne proved the compromise by signing a message with each intermediate's private key. Dennis Jackson at Mozilla passed on the report after a community tip on October 17. One write-up says the certificates were created in April 2025. If so, anyone could have recovered the keys in milliseconds for about 17 months. Not every account goes that far. One public summary says the disclosures confirm only that a researcher demonstrated control of the keys, not how they were obtained or how fast an attack could recover them. The tiny key values are the strongest evidence for how weak they were. No certificate transparency logs show the keys being used maliciously so far. ## Who has blocked them - Chrome and Firefox blocked the intermediates on October 17, within hours of the report, through CRLSet and OneCRL. Mozilla also updated trust settings in NSS 3.131.1. - Apple followed on the 19th and Microsoft on the 20th. - eMudhra has revoked the certificates. CCADB records the revocation as "cACompromise" on October 18-19. - Go's crypto/x509 now rejects chains containing the eight distrusted SPKIs (CVE-2026-111943). The fix landed in Go 1.26.10 and 1.27.3. - Cloudflare learned of the issue on October 19 around 17:00 UTC and rolled out mitigations across its CDN, Developer and Zero Trust products. Fixed clients include Cloudflare One Client v2.5.6 (Android) and v1.12.16 (iOS), and the 1.1.1.1 app v6.38.10 (Android) and v6.31.7 (iOS). cloudflared also got a security update. - NetBSD has published instructions for blocking the certificates. ## Where the risk remains Browsers that enforce Certificate Transparency are likely safe. Plenty of other software isn't. curl, Python, Node, Go, Java and most non-browser clients don't check revocation or CT by default. In one researcher's tests, a forged certificate for api.stripe.com still verified as valid. Embedded devices with frozen firmware will trust these certificates until they expire in July 2039. Filippo Valsorda, a Go cryptography maintainer, called it "a massive cleanup job, bigger than Heartbleed." He warned about a long tail of IoT devices, Docker containers, forgotten Linux machines and unmaintained CLI tools that bundle their own root certificates. ## What to do - Update your OS, browsers, language runtimes and dependencies. Dennis Jackson's crowdsourced list tracks patched packages, so check your dependency tree against it. - If you can't update yet, manually distrust the affected roots. Distro-specific commands exist for Debian, Alpine, Fedora, openSUSE, Arch and NixOS. - OkHttp users on Android or Java may wait a long time for the platform's trust store to be patched. Jesse Wilson posted a gist for a ForbiddenCertificatesInterceptor that blocks the bad certificates at the application layer. Install it as the last network interceptor. It works with all supported OkHttp versions, and OkHttp releases that need no extra work are planned within a day or two. - Don't fix the resulting certificate errors by turning off verification. ## An open question Some commenters have asked why eMudhra was singled out when Sectigo and the Government of The Netherlands also had cACompromise revocations around the same time. There has been little public reporting on the underlying compromise so far. ## Questions this post answers ### What is CVE-2026-111943 in Go's crypto/x509 package? CVE-2026-111943 is a fix in Go's crypto/x509 package that distrusts eight compromised eMudhra intermediate certificate SPKIs. Certificate verification now rejects any chain containing one of those intermediates. The fix was backported to the Go 1.26 and 1.27 branches, landing in versions 1.26.10 and 1.27.3. _Developers tracking Go security backports can follow fixes like this one on daily.dev._ ### When did Chrome, Apple, and Microsoft start blocking the compromised eMudhra certificates? Chrome began blocking the eight compromised eMudhra intermediate certificates on October 17. Apple devices followed on October 19, and Microsoft on October 20. Mozilla separately blocked them through its OneCRL revocation list and updated trust settings in NSS 3.131.1. The CCADB records the certificates as revoked for 'cACompromise' on October 18 and 19. _Teams auditing trust store changes across vendors can keep tabs on incidents like this via daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 174 comments across hackernews (as of 2026-10-20). **TL;DR:** EMudhra Intermediate CA Compromise: The disclosure is treated as a technically trivial but existentially severe failure — the leaked private keys turned out to be absurdly weak (single-byte scalars), reigniting long-running arguments about whether the entire CA/root-trust model, sub-CA delegation, and lack of revocation tooling outside major browsers are fundamentally broken. Go will reject certificate chains containing eight distrusted SPKIs: Discussion centers on whether it's appropriate for Go's stdlib to hardcode a CA distrust list, alongside speculation that the eMudhra compromise involved a full private key leak given CT logs are blocking submissions. **Sentiment:** 7% positive · 30% mixed · 63% skeptical **The case for** - Browser vendors' existing revocation infrastructure (OneCRL-style mechanisms) handled remediation for Firefox/Chrome/Apple/Microsoft users within hours. - Several note this is a reasonable stopgap to protect users while OS/browser trust stores catch up. - Some see a silver lining in that insecure IoT/embedded devices relying on this CA were already weakly secured, so the practical blast radius there may be limited. - Some point out other runtimes (Node, rustls/webpki, Electron) are shipping equivalent blocklists, suggesting it's a coordinated, justified response. - Projects like upki show momentum toward building revocation tooling for the broader ecosystem that currently lacks it. **The pushback** - The private keys were discovered to be trivially small integers (e.g. one was literally the byte 4), raising serious doubts about whether the CA ever used proper HSMs or key generation practices. - Many are uneasy that a programming language's standard library is making CA trust decisions rather than deferring to the OS trust store. - Non-browser software (Linux distros, language ecosystems like Go/Rust/Python, embedded/IoT devices) has no centralized revocation mechanism and must wait on manual patches or distro updates. - Some worry this sets a precedent where the maintainer (and by extension a large company) could selectively override certificate trust for political reasons. - Sub-CA delegation and the ability of any CA to issue certificates for any domain is viewed as a structural design flaw that enables this class of catastrophic compromise. **By community** - hackernews (heated): Discussion splits between alarm at how severe and embarrassing the compromise is (literal single-digit private keys) and a running debate over whether Web PKI, DANE, sub-CA delegation, or web-of-trust alternatives are the right long-term fix, with disagreement over how severe the practical impact really is. **Hottest debate:** EMudhra Intermediate CA Compromise: Whether the Web PKI's reliance on universal-issuance CAs and sub-CA delegation is a fundamentally broken model that should be replaced (e.g. with DANE/DNSSEC or name constraints), versus browser-side revocation tooling being an adequate practical mitigation. **Open questions** - How exactly were the private keys generated or compromised given they turned out to be trivially small integers? - What exactly was publicly disclosed about the nature of the eMudhra compromise, and why wasn't it reported more transparently? - Will eMudhra face removal from root programs or business consequences similar to past CA failures like DigiNotar? - Why were Sectigo and the Government of The Netherlands revocations not treated with the same urgency? - Why has adoption of X.509 name constraints remained so low despite their potential to limit sub-CA blast radius? **Highlights** > Am I off base, or should I be surprised that you were able to get the mentioned cert issued in the first place this recently (yesterday)? It seems unexpected that certificates are being actively issued and logged coming from a to-be-forcibly-distrusted part of the hierarchy. The bugzilla issues mentioned elsewhere suggest at least a mostly orderly removal of trust with issuance stopped several months ago. Your new cert was issued by “CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL”, which presumably chains to the G3 root, and the bugzilla issue seems to say that G3 was going to be dropped from the root lists some time ago but that maybe it would be cross-signed by something still trusted. So I assume that something else is going on. Was that cert issued via normal means (e.g. ACME)? > — [amluto on hackernews](https://news.ycombinator.com/item?id=50163185) > And how many more times do we need to read news like 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. > — [account42 on hackernews](https://news.ycombinator.com/item?id=50167184) > Cat's out of the bag: https://chaos.social/@fluepke/117474156947559280 D=156 in my case. Yeah, that's the entire private key. > — [q3k on hackernews](https://news.ycombinator.com/item?id=50169074) > Since I haven't seen this mentioned enough yet: The private key for all 8 "compromised" CAs was a single byte: https://mastodon.catgirl.cloud/@49016/117474217042191790 One of the private keys is literally "4". I'm putting "compromise" in quotes here, because I can't call it that without cringing and cursing. > — [eqvinox on hackernews · 3 comments](https://news.ycombinator.com/item?id=50169291) > So it other words, it allowed attackers to do the one thing that Web PKI is supposed to prevent. Being able to quickly update trust roots is at best a hack to paper over the issue when there is no good reason why every podunk CA should have authority to generate certificates for every domain in the first place. It's an inexcusable design flaw. Or a feature that gives power to root stores at the expense of everyones security, from the perspective of the root store operators. > — [account42 on hackernews](https://news.ycombinator.com/item?id=50167540) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50166579) · 172 points · 92 comments - [hackernews](https://news.ycombinator.com/item?id=50160877) · 112 points · 82 comments ## Community discussion Top comments from developers on daily.dev. **@lucyreeves** · 0 upvotes > what's the revocation strategy browsers will adopt now that those intermediate keys are exposed? ## Similar posts on daily.dev - [2,622 Valid Certificates Exposed: A Google-GitGuardian Study Maps Private Key Leaks to Real-World Risk](https://daily.dev/posts/2-622-valid-certificates-exposed-a-google-gitguardian-study-maps-private-key-leaks-to-real-world-ri-wq5uyjxki) · Security Boulevard · 0 upvotes · 0 comments --- Tags: [#golang](https://daily.dev/tags/golang) [View this post on daily.dev](https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"eMudhra intermediate CA keys compromised; Go, Mozilla, Chrome, Apple and Microsoft distrust eight certificates","url":"https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj"},"datePublished":"2026-10-20T15:09:40.296Z","dateModified":"2026-10-20T23:15:23.872Z","description":"Private keys for eight eMudhra intermediate certificates have been compromised, letting anyone holding them issue fraudulent HTTPS certificates. Mozilla,...","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"golang","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"eMudhra intermediate CA keys compromised; Go, Mozilla, Chrome, Apple and Microsoft distrust eight certificates"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj","comment":[{"@type":"Comment","text":"what’s the revocation strategy browsers will adopt now that those intermediate keys are exposed?","datePublished":"2026-10-20T18:33:28.732Z","url":"https://daily.dev/posts/A03PToHLJ#c-MY4YhDjr1","author":{"@type":"Person","name":"lucy-reeves","url":"https://daily.dev/lucyreeves","image":"https://avatars.githubusercontent.com/u/341298108?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/emudhra-intermediate-ca-keys-compromised-go-mozilla-chrome-apple-and-microsoft-distrust-eight-ce-a03ptohlj#faq","mainEntity":[{"@type":"Question","name":"What is CVE-2026-111943 in Go's crypto/x509 package?","acceptedAnswer":{"@type":"Answer","text":"CVE-2026-111943 is a fix in Go's crypto/x509 package that distrusts eight compromised eMudhra intermediate certificate SPKIs. Certificate verification now rejects any chain containing one of those intermediates. The fix was backported to the Go 1.26 and 1.27 branches, landing in versions 1.26.10 and 1.27.3. Developers tracking Go security backports can follow fixes like this one on daily.dev."}},{"@type":"Question","name":"When did Chrome, Apple, and Microsoft start blocking the compromised eMudhra certificates?","acceptedAnswer":{"@type":"Answer","text":"Chrome began blocking the eight compromised eMudhra intermediate certificates on October 17. Apple devices followed on October 19, and Microsoft on October 20. Mozilla separately blocked them through its OneCRL revocation list and updated trust settings in NSS 3.131.1. The CCADB records the certificates as revoked for 'cACompromise' on October 18 and 19. Teams auditing trust store changes across vendors can keep tabs on incidents like this via daily.dev."}}]} ```