TLS/SSL Overview

Transport Layer Security (TLS) is an industry standard set of cryptographic protocols for securing communications over a network. TLS evolved from Secure Sockets Layer (SSL), which remains part of the name for historical reasons. This overview includes these topics:

TLS/SSL and Its Use of Certificates

TLS/SSL provides privacy and data integrity between applications communicating over a network by encrypting the packets transmitted between endpoints (ports on a host, for example). Configuring TLS/SSL for any system typically involves creating a private key and public key for use by server and client processes to negotiate an encrypted connection at runtime. In addition, TLS/SSL can use certificates to verify the trustworthiness of keys presented during the negotiation to prevent spoofing and mitigate other potential security issues.

Setting up Cloudera clusters to use TLS/SSL requires creating private key, public key, and storing these securely in a keystore, among other tasks. Although adding a certificate to the keystore may be the last task in the process, the lead time required to obtain a certificate depends on the type of certificate you plan to use for the cluster.

Certificates Overview

Certificates can be signed in one three different ways:
Type Usage Note
Public CA-signed certificates Recommended. This type of certificate is signed by a public certificate authority (CA), such as Symantec or Comodo. Public CAs are trusted third-parties, so obtaining certificates from one of them simplifies deployment because some of the security infrastructure (root CAs, for example) is already in place, in the Java JDK and its default truststore, for example. See Obtain and Deploy Server Certificate for details.
Internal CA-signed certificates This type of certificate is signed by your organization's internal CA (if your organization has deployed its own, for example, by using Microsoft Active Directory Certificate Services or by setting up an OpenSSL Certificate Authority. Using an internal CA may require establishing the trust chain for certificates signed by an internal CA, depending on your IT infrastructure. See How to Configure TLS Encryption for Cloudera Manager for information about establishing trust as part of configuring a Cloudera Manager cluster.
Self-signed certificates Not recommended for production deployments. Self-signed certificates are created and stored in the designated keystore as a by-product of the key generation process, and should be replaced by a signed certificate. Using self-signed certificates requires configuring each client to trust the specific certificate (in addition to generating and distributing the certificates). However, self-signed certificates are acceptable for use in non-production deployments, such as proof-of-concept setups. See Using Self-signed Certificates for TLS for details.

During the process of configuring TLS/SSL for the cluster, you typically obtain a certificate for each host in the cluster, and re-use the certificate obtained in a given format (JKS, PEM) as needed for the various services (daemon roles) supported by the host. For information about converting formats, see How to Convert Certificate Encodings (DER, JKS, PEM) for TLS/SSL. As an alternative to creating discrete certificates for each host in the cluster, as of Cloudera Manager/CDH 5.9, all Cloudera cluster components support wildcard domains and SubjectAlternateName certificates.

Wildcard Domain Certificates and SAN Certificates Support

Cloudera Manager and CDH (as of release 5.9) support use of wildcard domain certificates and SAN certificates.

A wildcard certificate—a certificate with the common name *, as in *.example.com, rather than a specific host name—can be used for any number of first level sub-domains within a single domain name. For example, a wildcard certificate can be used with host-1.example.com, host-2.example, host-3.example.com, and so on.

Certificates obtained from public CAs are not free, so using wildcard certificates can reduce costs. Using wildcard certificates also makes it easier to enable encryption for transient clusters and for clusters that need to expand and shrink, since the same certificate and keystore can be re-used.

A SubjectAlternativeName or SAN certificate is a certificate that uses the SubjectAlternativeName extension to associate the resulting certificate with multiple specific host names. In the context of clusters, SAN certificates are used in high-availability (HA) configurations in which a load balancer targets two different specific hosts as primary and secondary nodes for fail-over purposes. See Server Certificate Requirements for HA Deployments for an example.

Wildcard Certificates Wildcard certificates can be used by all hosts within a given domain. Using wildcard certificates for all hosts in the cluster can reduce costs but also exposes greater potential risk.
SubjectAlternativeName Certificates SubjectAlternativeName (SAN) certificates are bound to a set of specific DNS names. A single SAN certificate can be used for all hosts or a subset of hosts in the cluster. SAN certificates are used in Cloudera Manager high-availability (HA) configurations.

Obtain Renewed Certificates Before Expiration Dates

The signed certificates you obtain from a public CA (or those you obtain from an internal CA) have an expiration date, such as that shown in this excerpt:



Expired certificates quite simply do not work and will cause the cluster to fail. Cloudera Manager Agent hosts, for example, will not be able to validate the Cloudera Manager Server host and will fail to launch the cluster nodes. Administrators should note expiration dates of all certificates when they deploy the certificates to the cluster nodes and setup reminders to allow enough time to renew.