Troubleshooting TLS/SSL Connectivity

The openssl tool can be run from the host that is running the Cloudera Manager Agent or client service that should be inspected for connectivity issues. You should also test whether the certificate in use by the host is recognized by a trusted CA during the TLS/SSL negotiation.

Use the following command to inspect the connection.
$ openssl s_client -connect []:[port]
For example:
$ openssl s_client -connect
A return code 0 means openssl was able to establish trust of the server through its library of trusted public CAs. If the certificate was self-signed (recommended only on test clusters) or provided by a private CA it might be necessary to add the private CA or self-signed certificate to the truststore using the openssl command. Adding the path to the root CA, -CAfile </path/to/root-ca.pem>, should allow openssl to verify your self-signed or private CA-signed certificate as follows:
$ openssl s_client -connect -CAfile \
Note that providing only the Root CA certificate is necessary to establish trust for this test. The result from the command is successful when you see the return code 0 as follows:
 Verify return code: 0 (ok)
By default, the Cloudera Manager Server writes logs to the /etc/cloudera-scm-server/cloudera-scm-server.log file on startup. Successful start of the server process with the certificate will show logs similar to the following:
2014-10-06 21:33:47,515 INFO WebServerImpl:org.mortbay.log: jetty-6.1.26.cloudera.2 
2014-10-06 21:33:47,572 INFO WebServerImpl:org.mortbay.log: Started SslSelectChannelConnector@ 
2014-10-06 21:33:47,573 INFO WebServerImpl:org.mortbay.log: Started SelectChannelConnector@ 
2014-10-06 21:33:47,573 INFO WebServerImpl:com.cloudera.server.cmf.WebServerImpl: Started Jetty server.