Hi Sean,
Alexey answered the same question for me:
I mean “com.sun.jndi.ldap.connect.timeout” property.
The positive value forces to start TLS handshake and wait for it completion
during the connectTimeout milliseconds:
Connection.java
if (connectTimeout > 0) {
int socketTimeout = sslSocket.getSoTimeout();
sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value
sslSocket.startHandshake();
sslSocket.setSoTimeout(socketTimeout);
}
Without this property handshake is started later asynchronously.
As result
certs = ssock.getSession().getPeerCertificates();
in the LdapClient.java could return SSLPeerUnverifiedException().
This exception will be wrapped to NamingException and thrown to application.
This is not usually happens but I saw it on the slow connection
The full context of LDAP Connection code that initiates the SSL
handshake could be viewed here:
https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345
-- Aleksei
On 06/07/2020 21:11, Sean Mullan wrote:
Hi Alexey,
This may have been discussed already, but can you explain why the
"com.sun.jndi.ldap.connect.timeout" property needs to be set in order
to use this feature? That property is mostly used in tests to avoid
long socket timeouts, etc.
Why does that need to be set? What problem are you trying to solve?
--Sean
On 7/3/20 11:31 AM, Alexey Bakhtin wrote:
I would suggest removing it. At least for the SASL GSS-API mech, it
seems the GSSContext object will not be leaked and no one has a
chance to call setChannelBinding again on it.
There is no spec saying setChannelBinding() can only be called once,
so I'd rather we don't enforce that, although you might say there is
no need to call it twice.
OK.
GSSContextImpl class is removed from patch.
Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11
Thank you
Alexey