WebLogic 12c：T3S协议下Foreign JNDI Provider双向认证配置失败求助

It sounds like you’ve covered the foundational steps for switching to T3S with mutual authentication, but those subtle SSL configuration gotchas are easy to miss. Let’s walk through the most likely culprits and how to debug them:

1. First, Enable SSL Debug Logs to Get Real Error Details #

A stuck JNDI tree load almost always means an SSL handshake failure that’s not being surfaced in standard logs. Let’s enable verbose SSL debugging to see exactly where the process breaks:

• Add this JVM argument to your local WebLogic instance’s startup script:

  -Djavax.net.debug=ssl,handshake
  

• Restart your local server and try loading the JNDI tree again. Check the local server logs (DomainHome/servers/[YourLocalServer]/logs/[YourLocalServer].log) and remote admin server logs for lines containing SSLHandshakeException, CertificateException, or unable to find valid certification path—these will point you directly to the issue.

2. Verify KeyStore/TrustStore Configuration Details #

Even if you generated and exchanged certificates, small misconfigurations here are the #1 cause of mutual auth failures:

• Check Foreign JNDI Provider Properties: Ensure your Foreign JNDI Provider has these initial context factory properties set (navigate to your provider > Configuration > General > Initial Context Factory Properties in the WebLogic Console):
  • weblogic.jndi.enableSSL=true
  • javax.net.ssl.keyStore=/full/path/to/client_keystore.jks
  • javax.net.ssl.keyStorePassword=your_client_keystore_password
  • javax.net.ssl.trustStore=/full/path/to/client_truststore.jks (or the updated cacerts file—confirm the remote server’s cert is actually in there!)
  • If your key password differs from the keystore password (common with keytool), add:
    javax.net.ssl.keyPassword=your_client_key_password
• Validate Certificates in Stores: Use keytool to double-check:
  • List client keystore entries:

    keytool -list -v -keystore client_keystore.jks
    

    Confirm your client key alias exists and has a valid certificate chain.
  • Verify remote server cert is in client truststore:

    keytool -list -v -keystore client_truststore.jks | grep "remote-server-cert-alias"
    

  • Repeat the check on the remote server: ensure the client’s cert is in its truststore.

3. Confirm Remote Server’s SSL & Mutual Auth Settings #

Your remote admin server needs to enforce two-way SSL for T3S connections:

• In the remote WebLogic Console, go to Servers > [AdminServer] > Protocols > SSL:
  • Ensure Listen Port Enabled is checked and set to your SSL port (e.g., 7002).
  • Under Advanced, set Two-Way Client Cert Behavior to Client Certs Requested and Enforced—this tells the server to require a client certificate for mutual auth.
  • Verify the Identity and Trust Locations are set to use your generated keystores/truststores (not the default demo ones!).

4. Fix T3S Address & Hostname Verification Issues #

• Double-check the Remote Address: Make sure your Foreign JNDI Provider’s Remote JNDI Name uses the correct T3S format:

  t3s://remote-server-hostname:ssl-port
  

  Avoid using IP addresses if your self-signed cert’s Common Name (CN) is a hostname—this will trigger hostname verification failures.
• Temporarily Bypass Hostname Verification (for Debugging): If your cert’s CN doesn’t match the remote hostname (common with self-signed certs), add this property to your Foreign JNDI Provider to rule out this issue:

  weblogic.security.SSL.ignoreHostnameVerification=true
  

  Note: This is not production-safe—long-term, update your cert’s CN to match the remote hostname or configure a custom hostname verifier.

5. Test T3S Connection Directly with WLST #

To isolate whether the issue is with T3S itself or the Foreign JNDI configuration, use WebLogic Scripting Tool (WLST) to test the connection:

• Run wlst.sh (or wlst.cmd on Windows) from your local WebLogic’s bin directory.
• Execute this command (replace with your remote server credentials and address):

  connect('remote-admin-username', 'remote-admin-password', 't3s://remote-server-hostname:ssl-port')
  

  If this fails, you’ll get a clear error message (e.g., "unable to authenticate" or "certificate not trusted") that’s easier to debug than a stuck JNDI tree. If it succeeds, the problem is likely in your Foreign JNDI Provider’s configuration.

6. Ensure SSL Protocol & Cipher Suite Compatibility #

Older WebLogic versions may use outdated SSL protocols that clash with your setup:

• Add this JVM argument to both your local and remote WebLogic instances to enforce a modern protocol (e.g., TLS 1.2):

  -Dweblogic.security.SSL.protocolVersion=TLSv1.2
  

• Check that the cipher suites enabled on the remote server are supported by your client. You can view and modify these in the remote SSL configuration’s Advanced tab.

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