The problem was iptables on the data nodes. Once these were flushed the following command worked a treat.   hadoop distcp -D ipc.client.fallback-to-simple-auth-allowed=true hdfs://active_namenode:8020/tmp/test.txt swebhdfs://active_namenode:50470/tmp/test.txt Apologies for my confusion.  ... View more

@Andrew Ryan Please chk if this can help http://java.globinch.com/enterprise-java/security/fix-java-security-certificate-exception-no-matching-localhost-found/ Root Cause of the Exception: java.security.cert.CertificateException: No name matching <host> found At run-time, Java check host name against the names specified in a digital certificate as required for TLS and LDAP. So if you are using for example, https://localhost:8443/MyService/. , the runtime will check if the certificate allows use of the given DNS name, in this case “localhost”. This matching is performed using the matching rules specified by RFC2459. As per the java doc, “If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.” Also “If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.)” The above points indicate that, the certificate CN (Common Name) should be the same as host name in the URL. If the CN in the certificate is not the same as the host name, you will get the error “java.security.cert.CertificateException: No name matching <the_host_name_used> found”, where , “the_host_name_used” is the host name you used as part of the URL in your client application. https://www.mkyong.com/webservices/jax-ws/java-security-cert-certificateexception-no-name-matching-localhost-found/ ... View more

This issue was resolved by updating the zookeeper jaas config to use a keytab rather than a ticket cache. The cache was expiring and the auth failing. I thing that I've learned is that the updated configs can take a while to propagate through the cluster. I had tried this config before but likely didn't wait long enough before discounting it as the solution. Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true useTicketCache=false keyTab="/etc/security/keytabs/hbase.service.keytab" principal="hbase/<your_host>@<your_realm>"; }; ... View more