Configuring TLS Encryption Only for Cloudera Manager
Minimum Required Role: Cluster Administrator (also provided by Full Administrator)
Before enabling TLS security for Cloudera Manager, you will need to create a keystore, submit a certificate-signing request, and install the issued certificate for the Server. If you are using a Private CA, append your Private CA's certificate (and any required intermediary certificates) to the alternate default truststore provided with the JDK for inherent trust. This process is described in more detail at Configuring SSL Encryption in Cloudera Manager Deployments.
|Example Property Values||Description|
|cmhost.sec.cloudera.com||FQDN for Cloudera Manager Server host for this example.|
|/opt/cloudera/security||Base location for security-related files in this example.|
|/opt/cloudera/security/x509||Location for openssl key/, cert/ and cacerts/ files to be used by the Cloudera Manager Agent and Hue.|
|/opt/cloudera/security/jks||Location for the Java-based keystore/ and truststore/ files for use by Cloudera Manager and Java-based cluster services.|
|/opt/cloudera/security/CAcerts||Location for CA certificates (Root and intermediary/subordinate CAs). One PEM file per CA in the chain is required.|
Step 1: Create the Cloudera Manager Server Keystore, Generate a Certificate Request, and Install the Certificate
In the following procedure, we assume a private Certificate Authority is in use, and therefore, trust must be established for that private CA. If a known public CA such as Verisign or GeoTrust is in use then you may not need to explicitly establish trust for the issued certificates. It's possible that newer public CAs might not yet be present within the JDK's default cacerts file. If you run into issues with the import process (such as keytool error: java.lang.Exception: Failed to establish chain from reply), follow the steps for trusting private CAs as documented below.
- Assuming the paths documented in the table above have been created, use keytool to generate a Java keystore and Certificate Signing Request (CSR) for the
Cloudera Manager Server. Replace cmhost and cmhost.sec.cloudera.com in the commands below with your hostname and FQDN. For example:
$ keytool -genkey -alias cmhost -keyalg RSA -keystore \ /opt/cloudera/security/jks/cmhost-keystore.jks -keysize 2048 -dname \ "CN=cmhost.sec.cloudera.com,OU=Support,O=Cloudera,L=Denver,ST=Colorado,C=US" \ -storepass password -keypass password
- -alias is a label used only within the keystore. In this example, the hostname is used for easy tracking and management of the key and certificate. Ensure the -alias consistent across all your commands.
- -keyalg is the algorithm to be used to generate the key. RSA allows for key lengths greater than 1024 bits for certificate requests
- -dname allows you to provide the certificate subject as a single line. If not specified, you will be prompted for the values of the certificate subject information. In that case, use the host FQDN that agents and browsers will use to connect to in the subject First and Last name (CN) question prompt.
- /opt/cloudera/security/jks/cmhost-keystore.jks is an example path to keystore. It must be a path to where you store the keystore file, and where the Cloudera Manager Server host can access it.
- -keypass must be set to the same password value as -storepass for Cloudera Manager to be able to access the keystore
- Generate a certificate signing request for the host (in this example, cmhost)
$ keytool -certreq -alias cmhost \ -keystore /opt/cloudera/security/jks/cmhost-keystore.jks \ -file /opt/cloudera/security/x509/cmhost.csr -storepass password \ -keypass password
- Submit the .csr file created by the -certreq command to your Certificate Authority to obtain a server certificate. When
possible work with certificates in the default Base64 (ASCII) format. Base64-encoded files can easily be modified from .CER or .CRT to .PEM. You will know the file is in ASCII format if you see the
Base64 encoded information with the opening and closing lines as follows:
-----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 less.) -----END CERTIFICATE-----
Adjust the commands based on the keytool documentation if your issued certificate is in the binary (DER) format.
- Copy the root CA certificate and any intermediary/subordinate CA certificates to /opt/cloudera/security/CAcerts/ ( as suggested in the table above).
- Import the root CA certificate first, followed by any intermediary/subordinate CA certificates. Substitute $JAVA_HOME from the command below to the path
for your Oracle JDK.
$ sudo cp $JAVA_HOME/jre/lib/security/cacerts $JAVA_HOME/jre/lib/security/jssecacerts $ sudo keytool -import -alias RootCA -keystore $JAVA_HOME/jre/lib/security/jssecacerts \ -file /opt/cloudera/security/CAcerts/RootCA.cer -storepass changeit $ sudo keytool -import -alias SubordinateCA -keystore \ rm $JAVA_HOME/jre/lib/security/jssecacerts \ -file /opt/cloudera/security/CAcerts/SubordinateCA.cer -storepass changeitRepeat for as many subordinate/intermediary CA certificates as needed. The default -storepass for the cacerts file is changeit. Once this step is complete, copy the jssecacerts file created to the same path on all cluster hosts.
- Now import the Private CA certificates into your Java keystore file. As always, import the root CA certificate first.
$ keytool -import -trustcacerts -alias RootCA -keystore \ /opt/cloudera/security/jks/<cmhost-keystore>.jks -file \ /opt/cloudera/security/CAcerts/RootCA.cer -storepass password $ keytool -import -trustcacerts -alias SubordinateCA -keystore \ /opt/cloudera/security/jks/<cmhost-keystore>.jks -file \ /opt/cloudera/security/CAcerts/SubordinateCA.cer -storepass passwordRepeat for as many subordinate/intermediary CA certificates as needed.
- Import the root CA certificate first, followed by any intermediary/subordinate CA certificates. Substitute $JAVA_HOME from the command below to the path for your Oracle JDK.
- Copy the signed certificate file provided to a location where it can be used by the Cloudera Manager Agents and possibly, Hue.
$ cp certificate-file.cer /opt/cloudera/security/x509/cmhost.pemInstall it with the following keytool command:
$ keytool -import -trustcacerts -alias cmhost \ -file /opt/cloudera/security/x509/cmhost.pem \ -keystore /opt/cloudera/security/jks/cmhost-keystore.jks -storepass passwordYou must see the following response to the above command for the certificate to have been properly imported against its private key.Since the issued certificate has now been imported by the Java keystore, the original certificate-signing request (.CSR) and certificate files are no longer needed by Java services on that host, and the certificate and private key will now be accessed through the keystore.
Certificate reply was installed in keystore
However, it will still be necessary to export the private key from the Jave keystore to make the certificate usable by Hue and the Cloudera Manager Agent. For instructions on reusing certificates, see Private Key and Certificate Reuse Across Java Keystores and OpenSSL.
Step 2: Enable HTTPS for the Cloudera Manager Admin Console and Specify Server Keystore Properties
- Log into the Cloudera Manager Admin Console.
- Select .
- Click the Security category.
- Configure the following TLS settings:
Property Description Path to TLS Keystore File The complete path to the keystore file. For our example, this path would be:
Keystore Password The password for keystore: password
- Click Save Changes to save the settings.
You should now be able to start the Cloudera Manager Server and connect to the Cloudera Manager Admin Console using an HTTPS browser connection. In case of a private CA certificate or self-signed certificate being used, you will need to establish trust in the browser for your certificate. Certificates issued by public commercial CAs should have no problem being trusted by your browser and other Java or OpenSSL-based services.