CMS requires encrypted communications between various components and as a result, X.509 certificates are required for all CMS deployments. They help ensure that a service/server can be trusted by other devices/services.
There are three types of certificates to consider: self-signed, private certificate authority (CA)-signed, and public CA-signed.
Although every service requires a certificate, creating individual certificates for each service can add unnecessary complexity. Fortunately, you can generate a certificate public and private key pair, then re-use it for multiple services. In this lab you will obtain a single certificate for Call Bridge, XMPP server, Web Bridge, and Web Admin. With some additional considerations taken into account in advance, this certificate will also be able to integrate with on-premise Microsoft Lync / Skype for Business.
Database clustering has some special certificate requirements described later and therefore each database cluster member requires both a database server and database client certificate. These are almost always signed by the same, private CA.
For all CA-signed certificates (both public and private), the general process is as follows:
Once uploaded to the CMS servers, the certificates are available for use. The certificates just need to be assigned to the components that require them. You will do this step as you go through and configure the individual services.
This section will walk you through generating a Certificate Signing Request, getting it signed, and installing the certificates. As mentioned earlier, you will be using a single certificate for Call Bridge, XMPP server, Web Bridge, and Web Admin. You will then generate separate certificates for the database.
The document Certificate Guidelines for Scalable and Resilient Deployments goes into detail on all the certificate requirements for a CMS deployment. We highly recommended you read through this document before you do a production deployment of CMS. This lab follows the guidelines from this document. These are the requirements for the combined non-database certificates:
The pki csr command has the following syntax:
The key/cert_basename is just the file name that will be used for the key and certificate files. Different file extensions will be appended to this base name depending on the type of file. It can be anything (as long as there aren't any special characters), but it's usually best to give it a name that reflects the server/service that you're generating the certificate for, like servername or servername-service. There are many other optional parameters: O: for Organization, L: for location, and so on. None of these are mandatory, especially for a private CA-signed certificate.
Use these links to connect to your CMS servers:
|Cisco Meeting Server Name||Password|
You will start with the combined certificate on:
This exact same procedure was already done on cms1b and cms1c. Only the server name in the subjectAltName field is different and, of course, the file name, to make it easier to keep track.
Before downloading the CSR via SFTP, follow the next set of steps to generate the CSRs for the database components.
CMS uses a postgres database with a single master and multiple, fully-meshed replicas. There is only a single master database at a time (the “database server”). The remaining cluster members are replicas or “database clients”.
For redundancy to work, database clusters must consist of at least 3 servers but no more than 5, with a maximum round-trip time of 200ms between any cluster members. This limit is more restrictive than Call Bridge clustering, so it is often the limiting factor in geographically dispersed deployments.
The database role for CMS has some unique requirements. Unlike other roles, it requires a client and server certificate, where the client certificate has a specific CN field that is presented to the server.
For the database cluster, a dedicated server certificate and client certificate are required. These must be signed certificates, typically by an internal private CA. Because any of the database cluster members may become the master, the database server and client certificate pairs (containing the public and private keys) must be copied to all of the servers so they can assume the identity of a database client or server. Additionally, the CA’s root certificate must be loaded to ensure that the client and server certificates can be validated.
Like before, use the pki csr command to generate the CSR. Connect to cms1a and issue the command below.
|Cisco Meeting Server Name||Password|
These steps have already been performed on cms1b and cms1c.
Next, create the database client certificate. This one is unique in that it requires setting CN:postgres. No other fields, such as the machine FQDN or other information, is required.
Again, these steps have already been performed on cms1b and cms1c.
Now that you have created all the necessary certificate requests, you can download them.
You will need download the key files and the signing requests using the PC1 Remote Desktop session. The reason for this is that this machine is part of the Windows Domain, allowing you to easily use the command-line interface to sign the certificates. Depending on your Certificate Authority, the process for getting the certificates signed will be different. But in all cases, the files must be downloaded first and CSRs signed.
Using username "admin". Using keyboard-interactive authentication. Please enter password: Connected to cms1a.pod2.cms.lab. Remote working directory is / psftp> remote:/cms1a.csr => local:cms1a.csr psftp> remote:/dbclusterserver.csr => local:dbclusterserver.csr psftp> remote:/dbclusterclient.csr => local:dbclusterclient.csr psftp>
OR to enter all commands at once, click below:
psftp email@example.com c1sco123 get cms1a.csr get dbclusterserver.csr get dbclusterclient.csr exit
You now have 3 CSRs that need to be signed: cms1a.csr, dbclusterserver.csr, and dbclusterclient.csr. We have provided an internal Microsoft Certificate Authority to sign these requests. Follow the instructions below to upload the requests to the CA.
Now you should have 3 certificates in your Certificates folder: cms1a.cer, dbclusterserver.cer, and dbclusterclient.cer. You can check this with thecommand on PC1.
Since all of the certificates are trusted by the same Certificate Authority, in many instances you will need to supply the CA's certificate as well. This is another file that can very easily be downloaded from the Certificate Authority that will be used to sign all of our certificate requests.
This will download the root CA file in base-64 encoding to your Certificates folder on PC1 and name the file cmslab-root-ca.cer.
Some services, such as the XMPP clustering server, require a trust bundle to identify all certificates of clients that it will accept, as a form of authentication. To create such a bundle, you must create a file that contains all three server certificates (from cms1a, cms1b, and cms1c) in a single file.
For this lab, the server certificates for cms1b and cms1c have already been already created for you. You just need to download them by following these steps:
Finally, you need to upload the appropriate files back onto the CMS servers. Each server will get its own certificate, the certificate bundle containing all three server certificates, and the certificates for the database server and client including the private keys. Because the database CSRs were generated on cms1a, that server already has those private keys, so you do not have to re-upload them.
To upload the files back to the CMS servers use SFTP and the psftp client on PC1 as follows.
Using username "admin". Using keyboard-interactive authentication. Please enter password: Connected to cms1a.pod2.cms.lab. Remote working directory is / psftp> local:/cms1a.cer => remote:cms1a.cer psftp> local:/dbclusterserver.cer => remote:dbclusterserver.cer psftp> local:/dbclusterclient.cer => remote:dbclusterclient.cer psftp> local:/cms1abc.cer => remote:cms1abc.cer psftp> local:/cmslab-root-ca.cer => remote:cmslab-root-ca.cer psftp>
OR to enter all commands at once:
psftp firstname.lastname@example.org c1sco123 put cms1a.cer put dbclusterserver.cer put dbclusterclient.cer put cms1abc.cer put cmslab-root-ca.cer exit
You won't need to use PC1 again until later in the lab when you will need to use it as a client for placing test calls.
|Cisco Meeting Server Name||Password|
To make sure the certificates were uploaded correctly, you can ssh to CMS and use the pki list command which will give a list of the file names (The ones in bold are the the ones that will be required for proper operation. The .csr files are no longer needed.) Take a look at CMS1a:
CMS1b and CMS1c will have the exact same certificate files except that they will have cms1b.key/cms1b.cer or cms1c.key/cms1c.cer instead of cms1a.key/cms1a.cer.
This simply verifies that the files are actually there, it does not check the contents in any way. CMS does provide the pki inspect command to dump the contents of a file, which is useful for checking things like the expiration date or subjectAltName fields present, as well as the pki verify command to verify the certificate is signed by the CA and that the certificate bundle can be used to assert this.
Feel free to test this, for example, on cms1a, you could issue the command:
If this succeeds, you know that the certificate you generated is signed by our CA certificate and is in fact correctly represented in the CA bundle.
It is also possible to verify that a certificate matches a given private key with the pki match command: