Problems connecting to 389 directory server

[Darren Boss]

I've got things running in DEBUG mode now and I'm super confused why my
deployments are using the jvm truststore.

If I see this message on startup:
2017-12-06 15:34:01,962 - WARN
[net.shibboleth.idp.attribute.resolver.dc.ldap.impl.LDAPDataConnector:168]
- Data Connector 'ccLDAP': Use of default JVM trust store will be removed
in the next major version of this software; replacement is trustFile
attribute

does this mean for sure that the IdP is using the JVM trust store? I see
this message on my production and dev deployments as well but I didn't have
to add the CA to the JRE since we are using certificates already signed by
a CA that exists in the default CA bundle.

I am using
idp.authn.LDAP.sslConfig                        = certificateTrust

So why is the JVM trust store being used?

Additionally I can now see even after adding the CA to the JRE trust store
with ldaptive debugging turned on that while the authn succeeds, attribute
retrieval doesn't because it's not using ssl on attribute retrieval even
though I've got:
idp.authn.LDAP.useSSL                           = true

and the ldap server string starts with ldaps://. What the heck is going on?
I normally despise html email but here is does come in handy for
highlighting some of the things that pop out to me in the logs.

2017-12-06 15:41:55,321 - DEBUG [org.ldaptive.SearchOperation:138] -
execute request=[org.ldaptive.SearchRequest at 732416381::baseDn=<redacted>,
searchFilter=[org.ldaptive.SearchFilter at 1496570425::filter=(cn=<redacted>),
parameters={}], returnAttributes=[], searchScope=SUBTREE, timeLimit=3000,
sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
sortBehavior=UNORDERED,
searchEntryHandlers=[[org.ldaptive.handler.DnAttributeEntryHandler at -1580910376::dnAttributeName=entryDN,
addIfExists=false]], searchReferenceHandlers=null, controls=null,
followReferrals=false, intermediateResponseHandlers=null] with
connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection at 1716672035
::config=[org.ldaptive.ConnectionConfig at 86506638::ldapUrl=ldaps://<redacted>,
connectTimeout=3000, responseTimeout=3000,
sslConfig=[org.ldaptive.ssl.SslConfig at 1639958975
::credentialConfig=org.ldaptive.ssl.CredentialConfigFactory$2 at 2c7106d9,
trustManagers=null, hostnameVerifier=null, hostnameVerifierConfig=null,
enabledCipherSuites=null, enabledProtocols=null,
handshakeCompletedListeners=null], *useSSL=false*, *useStartTLS=false*,
connectionInitializer=null],
providerConnectionFactory=[org.ldaptive.provider.jndi.JndiConnectionFactory at 43648489::metadata=[ldapUrl=ldaps://<redacted>,
count=1],
environment={java.naming.ldap.factory.socket=org.ldaptive.ssl.ThreadLocalTLSSocketFactory,
com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
com.sun.jndi.ldap.read.timeout=3000},
providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig at 1552295831::operationExceptionResultCodes=[PROTOCOL_ERROR,
SERVER_DOWN], properties={},
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$ActivePassiveConnectionStrategy at 4ee3d023,
controlProcessor=org.ldaptive.provider.ControlProcessor at 3a747492,
environment=null, tracePackets=null, removeDnUrls=true,
searchIgnoreResultCodes=*[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED,
PARTIAL_RESULTS]*, sslSocketFactory=null, hostnameVerifier=null]],
providerConnection=org.ldaptive.provider.jndi.JndiConnection at 68138b78]
2017-12-06 15:41:55,325 - DEBUG [org.ldaptive.SearchOperation:168] -
execute response=[org.ldaptive.Response at 88388466
::result=[org.ldaptive.SearchResult at 4303153::entries=[], references=[]],
resultCode=SUCCESS, message=null, matchedDn=null, responseControls=null,
referralURLs=null, messageId=-1] for
request=[org.ldaptive.SearchRequest at 732416381::baseDn=<redacted>,
searchFilter=[org.ldaptive.SearchFilter at 1496570425::filter=(cn=<redacted>),
parameters={}], returnAttributes=[], searchScope=SUBTREE, timeLimit=3000,
sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
sortBehavior=UNORDERED,
searchEntryHandlers=[[org.ldaptive.handler.DnAttributeEntryHandler at -1580910376::dnAttributeName=entryDN,
addIfExists=false]], searchReferenceHandlers=null, controls=null,
followReferrals=false, intermediateResponseHandlers=null] with
connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection at 1716672035
::config=[org.ldaptive.ConnectionConfig at 86506638::ldapUrl=ldaps://<redacted>,
connectTimeout=3000, responseTimeout=3000,
sslConfig=[org.ldaptive.ssl.SslConfig at 1639958975
::credentialConfig=org.ldaptive.ssl.CredentialConfigFactory$2 at 2c7106d9,
trustManagers=null, hostnameVerifier=null, hostnameVerifierConfig=null,
enabledCipherSuites=null, enabledProtocols=null,
handshakeCompletedListeners=null], *useSSL=false, useStartTLS=false*,
connectionInitializer=null],
providerConnectionFactory=[org.ldaptive.provider.jndi.JndiConnectionFactory at 43648489::metadata=[ldapUrl=ldaps://<redacted>,
count=1],
environment={java.naming.ldap.factory.socket=org.ldaptive.ssl.ThreadLocalTLSSocketFactory,
com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
com.sun.jndi.ldap.read.timeout=3000},
providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig at 1552295831::operationExceptionResultCodes=[PROTOCOL_ERROR,
SERVER_DOWN], properties={},
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$ActivePassiveConnectionStrategy at 4ee3d023,
controlProcessor=org.ldaptive.provider.ControlProcessor at 3a747492,
environment=null, tracePackets=null, removeDnUrls=true,
searchIgnoreResultCodes=*[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED,
PARTIAL_RESULTS]*, sslSocketFactory=null, hostnameVerifier=null]],
providerConnection=org.ldaptive.provider.jndi.JndiConnection at 68138b78]

Should I ditch Zulu and rebuild my containers with Oracle's Java?

On Wed, Dec 6, 2017 at 10:33 AM Daniel Fisher <dfisher at vt.edu> wrote:

> On Tue, Dec 5, 2017 at 12:05 PM, Darren Boss <darren.boss at computecanada.ca
> > wrote:
>
>> Unfortunately we can not directly implement any changes to the ldap
>> server. Points two and three have already been tested and I've switched
>> back to that exact configuration and it's working, but still with the CA in
>> the JRE's CA bundle.
>>
>
> Put org.ldaptive in DEBUG and you'll be able to see what's happening.
>
> --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/20171206/24b1f0c1/attachment.html>