This topic will guide you through the different certificate strategies that you can employ on your cluster to allow TLS/SSL clients to securely connect to servers using trusted certificates or certificates issued by trusted authorities. The set of certificates required depends upon the certificate provisioning strategy you implement. The following strategies are possible:

• Public CA-signed certificates: Using certificates signed by a trusted public certificate authority (CA) simplifies the integration procedure, because the default Java client already trusts the CA.
• Internal CA-signed certificates: Using certificates signed by an internal CA can also simplify integration if your infrastructure already trusts the internal CA. Otherwise, you must configure all hosts to trust your internal CA.
• Self-signed certificates: Using self-signed certificates complicates the deployment process because you must configure all clients of a particular service to trust the specific certificate used by that service.

  Note: Wildcard domain certificates and certificates using the SubjectAlternativeName extension are not supported at this time.

When choosing an approach to certificate provisioning, keep in mind that TLS/SSL must be enabled for all core Hadoop services (HDFS, MapReduce, and YARN) as a group. For example, if you are running HDFS and YARN on your cluster, you cannot choose to enable TLS/SSL for HDFS, but not for YARN. You must enable it for both services, which implies that you must make certificates available to all daemon roles of both services. You will need to obtain a certificate for each host on which an HDFS or YARN daemon role is running.

  Note: Cloudera Manager and CDH components support either TLS 1.0, TLS 1.1, or TLS 1.2, but not SSL 3.0. References to SSL continue only because of its widespread use in technical jargon.

Continue reading:

• Creating Certificates
• Creating Java Keystores and Truststores
• Private Key and Certificate Reuse Across Java Keystores and OpenSSL