Custom certificate authorities are common in private APIs, internal service meshes, and enterprise TLS inspection. CVE-2026-111943 forces teams to look at those trust designs because a locally trusted CA can still lead to a chain containing one of the eight compromised eMudhra intermediates.
The flaw is in Go's crypto/x509 verification code. The Go vulnerability database lists affected versions before go1.26.10 and from go1.27.0-0 before go1.27.3. Mozilla reported that private keys for eight eMudhra intermediates were compromised and could be used for fraudulent HTTPS certificates. The Go fix adds a denylist based on SHA-256 hashes of certificate Subject Public Key Info values and filters out chains that contain a blocked certificate.
A trusted root is not the final answer
Certificate verification answers a chain-building question and a policy question. The chain must reach a root that the verifier trusts. The policy must also decide whether each link is acceptable. A custom root can satisfy the first part while doing nothing about a compromised intermediate later in the path.
The Go patch applies its negative decision after chain construction. A chain can be valid in the sense that signatures resolve to a configured root, while still being unacceptable because an intermediate key is on the blocklist. Applications and tests should treat CertificateInvalidError with NoValidChains as the expected result when such a chain is presented.
This distinction affects incident handling. Adding another root, changing the operating system trust store, or copying a CA file into a container does not remove the Go behavior introduced by the patch. A workaround that disables verification would weaken the application and should not be used to make a failing connection appear healthy.
Where enterprise PKI breaks
Organizations often insert an interception proxy between a Go application and an external service. The proxy generates a leaf certificate and signs it with an internal intermediate. If that intermediate or an upstream link is tied to a compromised key, a patched Go client will reject the chain. The application owner may see a general handshake failure while the network team sees a valid proxy certificate.
The same pattern can occur in private service meshes when a trust bundle is out of date or a synthetic chain is assembled by hand. Before changing application code, capture the presented chain and compare each SPKI hash with the Go denylist. If the chain uses a blocked key, replace the intermediate and distribute the new trust path. A new root alone may not be enough if the old intermediate remains in the served chain.
Third-party TLS inspection needs an explicit compatibility test. Deploy the patched binary against the same proxy configuration used in production, then verify that ordinary internal endpoints still validate. If a blocked certificate appears, obtain a clean replacement chain from the inspection platform's owner. Record the replacement date and the new SPKI values so that another team does not reintroduce the old chain from a cached configuration.
Do not confuse trust stores
Go may use the host trust store on some platforms and a custom pool supplied by the application on others. The review should identify which behavior each binary uses. It should also determine whether an embedded CA bundle, container image, operating-system package, or application configuration supplies roots. These are different sources of trust, and updating one does not imply the others changed.
The patched toolchain is still the necessary control. A binary built with an affected Go release can continue to accept a blocked chain even if the surrounding system trust store is current. A binary built with go1.26.10, go1.27.3, or a later patched release carries the new chain filter in its standard library.
Inventory and rollout
Locate Go binaries that use private roots for authentication or proxy traffic. Rebuild them with a patched supported toolchain and test against controlled certificate chains. Do not use live banking, identity, or customer endpoints to exercise the rejection path. A test harness with generated certificates is enough to prove the behavior.
For internet-facing assets, a ZoomEye search for app="Go" returned 260,278 fingerprint matches at the recorded time. Those assets are not known to be vulnerable or to use a custom root. The count is useful only as a broad starting point for ownership discovery.
The decision to record
The PKI owner should state whether any active proxy or internal service presents a chain with one of the eight blocked intermediates. The application owner should state which Go build is deployed and whether testing reached the expected rejection path. Security should confirm that no team bypassed verification to restore connectivity. These three records close the loop between CA replacement, code patching, and operational trust.