Restricting JSSE TrustManager acceptance to specific issuers without a custom TrustManager

Short answer

Yes. The supported approach is a per-connection SSLContext backed by a dedicated trust store that contains only your internal CA (plus any intermediates it needs). This changes which anchors the default PKIX TrustManager trusts for your connections, without touching the JVM-wide cacerts file and without writing a custom X509TrustManager. Hostname verification stacks on top via SSLParameters.setEndpointIdentificationAlgorithm("HTTPS"), so both constraints are enforced by standard JSSE code.

Why this matches your constraint

Your understanding is correct: the default TrustManager has no issuer, domain, or policy boundary — it accepts any chain terminating at a configured anchor. But the set of anchors is a per-TrustManagerFactory input, not a JVM-global. Other components keep using the default context built from cacerts; your client uses its own context built from a store containing only the internal CA. The practical effect is identical to an issuer allowlist, because only chains rooted at that CA can validate.

Setup (Java 17)

KeyStore ts = KeyStore.getInstance("PKCS12");
try (InputStream in = Files.newInputStream(Path.of("internal-ca-only.p12"))) {
    ts.load(in, storePassword);
}
TrustManagerFactory tmf =
    TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); // PKIX
tmf.init(ts);
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, tmf.getTrustManagers(), new SecureRandom());

Build the dedicated store with keytool -importcert containing only the internal CA certificate. If the CA issues through intermediates that servers do not send during the handshake, include those intermediates too — otherwise path building fails even though the root is trusted.

Then, per connection, enable endpoint identification:

SSLSocket socket = (SSLSocket) ctx.getSocketFactory().createSocket(host, port);
SSLParameters params = socket.getSSLParameters();
params.setEndpointIdentificationAlgorithm("HTTPS");
socket.setSSLParameters(params);

Most higher-level clients (Apache HttpClient, OkHttp, HttpsURLConnection with a custom socket factory) accept an SSLContext/SSLSocketFactory and apply HTTPS endpoint identification themselves — verify for your specific client rather than assuming.

If a custom TrustManager becomes unavoidable

You should not need one for this scenario — no special security permission is required to construct an SSLContext from your own KeyStore. If you later need logic PKIX cannot express (e.g., pinning a specific intermediate while trusting a broader root), the minimal safe pattern is: obtain the default X509TrustManager from a TrustManagerFactory initialized with your dedicated store, wrap it, perform your extra check, then delegate checkServerTrusted to the wrapped instance. Never implement path validation yourself, and never catch-and-ignore exceptions from the delegate. Hostname verification is unaffected because it lives in the endpoint-identification layer, not the TrustManager.

Verification

• Run with -Djavax.net.debug=ssl:handshake and confirm a chain from an unrelated CA fails with a path-validation error, while the internal CA chain succeeds.
• Present a valid internal-CA certificate with a mismatched hostname and confirm rejection, proving endpoint identification is active.
• Confirm another component using the default context still validates public CAs, proving cacerts was untouched.

Caveats

The SSLContext snapshots the trust store at initialization; rotating the CA means rebuilding the context. Sharing one context across threads is safe. One open diagnostic: if your client library manages its own SSLParameters, confirm it does not overwrite your endpoint-identification setting — that is the most common silent failure in this setup.