Submitter is trying to connect to IBM Tivoli LDAP running on z/OS.
We do have IBM Tivoli on Windows but the problem doesn't reproduce with that.

The findings are that the SSL handshake works ok on both IBM and Oracle JDK.
Indicates the problem is not in the SSL setup and the
certificates are correctly set and the cipher suite negotiated successfully.
However the java class
that connects to LDAP and executes a search works only with IBM JDK. With
Oracle JDK the connection is just dropped by the server after the handshake
is made and the search is sent to the server. Here's the end of the logging:

...
*** Finished
verify_data: { 198, 161, 14, 41, 44, 37, 32, 147, 178, 121, 240, 177 }
***
Thread-0, WRITE: TLSv1 Handshake, length = 48
Thread-0, READ: TLSv1 Change Cipher Spec, length = 1
Thread-0, READ: TLSv1 Handshake, length = 48
*** Finished
verify_data: { 191, 196, 202, 114, 233, 232, 79, 196, 2, 231, 14, 81 }
***
%% Cached client session: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
Main Thread, WRITE: TLSv1 Application Data, length = 80
Thread-0, READ: TLSv1 Application Data, length = 48
Main Thread, WRITE: TLSv1 Application Data, length = 32
Main Thread, WRITE: TLSv1 Application Data, length = 144
Thread-0, received EOFException: ignored
Thread-0, called closeInternal(false)
Thread-0, SEND TLSv1 ALERT: warning, description = close_notify
Thread-0, WRITE: TLSv1 Alert, length = 32
Thread-0, called closeSocket(selfInitiated)
Nov 10, 2014 9:38:56 AM JndiSSLTest main
SEVERE: null
@ javax.naming.ServiceUnavailableException: xxx.xxx.xxx:636;
@ socket closed; remaining name 'ou=people,o=OPMOAM,C=us'
       at com.sun.jndi.ldap.Connection.readReply(Connection.java:439)
       at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:625)
       at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:543)
@ at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1965)
       at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1827)
       at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1752)
       at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java
:368)
       at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDir
Context.java:338)
       at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDir
Context.java:321)
       at
javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
       at JndiSSLTest.search(JndiSSLTest.java:45)
       at JndiSSLTest.main(JndiSSLTest.java:69)

so the server just closes the connection/socket. We also collected the
network packet traces from z/OS side but they are not showing anything that
we wouldn't know. We just see that the server sends FIN after the request is
made from client side. The client side sends ACK to which the server responds
with RST.