Overview
The following diagram shows how the various files involved in TLS/SSL are created and installed, and the relationships between them:
Organization
Each server has a directory :
...
You will see that there is a certificate ca.masterhost which is the CA cert for the cluster.
How keys are installed on the primary (master) server
When you do an install, SSL Keys are generated by :
...
A given server will only use the information present in etc/ssl/. The Staging area is never consulted except for adding and removing certificates.
HA Install
When an HA install is under way, the secondary server contacts sipxconfig. sipXconfig calls the following script:
...
This invokes gen-ssl-keys.sh and install-ssl-keys.sh passing the secondaryServerHostName as argument.
You will notice that as nodes are added to the cluster, the
var/sipdata/certdb/authorities.jks file is augmented with the public
keys (certificates) of the new servers added. As before, a format conversion to DER format is done before
adding the certificate to the java trust store. Each host has a Java keystore alias of its own host name.
You can re-run sipxecs-setup as many times as you wish on any server. However, if you run it on the master
server, note that a new CA certificate will be generated and hence you will need to run it on all the
other servers of the cluster.
Each host also has the common CA certificate for the cluster. XML RPC certificates are signed with the
key of the common XML RPC CA. Thus any host can talk to any other host
in the cluster using XMLRPC over SSL. The certificate for the server it is trying
to contact is shipped to it via SSL handshake and is verified upon receipt to
ensure it has been signed by the common CA key given that the CA certificate is available to the client.
This is part of standard SSL handshake.
The tar file that is generated by the install script contains the
authorities.jks database and the private xml rpc key for the specific
server to which that tar file is headed. It does not contain the private keys of any other server
in the cluster. It is untarred upon arrival and the secondary server is good to go at this point.
The SSL handshake takes care of
Web Keys
Starting with sipxecs 4.0 the web and xml RPC certificates are distinct. For the initial install they start out being the same but subsequently, a new web certificate may be installed. The CA certificate of the web certificate is not assumed to be available at the time the web cert is installed. Hence the web cert is not verified prior to installation. A web cert is identified by a hostname-web.p12. The CA cert should be available to the web server for verification of the SSL Cert that is shipped to it. Wildcard hostname certificates are not supported - see XX-5949
Important : The information here pertains to all version 3.11.12. 3.10 did things differently.