如何调试Glassfish环境下Java Web应用的SSLHandshakeException？

Hey there, since you already got this working smoothly in a desktop Java app, the issue is almost certainly tied to how Glassfish manages SSL contexts and PKI configurations compared to your standalone application. Let's walk through step-by-step debugging strategies to get to the bottom of this:

1. Enable Verbose SSL Debug Logging First #

SSL handshake errors are often vague—you need to see the nitty-gritty details of what's failing. In Glassfish, you can turn on full SSL debugging by adding a JVM option:

• Open the Glassfish Admin Console → Configurations → Select your target config (e.g., server-config) → JVM Settings → JVM Options
• Add this line: -Djavax.net.debug=ssl,handshake
• Restart Glassfish and reproduce the error.

Dig into the server logs (domain/logs/server.log) for clues:

• Did the client (your web app) send the correct client certificate from your PKI?
• Is the server's root CA present in your configured truststore?
• Are there "unable to find valid certification path to requested target" messages?
• Did the key/truststore load successfully (watch for password or path errors)?

2. Stop Relying on System Properties—Use a Custom SSLContext #

In desktop apps, setting system properties like javax.net.ssl.keyStore works because it's a single JVM instance. But in Glassfish (a multi-application server), system properties are global—other apps might overwrite them, or Glassfish's own SSL config might take precedence. Instead, create a dedicated SSLContext for your API calls:

import javax.net.ssl.*;
import java.io.FileInputStream;
import java.security.KeyStore;

public class CustomSslUtils {
    public static SSLContext createCustomSslContext(String pkiPath, String pkiPassword, String trustStorePath, String trustStorePassword) throws Exception {
        // Load client keystore (your PKI)
        KeyStore keyStore = KeyStore.getInstance("PKCS12"); // Adjust to JKS if your PKI uses that format
        try (FileInputStream fis = new FileInputStream(pkiPath)) {
            keyStore.load(fis, pkiPassword.toCharArray());
        }

        // Initialize KeyManagerFactory
        KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
        kmf.init(keyStore, pkiPassword.toCharArray());

        // Load truststore
        KeyStore trustStore = KeyStore.getInstance("JKS"); // Adjust format as needed
        try (FileInputStream fis = new FileInputStream(trustStorePath)) {
            trustStore.load(fis, trustStorePassword.toCharArray());
        }

        // Initialize TrustManagerFactory
        TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        tmf.init(trustStore);

        // Build custom SSLContext
        SSLContext sslContext = SSLContext.getInstance("TLSv1.2"); // Use TLSv1.3 if your API supports it
        sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

        return sslContext;
    }
}

Then use this SSLContext when making your API call (example with HttpClient):

SSLContext sslContext = CustomSslUtils.createCustomSslContext(pkiPath, pkiPass, trustStorePath, trustStorePass);
HttpClient client = HttpClient.newBuilder()
        .sslContext(sslContext)
        .build();

// Make your API request
HttpResponse<String> response = client.send(
        HttpRequest.newBuilder()
                .uri(URI.create("your-https-api-url"))
                .GET()
                .build(),
        HttpResponse.BodyHandlers.ofString()
);

This approach isolates your PKI config to just your API calls, avoiding conflicts with Glassfish's global SSL settings.

3. Verify Glassfish Isn't Overwriting Your PKI Config #

Glassfish has its own default keystore and truststore located in domain/config/keystore.jks and domain/config/cacerts.jks. Check if these are being used instead of your custom PKI:

• Open domain/config/domain.xml and look for <ssl> elements under <network-listener> or <http-listener>. If these specify keystore or truststore attributes, they might be overriding your system properties.
• If you don't want to modify Glassfish's global config, the custom SSLContext method from step 2 is the safest way to bypass this.

4. Validate PKI File Access and Integrity #

Ensure your web app can actually access and read your PKI files:

• Use absolute paths for your PKI/truststore files (relative paths in web apps are tricky—they're relative to Glassfish's domain directory, not your app's WAR).
• If you packaged the PKI files inside your WAR (e.g., WEB-INF/resources), load them via the classloader instead of file paths:

  InputStream keyStoreStream = getClass().getResourceAsStream("/WEB-INF/resources/your-pki.p12");
  keyStore.load(keyStoreStream, pkiPassword.toCharArray());
  

• Use the keytool command to verify your files are valid:
  • Check keystore: keytool -list -keystore your-pki.p12 -storepass your-password
  • Check if server CA is in truststore: keytool -list -keystore your-truststore.jks -storepass your-password | grep "server-ca-alias"

5. Rule Out Conflicting Configurations #

• Check if your web app's web.xml has <security-constraint> elements that enforce SSL—these might be forcing use of Glassfish's default SSL setup.
• If you're using a framework like Spring, ensure it's not overriding SSL settings (e.g., RestTemplate with its own SSL config).
• Test with a minimal, isolated servlet that only makes the HTTPS API call—this will tell you if the issue is in your core logic or elsewhere in the app.

6. Check for Certificate Chain Issues #

Even if your desktop app works, Glassfish might be using a different JRE with missing intermediate certificates. Use openssl to check the server's certificate chain:

openssl s_client -connect your-api-domain:443 -showcerts

Compare the chain to what's in your truststore—make sure all intermediate CAs are present, not just the root.

内容的提问来源于stack exchange，提问作者chocalaca