Certificates Overview

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the ownership of a public key. The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of an entity that has verified the certificate’s contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate’s subject.
In a typical public-key infrastructure (PKI) scheme, the certificate issuer is a certificate authority (CA), usually a company that charges customers to issue certificates for them.

In TLS (an updated replacement for SSL), a server is required to present a certificate as part of the initial connection setup. A client connecting to that server will perform the certification path validation algorithm:

The subject of the certificate matches the hostname (i.e. domain name) to which the client is trying to connect;
The certificate is signed by a trusted certificate authority (CA).

(Taken from Wikipedia)

Cluster certificates setup

The Conductor Manager cluster uses the TLS protocol (as described above) for:

Communication between the PostgreSQL cluster nodes.
Communication between the RabbitMQ cluster nodes.
Communication between the Studio Conductor Management service cluster nodes and the other services.

A few notes:

The certificates/keys should be created before proceeding with the installation process and in a PEM format.
The certificates/keys are copied to /etc/cloudify/ssl during installation from the source given by the user. Therefore, it is up to the user to delete the leftovers from the source location.
In case of using externally hosted PostgreSQL or RabbitMQ instances, the CA needs to be retrieved from the cloud service hosting the instance.
The same CA should be used to sign all cluster hosts’ certificates.

The following files should exist on each host:

CA certificate - The CA certificate that signed the hosts’ public key certificates.
Public key certificate - A public key certificate signed by the given CA that specifies the host IP and username.
Private key - The private key associated with the host’s public key certificate.

The cfy_manager generate-test-cert command can be used for creating example certificates:

On a host that has Studio Conductor installed, generate certificates for all hosts using:

For a nine nodes cluster:

cfy_manager generate-test-cert -s <manager-1-fqdn>,<manager-1-private-ip>,<manager-1-public-ip>
cfy_manager generate-test-cert -s <manager-2-fqdn>,<manager-2-private-ip>,<manager-2-public-ip>
cfy_manager generate-test-cert -s <manager-3-fqdn>,<manager-3-private-ip>,<manager-3-public-ip>
cfy_manager generate-test-cert -s <broker-1-fqdn>,<broker-1-private-ip>,<broker-1-public-ip>
cfy_manager generate-test-cert -s <broker-2-fqdn>,<broker-2-private-ip>,<broker-2-public-ip>
cfy_manager generate-test-cert -s <broker-3-fqdn>,<broker-3-private-ip>,<broker-3-public-ip>
cfy_manager generate-test-cert -s <db-1-fqdn>,<db-1-private-ip>,<db-1-public-ip>
cfy_manager generate-test-cert -s <db-2-fqdn>,<db-2-private-ip>,<db-2-public-ip>
cfy_manager generate-test-cert -s <db-3-fqdn>,<db-3-private-ip>,<db-3-public-ip>

For a three nodes cluster:

cfy_manager generate-test-cert -s <node-1-fqdn>,<node-1-private-ip>,<node-1-public-ip>
cfy_manager generate-test-cert -s <node-2-fqdn>,<node-2-private-ip>,<node-2-public-ip>
cfy_manager generate-test-cert -s <node-3-fqdn>,<node-3-private-ip>,<node-3-public-ip>

For an AIO node:

cfy_manager generate-test-cert -s <node-1-fqdn>,<node-1-private-ip>,<node-1-public-ip>

The commands above should be run on the same host. For production purposes, please use a proper CA (e.g. a company CA).

All-in-one Certificates Setup

For an all-in-one Conductor Manager, just the host’s public key certificate is needed alongside its associated CA certificate and private key.

Replacing certificates

Replacement of the certificates may be required as a result of regulatory compliance demand, certificate expiration, or revocation due to security breach. Follow the procedure described in the Replacing Certificates guide when certificates’ replacement is required.