TLS/SSL Self-Certificate or Authority Certificate for private Cluster in production?

[#1]

Hi all,

We have currently a Hadoop cluster in test in a private cloud with private ip and hostname:
- <private_ip_1> mh1.example.com (namenode 1 in private cloud)
- <private_ip_2> mh2.example.com (namenode 2 in private cloud)
- <private_ip_3> w1.example.com (worker 1 in private cloud)
...
- <private_ip_n> wn.example.com (worker n private cloud)
- <private_ip_m> eg1.example.com (edge node 1 + cloudera manager service in public cloud)
- <private_ip_o> eg2.example.com (edge node 2 + hue etc. in public cloud)

We can access on the private cloud only through the edge nodes and the cluster is kerberized with sentry.
For the moment we use only self-certificate, but now we want to put the cluster in production.

My question is that: Could we use official authority certificate in our case ? Because if I undestand well, authority certificate is only for public domain and public IP.

Or what I was thinking for production is:
- Self-Certificate for Cloudera Manager Agents (in all nodes in private cloud)
- Authority Certificate for HUE UI on edge node on public cloud (with public ip adress)
- Authority Certificate for Cloudera Manager UI on edge node on public cloud (with public ip adress)

Do you think it's ok or overkill for production ? Am I missing something ?

Thank you in advance,

Vincent

[#2 · Accepted solution]

@vincenth,

I'm not sure what you mean by "Authority Certificate." I think you mean Certificate Authority.

https://en.wikipedia.org/wiki/Certificate_authority

If so, then no, there is no restriction on this being public.  You can create and manage your own authority.

The advantage of using a public CA is that it is likely already trusted by clients (like browsers or openssl).  However, if you have control over your clients, there is no reason why the clients could not import whatever root CA public certificate of the CA you create.

If you are OK with running creating and using your own CA, you can save a good deal of money since public CAs do need to charge for their services.

If you have the $ and don't want to manage a CA, a public CA will work fine.

I wouldn't recommend self-signed certificates for production as management can become cumbersome.   Truststores, rather than havining your root CA may require every certificate of every host in your cluster.  If you add a host, then, you would need to update all trust stores.

If you have clients connecting to a different hostname (public) to CM and Hue, then you can add the hostnames you want to Subject Alternative Name in the certificate.

see:  https://en.wikipedia.org/wiki/Subject_Alternative_Name

If you are interested in learning about using OpenSSL to maintain your own CA, this person seems to explain it pretty well (though I haven't gone over it completely):

https://jamielinux.com/docs/openssl-certificate-authority/index.html

I can't speak for the overall design, but the above should help a bit with the TLS side of things.

[#3]

Hi @bgooley,

Thank you for your answer.

Yes sorry, each time I mean Certificate Authority (CA).
Ok then I will see what will be the best for us between our own CA or a public CA. And I will learn more about how to create and maintain a CA with your link.

In fact our IT admins will be the only clients on CM and HUE. Our production cluster (private cloud) will generate outputs to another webportal service (public cloud) where there will be the final users.

If I may ask, I have a last question to be sure:
1) Public CA won't work for host with private IP (private cloud) right ?

Thank you in advance,

Vincent

[#4]

@vincenth,

A public CA can sign certificates that for "private" hosts.  Usually, you would generate a CSR (Certificate Signing Request) and then submit that on the CA's website.

Different CAs have different licenses, deals, etc.

[#5]

Hello @bgooley ,
Thank you very much for your answers