Level 3: Configuring TLS Authentication of Agents to the Cloudera Manager Server

1. Create a local copy of the default openssl.cnf file, usually found at /etc/pki/tls/openssl.cnf (this may change according to your OS).

   cp /etc/pki/tls/openssl.cnf ./myopenssl.cnf

2. Add the following section to the end of the file:

   cat >> ./myopenssl.cnf <<EOF
   [ cloudera_req ]
   basicConstraints = CA:FALSE
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   extendedKeyUsage = serverAuth, clientAuth
   EOF

3. Run the following command on the Agent, replacing hostname with your actual hostname. The -subj command line option allows you to provide the certificate subject as a single line. If you do not specify the certificate subject (-subj) as an argument, you will be prompted for the values of the certificate subject information. In that case, use the host FQDN that Agents will use to connect from in the subject First and Last name (CN) question prompt. Country (C) requires a 2 letter country code. The "/" is replaced with "," in the actual CSR and private key file.

   $  openssl req -subj  '/CN=hostname.sec.cloudera.com/OU=Support/O=Cloudera/L=Denver/ST=Colorado/C=US' \
   -config ./myopenssl.cnf -reqexts cloudera_req  \
   -out /opt/cloudera/security/x509/hostname.csr -new -newkey rsa:2048 \ 
   -keyout /opt/cloudera/security/x509/hostname.key -passout pass:password

   password provides a password to protect the private key file. Keep the password in a safe place; you must provide a key password file to the Agent to complete configuration.

The CSR file created (/opt/cloudera/security/x509/hostname.csr) is collected from cluster hosts for submission to the certificate authority (CA) for signing. In the example paths, you copy the issued CA-signed certificate file to /opt/cloudera/security/x509 on each cluster host. For easy management and tracking of files, name the files in the hostname.pem format, replacing hostname with the actual hostname.

The CSR can be examined with the following command:

$  openssl req -text -noout -verify -in  /opt/cloudera/security/x509/hostname.csr

Examine the issued certificate to make sure the requested attributes are present under the X509v3 Extended Key Usage field.

$ openssl x509 -in /opt/cloudera/security/x509/hostname.pem -text -noout
...
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
                TLS Web Client Authentication
...

If the certificate does not have both TLS Web Server Authentication and TLS Web Client Authentication flags set, you will need to explicitly add the Agent's certificate to the Cloudera Manager Server truststore. This can be done when you create the Cloudera Manager Server truststore in Step 9.

Create a Java Keystore and private key files for an Agent host as follows:

$ keytool -genkeypair -alias hostname -keyalg RSA -keystore \
/opt/cloudera/security/jks/hostname-keystore.jks -keysize 2048 -dname \
"CN=cmhost.sec.cloudera.com,OU=Support,O=Cloudera,L=Denver,ST=Colorado,C=US" \
-storepass password -keypass password

password provides a password to protect the private key file. Set -keypass to the same value as -storepass. Cloudera Manager assumes that the same password is used to access both the key and the keystore, and therefore, does not support separate values for -keypass and -storepass.

Agents will authenticate themselves to the Cloudera Manager Server using the certificate issued in this step. However, it's possible that the issued certificate only has the TLS Web Server Authentication flag set, and not the TLS Web Client Authentication flag. Such certificates cannot be used by Cloudera Manager Agents to identify themselves as clients to the Cloudera Manager Server. To make sure Agents can use the issued certificates, you must request explicitly make this request when you generate the CSR as follows:

1. Generate a certificate signing request (CSR) and submit it to your CA for a signed certificate. Use keytool's extended attributes to request both serverAuth and clientAuth.

   $ keytool -certreq -alias hostname  \
   -keystore /opt/cloudera/security/jks/hostname-keystore.jks  \ 
   -file /opt/cloudera/security/x509/hostname.csr  \
   -ext EKU=serverAuth,clientAuth  \ 
   -storepass password -keypass password

2. Examine the keystore to make sure the requested options are present under the ExtendedKeyUsages section.

   $ keytool -list -v -keystore hostname-keystore.jks
   ...
   ObjectId: 2.5.29.37 Criticality=false
   ExtendedKeyUsages [
     serverAuth
     clientAuth
   ...

   If the keystore still does not have both serverAuth and clientAuth attributes set, you will need to explicitly add the Agent's certificate to the Cloudera Manager Server truststore. This can be done when you create the Cloudera Manager Server truststore in Step 9.
3. If you are using a Private CA, first import the root CA certificate followed by the intermediary/subordinate CA certificates into the Java keystore created previously.

    $ keytool -importcert -trustcacerts -alias RootCA -keystore \
   /opt/cloudera/security/jks/hostname-keystore.jks -file \ 
   /opt/cloudera/security/CAcerts/RootCA.cer -storepass password

   Repeat the following for all subordinate/intermediary CA certificates presented.

   $ keytool -importcert -trustcacerts -alias SubordinateCA -keystore \
   /opt/cloudera/security/jks/hostname-keystore.jks -file \ 
   /opt/cloudera/security/CAcerts/SubordinateCA.cer -storepass password

4. Copy the issued signed certificate file provided by your CA to the location from where it will be imported by the Cloudera Manager Agent and possibly Hue.

   $ cp certificate-file.cer /opt/cloudera/security/x509/hostname.pem

5. Import the issued certificate file into the previously created Java keystore (.jks) with the following command:

   $ keytool -import -trustcacerts -alias <hostname> \
   -keystore /opt/cloudera/security/jks/<hostname>-keystore.jks \
   -file /opt/cloudera/security/x509/<hostname>.pem -storepass password