Problems connecting to 389 directory server

[Darren Boss]

Here are my ldap settings:

https://pastebin.com/3XVtZLA2

The ldap-server.crt contains the CA (not in use in this particular
configuration) while the ldap-server.truststore file contains the ldap
server's cert and the CA created using keytool. If I use this exact
truststore using SSLPoke, no issues. I'm going to reconfigure it to using
trustCertificates again because of your comments but I have had that
configuration in place before and it still failed to connect to this
particular LDAP server. I would like to see if both configurations work now
that the JRE has the CA cert.

I'm running containerized Shibboleth IdPs running under Kubernetes and
until I ran into issue with this particular ldap server, the container that
was running our production IdP connecting to our OpenLDAP server using Go
Daddy certs and this installation using a private CA and running 389
Directory Server were identical except for Shibboleth configuration.

Now that I've got a working IdP with this newly built Docker image I'm not
hitting this quite as hard as I was over the last week but I'm still very
interested in figuring out what the heck is going on here. I'd much prefer
to use the same Docker image for both deployments and remove the complexity
from the build process that adds the CA cert to the JVM CA bundle.

I'd also like to try building the images using the Oracle JVM instead of
the OpenJDK/Zulu and see if there are differences in behaviour.

On Mon, Dec 4, 2017 at 3:37 PM Daniel Fisher <dfisher at vt.edu> wrote:

> On Mon, Dec 4, 2017 at 3:03 PM, Darren Boss <darren.boss at computecanada.ca>
> wrote:
>
>> I ended up getting it to work but I did have to import the CA of the cert
>> in der format into the JRE keystore in order to get it to connect and I'm
>> NOT using jvmTrust in my ldap.properties file. This seems to contradict
>> what I've read in the documentation and on the mailing list.
>>
>
> That configuration won't be supported in a future release.
>
> Note that ldap.properties will leverage idp.authn.LDAP.trustCertificates
> for the resolver if it's defined.
> However the idp.authn.LDAP.trustStore property is not propagated to the
> resolver, so if you're using it you'll need to deal with resolver trust
> configuration separately.
> I'm not clear on how you've got things configured, but I would recommend
> you try setting idp.authn.LDAP.trustCertificates to the file location of
> the PEM encoded ca cert.
>
> Logging the org.ldaptive package at DEBUG should also provide some insight.
>
> --Daniel Fisher
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net

-- 

*Darren Boss*
*Senior Programmer/Analyst*
*Programmeur-analyste principal*
*darren.boss at computecanada.ca <darren.boss at computecanada.ca>*
*(o) 416.228.1234 x *230
*(c) 919.525.0083*

155 University Ave, Suite 302 Toronto, ON M5H 3B7
www.computecanada.ca / www.calculcanada.ca
@ComputeCanada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171205/a3ed4cf8/attachment-0001.html>