When Certificate Trust Breaks: Why TLS Inspection Is an Enterprise Safety Net

The recent eMudhra certificate authority compromise highlights an often-overlooked security challenge: protecting enterprise applications that cannot respond to PKI incidents as quickly as modern web browsers.

Certificate trust is not absolute

The security of virtually every Internet connection depends on a fundamental assumption: when a trusted Certificate Authority (CA) issues a digital certificate, that certificate can be relied upon to authenticate the identity of a remote server.

But what happens when that trust is misplaced?

In October 2026, the discovery of compromised private keys associated with eight intermediate CA certificates issued by eMudhra sent ripples through the Internet security community. Due to a flaw in eMudhra's key-generation process, the affected ECDSA P-384 private keys had values smaller than 256, effectively providing at most 8 bits of randomness instead of the expected 384 bits. This made it possible to recover the private keys almost instantly from publicly available certificates. According to eMudhra, the problem originated from an error during a key-wrapping operation that inadvertently produced a second set of weak keys, which were subsequently used instead of the correctly generated ones.

Six affected intermediates were capable of issuing TLS certificates. An attacker possessing their private keys could create fraudulent certificates for arbitrary websites, potentially allowing them to impersonate legitimate services and intercept encrypted communications.

This was not a weakness in TLS encryption itself. Rather, it was a failure of the public key infrastructure (PKI) responsible for authenticating the parties establishing encrypted connections.

The response from major browser vendors was swift. Google Chrome deployed emergency certificate-blocking updates through CRLSets, while Mozilla Firefox used its OneCRL mechanism to reject the affected certificates. Both mechanisms can distribute emergency distrust decisions without requiring users to install a new browser version.

Importantly, Certificate Transparency provided another layer of protection. Google reported that no TLS certificates issued through the affected intermediates had been recorded in Certificate Transparency logs before Chrome's emergency block, preventing fraudulent certificates from being used successfully against CT-enforcing Chrome clients.

However, these browser protections raise a much broader question: What about all the enterprise applications that are not web browsers?

The enterprise Internet is much bigger than the browser

Modern browsers are exceptionally sophisticated TLS clients. They benefit from dedicated security engineering teams, centralized trust management, automated updates, Certificate Transparency enforcement, and specialized mechanisms for distributing emergency certificate distrust decisions.

Unfortunately, much of the software running in enterprise environments does not share these capabilities.

Consider the diversity of applications and systems that establish outbound encrypted connections in a typical large enterprise:

• Business applications built on Rust, Java, Python, Go, or other language runtimes, sometimes with their own certificate trust stores.
• Containers and microservices relying on certificate bundles included when their images were originally built.
• Legacy enterprise applications that require extensive testing and change-management approvals before being updated.
• IoT devices, industrial systems, and network appliances with limited or infrequent software update capabilities.
• Background services and automated workloads that communicate with external APIs without any browser involvement.

Many of these clients rely on operating system or application-specific trust stores that may be updated infrequently. Others do not consistently check certificate revocation information or enforce Certificate Transparency requirements.

This creates an uncomfortable security asymmetry.

A browser vendor can rapidly distribute a decision to distrust a compromised CA to millions of users. An enterprise security team, meanwhile, may need to identify hundreds of affected applications, determine which cryptographic libraries and trust stores they use, obtain updated packages, rebuild container images, validate application compatibility, and schedule deployments.

During this process, applications that continue to trust the affected CA may remain vulnerable to fraudulent certificates.

The eMudhra incident demonstrates that the speed at which an organization can respond to compromised certificate trust is itself a critical security capability.

TLS inspection: More than visibility into encrypted threats

TLS inspection is frequently discussed in the context of detecting malware, preventing data exfiltration, and applying security policies to encrypted traffic.

Those are important capabilities. But TLS inspection also provides another security benefit that receives considerably less attention: centralized enforcement of cryptographic standards and certificate trust decisions.

When an application connects directly to an HTTPS server, it is responsible for validating the server's certificate. That validation depends on the application's cryptographic libraries, trusted CA certificates, revocation mechanisms, and local configuration.

With TLS inspection, the trust relationship changes.

Instead of establishing a single end-to-end TLS connection, the inspecting security service establishes two independently authenticated TLS connections:

1. Between the enterprise application and the security service. The application authenticates the inspecting proxy using a certificate issued by a CA trusted by the enterprise.
2. Between the security service and the destination server. The security service independently validates the destination's certificate against its own managed trust policy before allowing the connection.

The enterprise application no longer needs to rely exclusively on its potentially outdated certificate trust store to determine whether the remote server is trustworthy. That decision can be enforced by a centrally managed security infrastructure.

