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.
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.
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.
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.
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.
Create the Auto-TLS directory /opt/cloudera/AutoTLS in the Cloudera Manager server. The
directory must be owned by the cloudera-scm user.
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).
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.
When this API returns successfully, you should see the recent command run as follows.
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.
Restart the CM service. Then restart the CM agents on all cluster servers.
The CM UI/API will now be available on the TLS port. Now restart all the Cloudera Manager
management services.
Restart the Cluster services. Now all the services are configured for wire encryption.
When adding new hosts to this cluster, the following additional steps need to be performed
to upload the CA signed host certificates to CM.
The add hosts wizard will prompt the following screen with instructions to upload the
certificates.
Upload the certificates to CM using the following
command: