Enabling SSL for HDFS, MapReduce and Yarn

[#1]

Hi All,

I have a question regarding the common name attribute of key stores when enabling SSL for HDFS,MapReduce and Yarn along with Ranger HDFS plugin.

I have read articles that state that the common name needs to be identical across the cluster for the keystores for the xasecure.policymgr.clientssl.keystore key store. This key store seems to be responsible for protecting the Ranger console so when not set to the FQDN of the console server breaks the Ranger console.

https://community.hortonworks.com/articles/16373/ranger-ssl-pitfalls.html

If this configuration is set then the journal nodes complain about the common name in the certificate not being the same as the hostname. Additionally, the configuration item common.name.for.certificate in hdfs-site.xml and the "Common Name for Certificate" value in the ranger plug-in policies implies that a single common name is required in all keystores across the cluster.

 response={"httpStatusCode":400,"statusCode":1,"msgDesc":"Unauthorized access. No common name for certificate set. Please check your service config","messageList":[{"name":"OPER_NOT_ALLOWED_FOR_ENTITY","rbKey":"xa.error.oper_not_allowed_for_state","message":"Operation not allowed for entity"}]}, serviceName=<clusterName>_hadoop

If the key stores have the FQDN set then the name nodes throw an SSLException.

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching <hostname> found

I am probably missing something. Do I need two distinct sets of keystores? One with an identical common name and one set with the FQDN for each host? Or should I be using a common subject alt name in the certificates?

[#2 · Accepted solution]

@Andrew Ryan

Please chk if this can help

http://java.globinch.com/enterprise-java/security/fix-java-security-certificate-exception-no-matchin...

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-l...