Use case 2: Use an existing Certificate Authority

You can make the Cloudera Manager CA an intermediate CA to an existing Root CA (2a) or you can manually generate the certificates signed by an existing Root CA and upload them to Cloudera Manager (2b).

Option 2a: Enabling Auto-TLS with an Existing Root CA

For new installations only, you can make Cloudera Manager an intermediate CA that signs certificates for all the cluster hosts and services. This is a three-step process. First, make Cloudera Manager generate a Certificate Signing Request (CSR). Second, have the CSR signed by the company’s Certificate Authority (CA). Third, provide the signed certificate chain to continue the Auto-TLS setup. The following example demonstrates these three steps.
  1. Initialize the certmanager with –stop-at-csr option before starting the Cloudera Manager: JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk; /opt/cloudera/cm-agent/bin/certmanager --location /var/lib/cloudera-scm-server/certmanager setup --configure-services --stop-at-csr.
  2. This will generate a Certificate signing request (CSR) file at /var/lib/cloudera-scm-server/certmanager/CMCA/private/ca_csr.pem. If you examine the CSR closely you will see the CSR request the necessary extension X509v3 Key Usage: critical Certificate Sign to sign certificates on its own.
  3. Once you have the signed certificate, make sure that the certificate has the required extensions – X509v3 Basic Constraints: CA: TRUE and X509v3 Key Usage: Key Cert Sign. Proceed with the installation with the following command: JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk; /opt/cloudera/cm-agent/bin/certmanager --location /var/lib/cloudera-scm-server/certmanager setup --configure-services --signed-ca-cert=cm_cert_chain.pem.
  4. Start Cloudera Manager and it should start with its UI on TLS port 7183. If the signed intermediate certificate is already imported into the client browser’s truststore, then you should not see any warnings. In the screenshot below, “Vkarthikeyan Internal Root CA” is the root certificate. This certificate is already trusted by the system and has signed the Cloudera intermediate CA.

Option 2b: Enabling Auto-TLS with Existing Certificates

Use the following approach if you have an existing cluster where you need to enable Auto-TLS, or if there is a need to get the host certificates signed individually by the company’s existing CA. This option adds operational overhead of generating certificates for any new hosts and uploading to Cloudera Manager via API request. In this option, certificates signed by CA are staged and the Auto-TLS is enabled by calling a Cloudera Manager API.
  1. Create the Auto-TLS directory /opt/cloudera/AutoTLS in the Cloudera Manager server. The directory must be owned by the cloudera-scm user.
  2. Create a public/private key for each host and generate the corresponding Certificate Signing request (CSR). Have these CSRs signed by the company’s Certificate Authority (CA).
  3. Prepare all the certificates signed by the company’s CA on the CM server. In this example, all the certificates are located under the /tmp/auto-tls directory. The password used for keystore and truststore are present in key.pwd and truststore.pwd files respectively.
  4. Run the Cloudera Manager API as follows:
    curl -i -v -uadmin:admin -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
    "location" : "/opt/cloudera/AutoTLS",
    "customCA" : true,
    "interpretAsFilenames" : true,
    "cmHostCert" : "/tmp/auto-tls/certs/",
    "cmHostKey" : "/tmp/auto-tls/keys/",
    "caCert" : "/tmp/auto-tls/ca-certs/cfssl-chain-truststore.pem",
    "keystorePasswd" : "/tmp/auto-tls/keys/key.pwd",
    "truststorePasswd" : "/tmp/auto-tls/ca-certs/truststore.pwd",
    "hostCerts" : [ {
    "hostname" : "",
    "certificate" : "/tmp/auto-tls/certs/",
    "key" : "/tmp/auto-tls/keys/"
    }, {
    "hostname" : "",
    "certificate" : "/tmp/auto-tls/certs/",
    "key" : "/tmp/auto-tls/keys/"
    }, {
    "hostname" : "",
    "certificate" : "/tmp/auto-tls/certs/",
    "key" : "/tmp/auto-tls/keys/"
    }, {
    "hostname" : "",
    "certificate" : "/tmp/auto-tls/certs/",
    "key" : "/tmp/auto-tls/keys/"
    } ],
    "configureAllServices" : "true",
    "sshPort" : 22,
    "userName" : "root",
    "password" : "cloudera"
    }' ''
  5. When this API returns successfully, you should see the recent command run as follows.
  6. When this API is executing you can check /var/log/cloudera-scm-server/cloudera-scm-server.log for API logs and also the certmanager logs at /var/log/cloudera-scm-agent/certmanager.log.
  7. Restart the CM service. Then restart the CM agents on all cluster servers.
  8. The CM UI/API will now be available on the TLS port. Now restart all the Cloudera Manager management services.
  9. Restart the Cluster services. Now all the services are configured for wire encryption.
  10. When adding new hosts to this cluster, the following additional steps need to be performed to upload the CA signed host certificates to CM.
    1. The add hosts wizard will prompt the following screen with instructions to upload the certificates.
    2. Upload the certificates to CM using the following command:
      curl -uadmin:admin -X POST --header 'Content-Type:
      application/json' --header 'Accept: application/json' -d '{
        "location": "/opt/cloudera/AutoTLS",
        "interpretAsFilenames": true,
        "hostCerts": [ {
            "hostname": "",
          } ]
      }' ''
    3. Continue to add hosts as usual.
In this example, the CA used to sign all the certificates is “Sec Lab Intermediate CA” which can be found in the screenshot below:
Cloudera Manager UI:
Knox UI: