Tom James created HADOOP-13825:
----------------------------------
Summary: KMSClientProvider is not using truststore and keystore
provided in ssl-client.xml
Key: HADOOP-13825
URL: https://issues.apache.org/jira/browse/HADOOP-13825
Project: Hadoop Common
Issue Type: Bug
Components: kms
Affects Versions: 2.6.0
Reporter: Tom James
When a KMSClientProvider is initialized it initializes a SSLFactory object with
its own trust store and key store (if hadoop.ssl.require.client.cert=true). But
during the course of execution, KMSClientProvider.createConnection gets called,
which in turn calls KerberosDelegationTokenAuthenticator.authenticate(). Inside
authenticate, conn = (HttpURLConnection) url.openConnection() gets called which
uses an entirely different trust store (default trust store in JAVA_HOME;
"/usr/java/jdk1.7.0_67-cloudera/jre/lib/security/jssecacerts" for me) and key
store (null).
This initializes the JVM trust store and keystore to the aforementioned trust
store and keystore.
This is causing problems down the line since all the specific certificates
(client, server, custom root certificates) are all in the trust store and
keystore specified in ssl-client.
Please find attached the log.
PS:
hadoop version
Hadoop 2.6.0-cdh5.7.1
Subversion http://github.com/cloudera/hadoop -r
ae44a8970a3f0da58d82e0fc65275fff8deabffd
Compiled by jenkins on 2016-06-01T23:25Z
Compiled with protoc 2.5.0
>From source with checksum 298b68dc3b308983f04cb37e8416f13
This command was run using /usr/lib/hadoop/hadoop-common-2.6.0-cdh5.7.1.jar
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
