Well, I was just enquiring about the same a few minutes back. It depends on the requirement if you want to enable ssl for all Web UIs, all services and also if you need wire encryption. Depending on that you can use following strategies. The set of certificates required depends upon the certificate provisioning strategy you implement. The following strategies, among others, are possible:
Certificate per host: In this strategy, you obtain one certificate for each host on which at least one SSL daemon role is running. All services on a given host will share this single certificate. Certificate for multiple hosts: Using the SubjectAltName extension, it is possible to obtain a certificate that is bound to a list of specific DNS names. One such certificate could be used to protect all hosts in the cluster, or some subset of the cluster hosts. The advantage of this approach over a wildcard certificate is that it allows you to limit the scope of the certificate to a specific set of hosts. The disadvantage is that it requires you to update and re-deploy the certificate whenever a host is added or removed from the cluster. Wildcard certificate: You may also choose to obtain a single wildcard certificate to be shared by all services on all hosts in the cluster. This strategy requires that all hosts belong to the same domain. For example, if the hosts in the cluster have DNS names node1.example.com ... node100.example.com, you can obtain a certificate for *.example.com. Note that only one level of wildcarding is allowed; a certificate bound to *.example.com will not work for a daemon running on node1.subdomain.example.com. Given above strategies, I would recommend having one certificate per host wherever you have any ssl daemon running i.e. if HDFS and YARN are on same host. Both would use the same. We have been mostly using this. Reference: http://www.cloudera.com/content/www/en-us/document...
... View more
