Let’s break down your core issue first: your legacy system runs fine on WAS, works correctly on OpenShift with the Test DB—but throws an SSL handshake failure only when switching to the PROD DB, even with identical code and JKS files. The debug log’s key red flag is Warning: no suitable certificate found - continuing without client authentication for PROD, which never appears with Test.

Here are targeted, actionable steps to diagnose and fix this:

1. Verify PROD DB’s SSL Client Authentication Rules #

Even if you compared basic DB properties, double-check if the PROD DB enforces mandatory client certificate authentication while the Test DB uses a looser policy:

• Check your PROD DB’s SSL config (e.g., PostgreSQL’s ssl_client_auth=required, Oracle’s SSL_CLIENT_AUTHENTICATION=true). If Test DB uses sslmode=prefer or skips client auth entirely, this explains why the missing valid client certificate only breaks PROD.
• The log shows Cert Authorities: <Empty> from the server, but some DBs still enforce client auth without listing allowed CAs—they just expect a certificate signed by a CA in their own truststore.

2. Confirm Your JKS File Is Actually Loaded in Production #

Setting -Djavax.net.ssl.trustStore and -Djavax.net.ssl.keyStore as environment variables doesn’t guarantee the JVM picks them up:

• In your OpenShift production pod, run ps aux to inspect JVM startup arguments. Ensure the -D parameters are present, point to the correct absolute path, and have no typos.
• Add a quick debug log line in your app to validate the loaded paths:

  System.out.println("Active KeyStore: " + System.getProperty("javax.net.ssl.keyStore"));
  System.out.println("Active TrustStore: " + System.getProperty("javax.net.ssl.trustStore"));
  

• Check file permissions: OpenShift runs pods with non-root users—make sure your JKS file has read permissions (fix with chmod 644 your.jks in your Dockerfile or build config).

3. Validate Certificate Compatibility Between JKS and PROD DB #

Even if the JKS works for Test, it might not meet PROD DB’s stricter requirements:

• List all certificates in your JKS to check their validity and algorithms:

  keytool -list -v -keystore your.jks -storepass your-keystore-password
  

  Verify the client certificate’s signature algorithm matches one of the supported types in your log (e.g., SHA256withRSA). Also confirm it hasn’t expired—expired certificates are a common production-only gotcha.
• Fetch the PROD DB’s server certificate and check if its CA exists in your truststore:

  openssl s_client -connect prod-db-host:prod-db-port < /dev/null | openssl x509 -out prod-db-cert.crt
  keytool -list -v -keystore your-truststore.jks | grep -A5 -B5 "Issuer"
  

  Coordinate with your DB admin to confirm your client certificate is present in the PROD DB’s truststore.

4. Rule Out Production Network/Proxy Interference #

Production environments often have extra network layers that alter SSL handshakes:

• Test direct SSL connectivity from your production pod to the PROD DB using openssl:

  openssl s_client -connect prod-db-host:prod-db-port -cert client-cert.pem -key client-key.pem
  

  (Extract the certificate/key from your JKS with keytool if needed.) If this fails outside your app, the issue lies with a network proxy, firewall, or SSL inspection tool intercepting connections.
• Check if a corporate SSL proxy is rewriting DB certificates—you may need to add the proxy’s root CA to your truststore instead of the DB’s.

5. Compare WAS vs. OpenShift SSL Configurations #

WAS has its own proprietary SSL management that might include hidden settings your OpenShift deployment is missing:

• In WAS, check if the global truststore/keystore included additional CA certificates that weren’t copied to your OpenShift JKS. For example, WAS might have preloaded a root CA required for the PROD DB.
• WAS often overrides default JVM SSL properties—confirm your OpenShift setup doesn’t need custom cipher suites or SSL providers that were configured in WAS.

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