The alias for trust entries is irrelevant. You can use "ldap_server" or whatever you want. The alias is only needed if the cert or key needs to be looked up explicitly - like if you wanted to use a specific cert and private to set up an SSL connection.
Rob On Fri, Apr 5, 2019 at 11:18 AM Odon Copon <odonco...@gmail.com> wrote: > Hi Robert, > Thanks for all the info provided. That was really helpful. > If the pem cert gets into gateway.jks, what alias should it have? What > kind of alias is Knox expecting the ldap pem to be stored under? > > Thanks > > On Thu, 4 Apr 2019 at 14:36, Robert Levas <rle...@cloudera.com> wrote: > >> 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. >>> >>
