Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Replacing system self signed Ambari certificates?

Replacing system self signed Ambari certificates?

New Contributor

Hi guys,

A number of certificates have been flagged as vulnerabilities in a recent security scan. The primary certificate for the Ambari Server Web UI is a company signed 2048 bit certificate, which is fine.. although it seems that Ambari has automatically generated a group of certificates for inter-node communications which don't meet the IT standards (1024 bit).

I have attempted to create new certs and have tried to replace them on the server although Ambari doesn't register them and I'm left with broken processes. The only way I know of changing the certificates is using the 'ambari-server setup-security' command. Although that is only relevant to the Ambari Web UI cert. Does anyone else know how to replace the system level certificates?

Thanks in advance,

2 REPLIES 2

Re: Replacing system self signed Ambari certificates?

Super Mentor

@L V


Ambari agents communicates to ambari server on 8440 (Handshake Port for Ambari Agents to Ambari Server) and 8441 (Registration and Heartbeat Port for Ambari Agents to Ambari Server) HTTPS ports. These are secure ports so ambari server generates some default certificates for the communication with agents. On Ambari side these certs can be found here.

On Ambari Server Side:

# ls /var/lib/ambari-server/keys/
ca.config  ca.crt  ca.csr  ca.key  db  keystore.p12  pass.txt


However it is possible to replace those certificates with the CA Signed certificates as described in the following thread: https://community.hortonworks.com/questions/88920/replace-self-signed-ssl-certificates-with-ca-signe...

.

.

- Also for more better security ambari provides an option to setup two way ssl between ambari server and agent using CA Signed certificates as described in the following article that can be used to generate the desired certificates for use.
https://community.hortonworks.com/content/kbentry/107092/configure-2-way-ssl-between-ambari-server-a...

.


Or you also might want to refer to the following Doc which explains how you ca create more strong certificates and place them inside the ambari server. https://cwiki.apache.org/confluence/display/AMBARI/Handling+Expired+HTTPS+Certificates

.

Re: Replacing system self signed Ambari certificates?

New Contributor

Hi @Jay SenSharma

Will I need to import certificates into a keystore on each server individually or do I just transfer all the certificates to the management node and add them into that keystore? I forgot to mention intially that the certificates that were flagged are located in the: /var/lib/ambari-agent/keys/ directory in each server.

For example:

app1.example.com.crt

cluster1.example.com.crt

etc...

These have been my attempts:

1.) Hot swapped the certificates on the affected server with a '.crt' (Both Agent and Server were restarted) - Resulted in heartbeat lost for that node.

2.) Hot swapped the certificates on the affected server with a '.pem' (Both Agent and Server were restarted) - Resulted in heartbeat lost for that node.

3.) On the management node. A trust store was created and the app server '.crt' certificate was imported. The trust store was then added into the Ambari Server. After rebooting both Server and Agent for the app server, heartbeat was lost. On further inspection, despite a 2048 bit certificate being added into the new trust-store. After every restart of the agent, a new 1024 bit certificate was generated and placed in the 'var/lib/ambari-agent/keys/' folder.

4.) On the management node. A trust store was created and the app server '.pem' certificate was imported. The trust store was then added into the Ambari Server. After rebooting both Server and Agent for the app server, heartbeat was lost. On further inspection, despite a 2048 bit certificate being added into the new trust-store. When using the '.pem' certificate the agent was not able to generate a new certificate of any kind on the app server.

5.) Turning off 2 way SSL alleviates errors and the agents are able to communicate with the cluster. Although this presents more vulnerabilities than it solves.

Don't have an account?
Coming from Hortonworks? Activate your account here