[RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate"
rob.mckenna at oracle.com
Wed Jan 9 16:09:15 UTC 2019
The parameter can be null, but if you look at the spec for getDomainName
it details the behaviour when the result is created with a null value.
I would rather avoid changing the spec at this point so I plan to stick
with this approach. (I'll switch the "".equals for isEmpty - thanks for
On 09/01/19 12:33, vyom tewari wrote:
> Hi Rob,
> Thanks for fixing this issue, please use hostname.isEmpty(), instead of
> "".equal(hostname). I have a question to you, why we are converting null to
> empty string("") in LdapDnsProvider ?.
> If you see the java doc it tells that domainname can be null
> * Construct an LdapDnsProviderResult consisting of a resolved domain
> * and the ldap server endpoints that serve the domain.
> * @param domainName the resolved domain name; can be null.
> My personal suggestion is not to replace null to empty string("") in
> "LdapDnsProviderResult" either throw some exception or just pass whatever
> you got in LdapDnsProviderResult constructor.
> On 08/01/19 10:33 PM, Rob McKenna wrote:
> > Hi folks,
> > I'd like to fix this test failure caused by 8160768.
> > The problem is that the LdapDnsProviderResult sets the hostname to the
> > empty String and gets passed to StartTlsResponseImpl.verify.
> > Unfortunately StartTlsResponseImpl.verify only expects null values.
> > Since null and the empty String are functionally equivalent I've added a
> > check to StartTlsResponseImpl.verify to take the empty String into
> > account.
> > http://cr.openjdk.java.net/~robm/8214440/webrev.01/
> > This was caught by an existing test which I managed to miss in my
> > testing incantation.
> > -Rob
More information about the core-libs-dev