Consider an application whose certificate trust store has not yet been updated following the eMudhra incident. If it establishes a direct connection to a malicious server presenting a forged certificate signed by one of the compromised intermediates, the application might accept that certificate as valid.

Now consider the same application connecting through a TLS-inspecting security service that has already distrusted the compromised CA. The security service rejects the fraudulent certificate and blocks the connection, even though the application itself might have accepted it.

The application's outdated trust configuration is no longer the only line of defense.

How Zscaler Internet Access helps close the gap

Zscaler Internet Access^TM (ZIA^TM) delivers TLS inspection through a globally distributed cloud security infrastructure, enabling organizations to apply consistent security policies to encrypted Internet traffic without depending entirely on security controls within individual applications.

Following the discovery of the eMudhra incident, Zscaler updated certificate trust stores across its global proxy infrastructure to reject certificates associated with the compromised CAs.

For customers using ZIA TLS inspection, with the Untrusted Server Certificates policy configured to Block, this provides protection against attempts to establish connections using certificates issued through those compromised keys.

The protection is particularly valuable for organizations with complex application environments.

An enterprise does not need to wait until every application has received an updated trust bundle before benefiting from the centrally enforced distrust decision. Applications whose traffic is inspected by ZIA can inherit that protection, even when their local certificate validation configurations have not yet been updated.

Importantly, the benefit is not limited to this specific incident.

Certificate authorities can be compromised, private keys can be exposed, issuance processes can fail, and vulnerabilities in PKI implementations can be discovered. Responding to these events requires organizations to update their trust decisions quickly.

A centrally managed inspection infrastructure provides an additional point at which those decisions can be enforced. Once the service has incorporated the necessary certificate distrust information, that protection can extend across inspected applications without requiring individual updates to each client.

This does not eliminate the need for incident response. It changes the scale of the remediation challenge, allowing security teams to reduce immediate exposure while they coordinate the more complex process of updating their application estates.

Making TLS inspection an effective enterprise security control

Realizing these benefits requires more than simply routing traffic through a cloud security service.

First, organizations should aim for comprehensive TLS inspection coverage across their enterprise application environments, not just employee web browsing. Modern enterprises generate substantial volumes of encrypted traffic through background services, API clients, automated workloads, and applications running outside traditional browsers. These connections are just as dependent on PKI trust as interactive browsing sessions.

Second, certificate validation policies must be configured to enforce meaningful security decisions. In ZIA, configuring the handling of untrusted server certificates to Block ensures that certificate validation failures result in connections being rejected rather than permitted.

Third, organizations must ensure that applications trust the certificates used by their enterprise TLS inspection infrastructure.

While browsers typically use operating-system-managed trust stores, many enterprise applications maintain their own. Java runtimes, application frameworks, containerized workloads, and embedded software may therefore require additional configuration to trust the enterprise's inspection CA. This is a particularly important deployment consideration. Establishing consistent trust in the inspecting service enables applications to benefit from centrally managed certificate validation and other security controls.

Finally, TLS inspection should complement rather than replace application and operating system updates.

Organizations should continue to remove compromised trust anchors, update cryptographic libraries, and remediate vulnerable applications. Centrally managed TLS inspection is not a substitute for maintaining healthy PKI configurations throughout the enterprise.

Instead, it provides a valuable security safety net, reducing the urgency of having to update every affected client simultaneously and giving overstretched security teams additional time to deploy durable fixes.

Security requires the ability to change trust quickly

The eMudhra incident is an important reminder that trust in the public PKI ecosystem is neither static nor infallible.

Even well-established certificate authorities can experience cryptographic failures with consequences far beyond their own infrastructure.

Modern web browsers have developed sophisticated mechanisms to respond to such incidents rapidly. Unfortunately, the broader enterprise application ecosystem remains much more fragmented, with inconsistent certificate validation practices, disparate trust stores, and widely varying update capabilities.

For CISOs and security architects, this raises an important strategic question: How quickly can your organization change whom its applications trust?

If the answer depends on identifying, rebuilding, testing, and updating every affected application individually, a CA compromise can quickly become a major operational challenge.

TLS inspection offers an additional layer of resilience.

By centralizing certificate validation and enforcing updated trust decisions across encrypted connections, organizations can reduce their exposure to compromised certificate authorities while continuing the necessary work of updating individual systems.

The value of TLS inspection therefore extends well beyond detecting malicious content or protecting sensitive data in transit.

It is also about ensuring that when trust in the Internet's cryptographic infrastructure breaks, enterprise security does not have to wait for every application to catch up.