On 1/4/19 1:06 PM, jmontm42 wrote:
> stevewdj;2493173 Wrote:
>> You have two (2) options:
>> a) update the certificate to have the Subject match the actual DNS name
>> (For Example: CN=steve.netiq.com, O=MyTee)
>> b) In the setenv(.sh/bat) in the JAVA_OPTS section add the following
>> entry:
>> -Dcom.sun.jndi.ldap.object.disableEndpointIdentific ation=true

> You are spot on. Default edir Tree cert subject didn't match the fully
> qualified host name I was using in configupdate.
> Previsously, I would rely on entering credentials in configupdate then
> browsing for a user container to help "confirm" that my LDAP settings
> were all working. In this case I could browse successfully with the
> tool, so I was assuming all was right in the world. With infinite time
> and resources, an enhancement to the configupdate would help detect if
> that hostname doesn't match an existing cert subject in the truststore.
> The only evidence of failure was that schema related exception in the
> LDAP call, so there isn't a whole lot there to lead customers to a
> successful outcome, given that I don't think i've ever seen anyone
> change out the edir certs for ldap, and its a good habit to use fqdn's,
> so I think this might come up more often that not.
> Anyhow, thanks for two great options to fix it!
> --Jim
> <insert ASCII Thumbs Up here>
> Greetings Jim,

There should have been an error in the osp log similar to
"java.security.cert.CertificateException: No name matching error"

I do not know if you still have your osp logs from when the problem was
seen with OSP logging enabled.

Steven Williams
Principal Enterprise Architect
Micro Focus