The disclosure site author documents what they describe as a compromise of an eMudhra intermediate CA, publishing under the 'we-have-a-problem.com' convention that security researchers historically use when they want a CA to notice outside PR channels. The technical detail and chosen disclosure pattern mirror prior serious incidents like the Symantec distrust chain.
Argues that because eMudhra's roots are embedded in Mozilla, Microsoft, Apple, and Chrome root stores, a compromised intermediate can mint valid certificates for any domain on the public internet. When an intermediate key escapes its HSM, every TLS guarantee degrades to 'as trustworthy as whoever has the key,' enabling MITM attacks on banking, Google properties, or internal corporate VPNs with the browser lock still showing.
Notes that a dense PKI story reaching 178 points with 76 comments and no vendor comms attached indicates the technical community finds the evidence credible on its own merits. Prior disclosures under similar 'shaming URL' conventions have historically escalated quickly once Mozilla's dev-security-policy list and CA/B Forum incident bugzilla pick them up.
A public disclosure site at emudhra.we-have-a-problem.com went live over the weekend, documenting what the author describes as a compromise of an intermediate CA operated by eMudhra, one of the larger India-headquartered commercial certificate authorities and a WebTrust-audited member of the CA/Browser Forum. The post climbed to 178 points on Hacker News, which — for a dense PKI story with no vendor press release attached — is the kind of signal that usually means the technical crowd finds the evidence credible.
The domain name is itself the story: `we-have-a-problem.com` is the pattern security researchers have used for years when they want a CA to notice a disclosure without going through the vendor's PR filter. Prior incidents published under similar "shaming URL" conventions — most notably the chain of disclosures that eventually led to the Symantec distrust in 2018 — tend to escalate quickly once Mozilla's `dev-security-policy` list and the CA/B Forum incident bugzilla pick them up.
eMudhra's roots are embedded in the Mozilla, Microsoft, Apple, and Chrome Root Store programs. That means an intermediate chained to one of those roots can issue a TLS certificate for *any* domain on the public internet, and every stock browser on earth will treat it as valid. There is no higher-privilege key material on the web PKI.
CA compromise is one of the few remaining single points of failure in the modern web stack. When an intermediate CA key leaves the HSM it's supposed to live inside, every TLS guarantee in the browser's lock icon degrades to "as trustworthy as whoever has the key." An attacker holding a usable intermediate can mint a cert for `login.yourbank.com`, `*.google.com`, or your internal `vpn.corp.example` and present it to a victim whose traffic they can route — on a hostile Wi-Fi, inside a nation-state's border router, or via a compromised ISP. The browser will show the lock. Pinning helps for the handful of properties that bother; HSTS alone does not.
The historical pattern is well-established and worth re-reading before you dismiss this as yet another CA story. DigiNotar (2011) was fully distrusted within two weeks of the disclosure after Iranian-origin misissuance was proven; the company filed for bankruptcy inside a month. Symantec (2017–2018) — a vastly larger CA — was given a staged distrust timeline because the volume of legitimate certificates in the wild made a hard cutoff impossible, but it still ended with Symantec selling the entire PKI business to DigiCert. TrustCor (2022) was distrusted after reporting tied the operator to US surveillance contractors, with no demonstrated misissuance at all — the appearance of operational risk was enough.
The browser root programs have been visibly less patient with each successive incident. Mozilla's current policy explicitly contemplates "removing trust" as a routine response to control failures, not a last resort. Chrome's Root Store, which went live as a browser-managed trust store independent of the OS in 2023, has already demonstrated it will act unilaterally. If the eMudhra disclosure holds up — and the disclosing researcher is pointing at a specific key, not just hand-waving — the realistic distrust horizon is weeks.
The second-order problem is the long tail. eMudhra is a significant issuer in the Indian government and enterprise space, including for digital signature certificates used in GST filings, MCA submissions, and a non-trivial amount of B2B TLS inside India. A distrust event there isn't a Western-browser abstraction — it's a bunch of real production endpoints suddenly throwing cert errors in Chrome and Edge on Monday morning.
First, run the audit. On any machine you care about, dump your TLS chain and look for eMudhra in the issuer path: `openssl s_client -showcerts -connect host:443 /dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout | grep -i emudhra`. For an org-wide view, Censys and crt.sh both let you query Certificate Transparency logs by issuer; the search string `issuer:"eMudhra"` on crt.sh will give you every cert any eMudhra intermediate has ever signed that made it into CT, which is effectively all of them post-2018.
Second, check your dependency graph. If you consume APIs from Indian fintech, government, or large enterprise endpoints, there's a non-trivial chance one of them is eMudhra-chained. Node.js, Go, Python, and the JVM all ship their own CA bundles that lag behind browser root stores by months — a distrust at the Mozilla level won't automatically propagate to your `requests` client or your `http.Client`, which is simultaneously a stability win and a security problem.
Third, if you operate a service that terminates TLS and your current cert is eMudhra-chained, start the migration today. Don't wait for the distrust announcement. Reissuing from Let's Encrypt, Google Trust Services, or any other actively-trusted CA takes an afternoon; discovering on launch morning that your checkout flow is throwing `NET::ERR_CERT_AUTHORITY_INVALID` to half your users takes considerably longer to recover from.
The deeper story here isn't eMudhra specifically. It's that the web PKI continues to run on a trust model where ~50 commercial organizations hold universal signing authority, auditing is largely self-reported, and the only real backstop is Certificate Transparency — a detective control, not a preventive one. Google's push to 90-day max certificate lifetimes and the industry's slow drift toward ACME-everywhere are partial fixes: they reduce the half-life of a stolen key but don't change who holds the keys. The more interesting direction is the Chrome team's quiet work on Merkle Tree Certificates and the broader interest in short-lived, non-CA-rooted trust (SPIFFE/SPIRE inside the datacenter, WebPKI alternatives at the edge). None of it is close to shipping to end users. Until it does, every few years a CA will have a bad weekend, and the rest of us will spend Monday rotating certs.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.