Community Articles
Find and share helpful community-sourced technical articles
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.
Labels (1)
New Contributor

In many cases, it's sufficient or even desirable to use self-signed, or company-internal signed certificates to provide TLS encryption, for example between your users' browsers and Ambari and also between Ambari and an LDAP service (LDAPS).

If you're not careful with your management of the certificates for each component you're working with, it's possible that you can end up with a broken Ambari views installation. In such cases, when you try to load Ambari views, you might instead see a stack trace which on the surface may appear cryptic, with an error code such as "RA040". If you do see

javax.net.ssl.SSLHandshakeException

in the trace somewhere, it's likely that your problem lies with the custom trust store in Ambari.

Consider this scenario:

1. You set up HTTPS for Ambari using a private CA - e.g. your corporate IT team to sign your certificates so that IT-managed browsers which already have imported the CA certificates do not generate warnings. You used "ambari-server setup-security" for this, choosing option 1 "Enable HTTPS for Ambari Server"

2. You then enabled LDAPS-based authentication, but during the process, unwittingly switch to using a custom keystore because the team that runs LDAP have signed their own certificates has CA-certificate associated with the CA that signed your LDAP server's certificate.

You might have done something like this

mkdir /etc/ambari-server/keys
$JAVA_HOME/bin/keytool -import -trustcacerts -alias root -file /etc/openldap/cacerts/ldap-ca.crt -keystore /etc/ambari-server/keys/custom-keystore.jks

Then during "ambari-server setup-ldap" you may have answered as follows

Do you want to provide custom TrustStore for Ambari [y/n] (n)?y
TrustStore type [jks/jceks/pkcs12] (jks):
Path to TrustStore file :/etc/ambari-server/keys/custom-keystore.jks
Password for TrustStore:
Re-enter password:

By switching to the custom keystore, you'll lose the previously established trust that you set up when you set up HTTPS for Ambari. Ambari needs to be able to connect to itself over HTTPS for Views to work and if it can't trust it's own connection you will see the SSL handshake errors.

To fix this problem you need to re-import the corporate IT team's CA back into your custom keystore in Ambari.

Place a copy of your corporate CA's certificates in a path that's accessible to you, then run "ambari-server setup-security" again, but this time choose option 5 - Import certificate to truststore. Ambari is already configured to use the custom-keystore.jks file, so all you need to do is provide the path to the certificate.

[00:48]:[root@ambariserver:~]# ambari-server setup-security
Using python  /usr/bin/python
Security setup options...
===========================================================================
Choose one of the following options:
  [1] Enable HTTPS for Ambari server.
  [2] Encrypt passwords stored in ambari.properties file.
  [3] Setup Ambari kerberos JAAS configuration.
  [4] Setup truststore.<br>
  [5] Import certificate to truststore.
===========================================================================
Enter choice, (1-5): 5
Do you want to configure a truststore [y/n] (y)? y
Do you want to import a certificate [y/n] (y)? y
Please enter an alias for the certificate: CORP-CA
Enter path to certificate: /tmp/CORP-CA.pem
Ambari Server 'setup-security' completed successfully.
[00:49]:[root@ambariserver:~]#

Restart the Ambari server and with a bit of luck your Ambari Views will be working again!

169 Views
0 Kudos
Don't have an account?
Coming from Hortonworks? Activate your account here
Version history
Revision #:
1 of 1
Last update:
‎09-30-2016 07:34 PM
Updated by:
 
Contributors
Top Kudoed Authors