On 20 October 2026, the Chrome and Android security teams reported that a researcher had identified weak private keys for eight eMudhra subordinate certification authorities. Google says the keys were generated with insufficient randomness. A client that still trusts one of the affected chains could accept a forged HTTPS certificate under conditions where an attacker can intercept its connection. The incident concerns certificate-based authentication, not a break in TLS encryption, as Cloudflare's response explains.
Quick answer. Check the actual trust store and certificate verifier used by each browser, API client, proxy, container and mobile application. Chrome and Firefox distributed blocks for their standard configurations, but those browser fixes do not establish that a custom or bundled application trust store changed. eMudhra says the affected intermediates issued no end-entity certificates, while Google says no TLS certificates under the six TLS intermediates were logged before its block. Treat those as important limits on observed impact, not a reason to skip validation of non-browser connections.
This guide is for the infrastructure, application and security owners who need to decide what to update and what evidence would show the protection is active. The sources cited here do not establish successful exploitation in the wild.
What happened, and what is still uncertain
The distinction between a root, an intermediate and a leaf certificate matters here. A trusted root delegates issuance to intermediates. An attacker who can use a compromised intermediate private key can create a leaf certificate that appears to chain to that authority. Whether a client accepts it depends on that client's trust store, revocation and distrust mechanisms, Certificate Transparency policy, and the connection being intercepted.
Date | Primary-source observation | Practical meaning |
|---|---|---|
17 October 2026 | Google says the Chrome Root Program received the report at 18:05 UTC and landed a CRLSet block by 19:45 UTC. | Standard Chrome clients received a key-based block without a browser restart. |
17 October 2026 | Mozilla says it received the report at 20:06 UTC and completed OneCRL distribution to standard Firefox configurations by 22:59 UTC. | Firefox used a separate rapid revocation channel. |
20 October 2026 | Mozilla released Firefox 158.0.1 and ESR 115.43.1 and 153.5.1 for configurations that might not have received OneCRL, and planned an NSS trust-store change. | A browser version check and an NSS library check answer different questions. |
21 October 2026 | Mozilla released Firefox for Android 158.0.2 after finding that some clients did not apply bundled OneCRL changes immediately after startup. | Check the Android app version as well as the OneCRL delivery path. |
20 October 2026 | Google announced removal of emSign ECC Root CA - G3 from the Chrome Root Store, expected for 27 October. | Legitimate certificates under that root may need migration even if no compromised intermediate issued them. Recheck the rollout status before acting on a date. |
20 October 2026 update | eMudhra said none of the eight intermediates issued end-entity certificates. Its statement was updated through 22 October, with the root-cause investigation still open. | Do not describe eMudhra's preliminary explanation as a final forensic finding. |
22 October 2026 | eMudhra announced it would withdraw from the global SSL/TLS certificate business. It said its G1 RSA roots would keep serving customers during the transition and that affected customers would be contacted about replacement certificates from partners at no cost. | Inventory other eMudhra-issued public TLS certificates and plan with the issuer; the announcement gives no universal replacement deadline. |
Google says no TLS certificates chaining to the six affected TLS intermediates were logged in Certificate Transparency before Chrome's block. CT enforcement is a meaningful defense for public web certificates in clients that require it. That observation does not prove that every private application, old client or custom verifier enforced CT, and it is not evidence that a specific organization's traffic was intercepted.
The response has three distinct workstreams. Distrust the affected issuance path wherever a client could accept it. Plan migration of legitimate certificates under the root Google said it would remove wherever a service depends on that chain. Inventory other eMudhra-issued public TLS certificates for the company's announced business transition. Conflating these tracks can lead a team to declare the incident closed after patching browsers while leaving an outbound API client unchanged, or to replace a certificate without checking its clients' verifier behavior. eMudhra did not give a universal replacement deadline in its 22 October announcement.
Which systems need a separate check?
Cloudflare's developer guidance makes the core point: an API SDK may delegate TLS verification to a runtime, HTTP library, operating system or custom bundle. Changing the SDK's version alone may leave the actual trust decision untouched. The same service can also have different trust paths for inbound and outbound TLS.
Figure 1: Trust sources and activation checks for enterprise TLS clients. Source: Cloudflare, eMudhra CA response, Mozilla, Firefox and NSS response and Google, Chrome Root Store response.
Browser and managed endpoint fleet
Confirm whether your browser fleet receives Chrome CRLSets or Firefox OneCRL and whether device policy, network controls or an unusually old browser version changes that path. Google's announcement says Chrome blocked the affected intermediate public keys by SPKI. Mozilla says OneCRL protection reached standard Firefox configurations and published fixed Firefox releases for a minority with custom settings. Its 21 October update also says Firefox for Android 158.0.2 fixed clients that did not apply bundled OneCRL changes immediately after startup. Validate the fleet's actual managed configuration and Android app versions rather than extrapolating from one patched workstation.
Server workloads, base images and language runtimes
Inventory outbound clients that make HTTPS calls to payment processors, identity providers, SaaS integrations and internal APIs. Record the runtime and image digest, the trust source it loads at process start, and the reload or redeployment needed to activate an update. A newly patched host image does not change a long-running container whose certificate bundle is baked into an older image. Neither does a patched browser say anything about a service written in Java or Go.
Proxies, service meshes and TLS inspection
Map where TLS is terminated and re-established. A proxy that verifies an origin certificate has its own trust decision; the application behind it may never see the origin's chain. Conversely, an application that bypasses the proxy may use its own library. Include outbound gateways, cloud workload proxies, service meshes, API gateways and mobile traffic inspection where they are in scope.
Custom bundles and mutual TLS
Custom trust bundles deserve special attention because they can preserve an issuer after the operating system removes it. Keep separate inventories for server authentication and client-certificate authentication. In NIST SP 800-52 Rev. 2, section 3.5.2, NIST advises a minimum necessary set of client-authentication trust anchors for federal TLS servers. That principle is a useful review question for private B2B APIs too: which issuers must this service accept, and why?
A response plan that produces evidence
Today: bound the exposure and preserve the current state
Assign an owner to each critical TLS path. Collect the hostname, workload, image or build, TLS termination point, verifier library, trust bundle and certificate chain presented or accepted.
Check vendor and platform notices for the exact software in use. Apply documented updates to browsers, runtimes, containers and gateways. Record their publication date and the deployed build or digest.
Identify any service certificate chaining to emSign ECC Root CA - G3. Plan replacement under a currently trusted hierarchy and test its full chain from real client environments. Google's stated 27 October Chrome rollout was a future plan when this article was researched, so confirm its current status before setting a migration deadline.
Preserve relevant logs and configuration snapshots if there is an unexplained certificate change or TLS interception signal. Do not treat a blocked handshake as proof of a breach.
This week: test what the applications really accept
A useful validation is a controlled negative test against a staging or authorized test endpoint: present a certificate chain that policy says must be rejected and verify that the actual application process fails closed. Use a safe test CA and assets owned for the assessment. Record the error at the verifier, not just a browser warning. Also test an approved chain so that the fix does not merely break all connections.
For a containerized workload, verify the rebuilt image is deployed and the running process uses the updated bundle. For an API gateway, test the inbound and outbound legs separately. For mutual TLS, test both the server's validation of a client certificate and the client's validation of the server. If certificate errors appear after a change, do not disable verification to restore availability; investigate the chain and policy instead, as Cloudflare advises.
This quarter: make future distrust faster
Build a certificate and trust-source inventory that distinguishes public WebPKI, private enterprise PKI, partner client CAs and pinned or bundled roots. Give each trust source an update owner, a deployment path and a test. Rehearse the sequence from a root-program notice to a fleet change, a negative test and an auditable closeout. A pentest can then sample whether the claimed policy holds at real application boundaries rather than relying on documentation alone.
What to put in a penetration-test scope
A generic external network test may see the website's presented certificate but miss outbound API clients and private mTLS listeners. A web application and API assessment can include authenticated requests across roles and certificate-validation behavior at relevant integrations. A cloud penetration test can trace gateway, workload and trust-bundle configuration through deployed infrastructure. Use an external network assessment for internet-facing TLS termination and management surfaces.
Give the testers an approved asset list, a staging certificate authority, representative clients, a diagram of termination points and a rule that forbids disruptive tests on production partner connections. Ask for evidence of both rejection and acceptance paths, plus a retest after changes. Stingrai's human-led engagements assign two named testers from a CREST-accredited firm, post confirmed findings in the client portal as they are found, and include retesting. The exact scope is quoted through Get a Quote.
A penetration test can show whether sampled trust boundaries behave as specified. It cannot prove that no unknown client anywhere in an enterprise still trusts a weak CA. That broader claim needs asset inventory and platform deployment evidence, which the test can sample and challenge.
Frequently Asked Questions
Were the eight eMudhra intermediates used to issue customer certificates?
eMudhra said in its 20 October 2026 update that none of the eight affected intermediates issued end-entity certificates. Its later updates left the investigation open. Google's separate CT observation covers the six TLS intermediates before Chrome's block.
Are Chrome and Firefox users protected without updating the browser?
Google says Chrome's CRLSet block took effect without a browser update or restart. Mozilla says OneCRL reached standard Firefox configurations without an update or restart, but it also shipped releases for clients that might not have received that channel. Its 21 October update says Firefox for Android 158.0.2 fixed a startup delay in applying bundled OneCRL changes for some clients. Check managed settings and the Android app version before assuming coverage.
Does a passing browser check prove our APIs are protected?
No. An API client may use a different runtime, operating-system trust store or custom certificate bundle. Test the actual client and the TLS path it uses, including proxies and containers.
Should we replace every eMudhra-issued certificate?
No blanket immediate replacement follows from the sources. Identify certificates that chain to the specific emSign ECC Root CA - G3 being removed from the Chrome Root Store. eMudhra's 22 October announcement also says it will leave the global SSL/TLS business and contact affected customers about partner-issued replacements at no cost during its transition. Inventory other eMudhra-issued public TLS certificates and follow issuer and browser-program guidance; the announcement gives no universal replacement date.
Can a penetration test certify that the trust incident is resolved?
A penetration test can verify sampled certificate acceptance, rejection and boundary behavior. Closure also depends on complete asset inventory, updates, redeployments and owner sign-off for paths outside the tested sample.
Related reading
References
Google Chrome and Android Security Teams, eMudhra intermediate CA response, 20 October 2026.
Mozilla Firefox Security Team, eMudhra intermediate response, 20 October 2026.
eMudhra, certificate security incident statement, updated 22 October 2026.
eMudhra, withdrawal from global SSL/TLS certificate business, 22 October 2026.
Cloudflare, eMudhra certificate compromise response, 20 October 2026.
NIST, SP 800-52 Rev. 2, Guidelines for TLS Implementations, section 3.5.2.
Talk to Stingrai
Stingrai can scope a human-led assessment of the web, API, network and cloud trust boundaries that matter to your environment. Get a Quote or book a free discovery call to define the assets, test certificates and evidence you need.
