Odon... I believe that the error you are seeing may be related to the trust store configuration.
Look at the configuration in your gateway-site.xml file. Check the value for `gateway.client.auth.needed` and `gateway.client.auth.wanted`. If either exist or are "true", then check the `gateway.truststore.path`. If is set, make sure the path specified for that parameter exists and matches the trust store type set in `gateway.truststore.type`. If that looks good, make sure that the trust store's password was set properly in the Gateway's credential store under the alias of "gateway-truststore-password". Finally attempt to list the contents of the trust store to make sure all is good and that you see an alias for your LDAP's servers certificate. keytool -list -keystore <gateway.truststore.path> -storetype <gateway.truststore.type> If `gateway.client.auth.needed` or `gateway.client.auth.wanted` exist and are set to "true" but the `gateway.truststore.path` value is not set; then the Gateway is using the gateway.jks file as its trust store. This file will most likely exist in <GATEWAY_HOME>/data/security/keystores/gateway.jks. The password for this file will be the master secret you previously set up. Run the following command to make sure all is will with this file: keytool -list -keystore <GATEWAY_HOME>/data/security/keystores/gateway.jks -storetype jks If `gateway.client.auth.needed` or `gateway.client.auth.wanted` do not exist or are set to "false", the Gateway is using the cacerts file. You should make sure that this file has not been corrupted. The password should be "changeit" keytool -list -keystore /usr/jdk64/jdk1.8.0_112/jre/lib/security/cacerts In any case, make sure these trust store files are readable by all since the knoxcli can be run as anyone. ls -l /usr/jdk64/jdk1.8.0_112/jre/lib/security/cacerts -rw-r--r--. 1 root root 112860 Sep 23 2016 /usr/jdk64/jdk1.8.0_112/jre/lib/security/cacerts If none of this helps, maybe the issue is with the cert presented by the LDAP server. You can grab that by issuing the following command: openssl s_client -connect ldap-host:636 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > server.pem I hope this helps... Rob On Thu, Apr 4, 2019 at 8:27 AM Odon Copon <odonco...@gmail.com> wrote: > Hi, > I'm trying to make Knox connect to LDAPS to perform authentication, but > I'm getting the following error message: > > Caused by: javax.naming.CommunicationException: simple bind failed: > ldap-host:636 [Root exception is javax.net.ssl.SSLException: > java.lang.RuntimeException: Unexpected error: > java.security.InvalidAlgorithmPara > meterException: the trustAnchors parameter must be non-empty] > > This is while running "knoxcli.sh system-user-auth-test --cluster ldap --d" > > And my simple topology is the following: > > ldap.xml: > > <topology> > <gateway> > > <provider> > <role>authentication</role> > <name>ShiroProvider</name> > <enabled>true</enabled> > <param name="main.ldapRealm" > value="org.apache.hadoop.gateway.shirorealm.KnoxLdapRealm"/> > <param name="main.ldapContextFactory" > value="org.apache.hadoop.gateway.shirorealm.KnoxLdapContextFactory"/> > <param name="main.ldapRealm.contextFactory" > value="$ldapContextFactory"/> > > <param name="main.ldapRealm.contextFactory.url" > value="ldaps://ldap-host:636"/> > <param name="main.ldapRealm.contextFactory.systemUsername" > value="uid=user-uid,ou=account,dc=company,dc=net"/> > <param name="main.ldapRealm.contextFactory.systemPassword" > value="password"/> > > <param name="main.ldapRealm.searchBase" > value="ou=Users,dc=company,dc=net"/> > <param name="main.ldapRealm.userSearchAttributeName" > value="displayName"/> > <param name="main.ldapRealm.userObjectClass" value="person"/> > > <param name="urls./**" value="authcBasic"/> > </provider> > > </gateway> > <service> > <role>KNOX</role> > </service> > </topology> > > > The ldap certs are all in java cacerts and knox-env.sh sees correctly the > java location. So I might be missing something. > Any idea? > With other ldap tools, like ldapsearch or ldapwhoami it works, so > wondering what I'm missing in my topology or gateway configuration. > > Thanks. >
