If a business website starts failing certificate checks after the October 2026 eMudhra trust changes, investigate both the certificate chain the service presents and the trust decisions made by the connecting software. Replace an affected chain at the service and keep client protections current. Adding a local trust exception just to reopen the page can undermine the reason the certificate was distrusted.
For an IT manager handling access complaints, the immediate task is to locate the failed validation: the browser, an application, or an inspecting web gateway. A certificate chain links the site’s certificate through issuing authorities to a trusted root. The same hostname can produce different results along different connection paths.
What changed this week
Microsoft’s October 26 account, updated October 27, describes eight compromised eMudhra intermediate certificate-authority keys: six for Transport Layer Security (TLS), which protects HTTPS connections, and two for code signing. Such keys could support website impersonation or misleading software signatures. Microsoft identifies this as an eMudhra hierarchy issue, not a compromise of Microsoft systems.
The Microsoft Trusted Root Program announcement separates three actions:
- October 20: Windows disallowed-list updates blocked the identified compromised keys; Edge/WebView2 component updates blocked the affected TLS keys.
- October 26: Microsoft removed six eMudhra G3 roots and an AAA Certificate Services cross-sign from the Windows trust list.
- October 27: the same seven certificates were removed from the Edge trust list.
Blocking compromised intermediate keys and removing default trust in root certificates have different scopes. Match the service’s actual chain against Microsoft’s published identifiers. A supplier’s brand name alone is too broad a basis for deciding that every certificate it issued is affected.
One portal, three places to investigate
Consider this hypothetical support case. Employees use a supplier portal through an approved HTTPS-inspection gateway. The gateway connects to the supplier, while the managed browser connects to the gateway. Network Box USA’s SSL proxying architecture explanation describes these separate connections; the older paper is an architectural reference, not current configuration guidance.
The portal stops loading after a trust update. An employee says it still opens on another device. That comparison is a useful clue, but sending staff to the other device would leave the underlying trust question unresolved. The support team needs to establish which connection was rejected.
| What the investigation establishes | What to do next |
|---|---|
| The gateway rejects the supplier’s upstream chain, and the chain matches a removed hierarchy. | Ask the supplier to replace the affected certificate or provide an appropriate alternative trusted chain. Keep the gateway’s validation enabled while the supplier repairs its endpoint. |
| The browser reports that it does not trust the organization’s inspection certificate. | Investigate the managed device’s inspection-certificate deployment and policy. Do not attribute that separate failure to the supplier without upstream evidence. |
| On a route without HTTPS inspection, an older device accepts the affected supplier chain while an updated device rejects it. | Compare their validation software, trust stores and update delivery. Acceptance by the older device may reflect missing protection; do not use it as the reference configuration. |
These are illustrative findings, not diagnoses that follow from the screen message alone. Record the hostname, exact error, application, time, traffic path and observed certificate chain. Share public certificate identifiers where needed; private keys do not belong in support tickets. Use authorized diagnostic checks without submitting credentials or sensitive data to a connection whose trust is unresolved.
Give the gateway operator a specific investigation
Network Box USA’s Managed Secure Web Gateway service includes HTTPS inspection, URL and content policy, malware defense, and reporting. Within the agreed inspection path, that managed work provides a place to investigate the policy decision, review available connection evidence, and coordinate a change with the application owner.
Ask the operator which connection failed validation, what chain it observed, and which policy or trust update explains the result. Confirm the evidence available in your deployment. The service description does not establish a specific eMudhra mitigation status or transfer responsibility for the supplier’s certificate and endpoint trust stores to Network Box USA.
Restore access while retaining the trust protections
Microsoft recommends replacing certificates that depend on the removed chains and keeping Windows trust and Edge component updates flowing. Its local-trust warning matters particularly when software does not reliably consult revocation information or the disallowed list. A compatibility exception requires a security assessment of that software’s behavior, not simply a user’s report that the page now opens.
For disconnected Windows systems, the endpoint team should verify the managed delivery of both trusted and disallowed certificate lists. Microsoft documents a distribution method for disconnected environments; follow the procedure appropriate to the deployed systems. Review other applications’ trust mechanisms with their owners rather than assuming one Windows update controls every validator.
In the hypothetical supplier case, a useful acceptance test is the normal business transaction through the approved gateway after the supplier deploys an acceptable chain, with the intended trust protections still active. Record the chain observed and the client and gateway paths tested. Our certificate deployment verification guide covers checking that a replacement is actually served.
If your team needs help establishing where managed HTTPS inspection fits in that investigation, contact our team with the affected application, error and connection path.