Help: Our legacy Java app fails because Netskope intercepts its weird certificate pinning.

Alright, let's get this documented for the next poor soul who stumbles into this particular circle of ZTNA hell. We're in the middle of a "zero trust" migration, which in reality feels more like a "zero understanding of legacy application behavior" migration. The vendor, Netskope in this case, promised seamless traffic inspection and secure access. What they delivered was a spectacular failure for a critical, albeit ancient, internal Java application.

The app in question is a monolithic beast from the early 2010s. It uses a custom HTTP client built on top of what I can only describe as a "creative" interpretation of Apache HttpClient 4.x. The developers, in their infinite wisdom, decided to implement certificate pinning. Not via the standard trust store, but by programmatically loading a specific cert and validating the chain itself. It's the kind of thing that makes security teams nod approvingly and operations teams weep silently.

Enter Netskope's ZTNA connector. It sits in-line, performing TLS interception (or "inspection," if you prefer the marketing term). This means it terminates the TLS connection from the app, inspects the content, and then initiates a new TLS connection to the actual backend. To the app, the certificate presented is now the Netskope-issued one, not the backend's actual certificate. Our app's custom pinning logic, of course, rejects this outright. The result is a `javax.net.ssl.SSLHandshakeException` with a root cause buried in a custom `X509TrustManager` that's looking for a specific issuer DN that never arrives.

We've been given the usual checklist by the Netskope support team: "Add our CA to the global trust store," "disable certificate validation" (absolutely not), "use a different client." The first two are non-starters for compliance and security, and the third is a multi-month rewrite. The app's code is a rat's nest of deprecated libraries and proprietary classes. Here's a sanitized snippet of the offending trust manager logic:

```java
public class OurBrilliantTrustManager implements X509TrustManager {
private final X509Certificate pinnedCert;

@Override
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
// It walks the chain looking for a very specific certificate
boolean foundPinnedCert = false;
for (X509Certificate cert : chain) {
if (cert.getIssuerX500Principal().getName().equals("CN=Our-Legacy-Issuer, O=Internal, C=US")) {
foundPinnedCert = true;
break;
}
}
if (!foundPinnedCert) {
throw new CertificateException("Certificate chain does not contain the expected pinned issuer.");
}
// Then it does its own basic validation
// ... more fragile code here
}
}
```

The question for the community is this: has anyone successfully navigated this specific type of collision between a ZTNA proxy and an application with non-standard, programmatic certificate pinning? We're being told the only path is an "exception policy" that bypasses inspection for this app, which frankly defeats the entire purpose of rolling out ZTNA to this segment. Are there any configuration nuances on the Netskope side—a way to present a certificate that can somehow satisfy a pinning check, perhaps by leveraging a specific intermediate CA? Or is this simply an architectural incompatibility where the only answers are a costly refactor or a security bypass?

I'm deeply skeptical that a platform marketed as enterprise-ready has no elegant solution for a common legacy integration challenge like this. The vendor's documentation is, predictably, full of happy-path scenarios and silent on real-world entropy.

-- Cam