Keys, keystores, certificates, and other security artifacts can be created and managed using key management utilities, including the Java Keytool and OpenSSL. In addition to the brief overviews below, see How to Convert PEM to JKS and JKS to PEM for TLS/SSL Services and Clients for more information about using these two tools.

Distributing the certificates, keys, truststore—in short, all security artifacts used for TLS/SSL intra-cluster communications—is part of this and some subsequent processes. To keep things organized, Cloudera recommends that you create the directory and distribute the artifacts when you receive them, even though they may not be immediately needed.

The following table shows the recommended directory structure for the security artifacts created in this and subsequent sections. Use your own names if you prefer but for ease of deployment use the same directory names across all hosts in the cluster.

Directories and artifacts persist during system upgrades. For security purposes, for any host you remove from a cluster, remove any directories you create and more importantly, remove any security artifacts (keys, certificates, and so on) they may contain.

$ sudo cp $JAVA_HOME/jre/lib/security/cacerts $JAVA_HOME/jre/lib/security/jssecacerts

  Note: For certificates obtained from an internal (rather than a public) CA, you must import the CA. See How to Add Root and Intermediate CAs to Truststore for TLS/SSL for details.

If you do not have the $JAVA_HOME variable set, replace it with the path to the Oracle JDK. For example, the default path to the Java JDK on a Cloudera Manager Server host is:

/usr/java/jdk1.7.0_67-cloudera/

  Important: Do not skip this step. Not using cacerts as the basis for the jssecacerts trust store can cause many issues because cacerts contains all default publicly available CA-signed certificates that are needed during the TLS/SSL handshake.

The steps in this section generate discrete public keys and create CSRs to obtain the certificate for each. To create a SAN certificate such as for an HA configuration with a load balancer, see Server Certificate Requirements for HA Deployments for an example.

  Note: Always check with your selected public CA before creating any CSRs, and be sure to follow the CA-specific processes. For an internal CA, follow your organization's internal process for creating and submitting CSRs.

1. On the Cloudera Manager Server host, use the keytool utility to generate a keypair and a keystore named for the server. Replace the OU, O, L, ST, and C entries with the values for your organization name, location, and country code (US, in the example):

   $ sudo keytool -genkeypair -alias $(hostname -f)-server -keyalg RSA -keystore \
   /opt/cloudera/security/pki/$(hostname -f)-server.jks -keysize 2048 -dname \
   "CN=$(hostname -f),OU=Dept,O=Example.com,L=City,ST=State,C=US" \
   -storepass password -keypass password
   

   Use the same password for the key and its keystore (-keypass and -storepass, respectively): Cloudera Manager does not support using different passwords for the key and keystore.
2. Generate a certificate signing request (CSR) for the public key (contained in the keystore as a result of the command above). In this command below, enter the password that you set for the key and the keystore in the command above:

   $ sudo keytool -certreq -alias $(hostname -f)-server \
   -keystore /opt/cloudera/security/pki/$(hostname -f)-server.jks \
   -file /opt/cloudera/security/pki/$(hostname -f)-server.csr -storepass password \
   -keypass password

1. Submit the CSR file to your certificate authority using the process and means required by the CA, for example, email or web submission. For the certificate format, specify PEM (base64 ASCII) (see Step 5 below for an example of PEM formatted certificate heading and closing structure).
2. The public CA will request specific details from you, to verify that you own the domain name contained in the CSR, before they issue the certificate.
3. The public CA sends you the signed certificate for your public key. The certificate includes (among other details) notBefore and notAfter properties that specify the lifetime of the certificate, which is typically one-year from the time issued.
     Important: Document the expiration dates for all certificates you deploy in your clusters so that you can pro-actively renew certificates prior to their expiration. See Obtain Renewed Certificates Before Expiration Dates for details about checking expiration dates on certificates already deployed.
4. When you receive the signed certificate from the CA, you can proceed with Step 5.

-----BEGIN CERTIFICATE-----
<The encoded certificate is represented by multiple lines of exactly 64 characters, except
for the last line, which can contain 64 characters or fewer.>
-----END CERTIFICATE-----

If your issued certificate is in binary (DER) format, convert it to PEM format before continuing. See How to Convert Formats (PEM, JKS) for TLS/SSL Clients and Services for details.

To modify the truststore (jssecacerts) to explicitly trust certificates or certificate chain (as you might for certificates signed by an internal CA), follow the steps in How to Add Root and Intermediate CAs to Truststore for TLS/SSL.

cp cert-file-recd /opt/cloudera/security/pki/$(hostname -f)-server.cert.pem

$ sudo keytool -importcert -alias $(hostname -f)-server \
-file /opt/cloudera/security/pki/$(hostname -f)-server.cert.pem \
-keystore /opt/cloudera/security/pki/$(hostname -f)-server.jks

... is not trusted. Install reply anyway? [no]:  yes

Certificate reply was installed in keystore

If you cannot successfully import the certificates, see Getting Support for information about resources for help, including how to contact Cloudera Support.