The following sections will walk you through obtaining certificates from commercial Certificate Authorities and creating self-signed test certificates.
Keytool is a utility for creating and managing certificates and cryptographic keys, and is part of the standard JDK distribution. The keytool executable usually resides in $JAVA_HOME/bin.
Java-based services such as HDFS, MapReduce, and YARN use the JKS format by default. For this reason it is particularly convenient to use keytool for managing keys and certificates for these services. In the following topics, we assume you are using keytool.
For additional information on keytool, refer the keytool documentation.
Python-based services such as Hue expect certificates and keys to be stored in PEM format. When managing certificates and keys for such services, you may find it convenient to use the openssl tool.
Refer the openssl documentation for more information.
Obtaining a Production Certificate from a Commercial CA
Once you have decided on a certificate-provisioning strategy, and have determined which hosts require certificates, you will typically purchase the necessary certificates from a commercial Certificate Authority (CA). The procedure for applying for a certificate varies from one CA to another, but typically involves providing some form of proof that you are the legitimate owner of the domain name for which you are requesting a certificate, generating a key pair, and submitting a Certificate Signing Request (CSR) to the CA.
As noted above, you may find it convenient to use the Java keytool utility to generate your key pair and CSR, and to manage your certificates. The CA you choose will provide instructions for obtaining and installing a certificate; typically, there will be separate sets of instructions for different web and application servers. The instructions for Java-based servers (Tomcat, for example), will usually describe the following process comprising three keytool commands to obtain a certificate:
- keytool -genkeypair to generate a public/private key pair and create the keystore.
- keytool -certreq to create the CSR.
- keytool -importcert to import the signed certificate into the keystore.
$ keytool -genkeypair -keystore node1.keystore -alias node1 \ -dname "CN=node1.example.com,O=Hadoop" -keyalg RSA \ -keysize 2048 -storepass changeme -keypass changeme
This command generates a pair of 2048-bit keys using the RSA key algorithm, one of several available. The keys are stored in a keystore file called node1.keystore, in a keystore entry identified by by the alias node1. The keystore password (which protects the keystore as a whole) and the key password (which protects the private key stored in the node1 entry) are set using the -storepass and -keypass options (respectively). -keypass must be set to the same password value as -storepass for Cloudera Manager to access the keystore.
To create a CSR, you would use a command similar to the following:
$ keytool -certreq -keystore node1.keystore -alias node1 \ -storepass changeme -keypass changeme -file node1.csr
$ keytool -importcert -keystore node1.keystore -alias node1 \ -storepass changeme -keypass changeme -trustcacerts -file node1.crt
Here we assume that the CA's reply is stored in the file node1.crt.
Creating Self-Signed Test Certificates
It is also possible to create your own test certificates. These certificates are typically self-signed; that is, they are signed by your own private key, rather than that of an external CA. Such test certificates are useful during testing and bringup of a cluster.
$ keytool -genkeypair -keystore node1.keystore -keyalg RSA \ -alias node1 -dname "CN=node1.example.com O=Hadoop" \ -storepass changeme -keypass changemeSet -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.