Cisco cms files

CMS uses a postgres database with a single master and multiple, fully-meshed replicas. 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 ms 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. Like before, use the pki csr command to generate the CSR.

Connect to cms1a and issue the command below. 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. 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. You now have 3 CSRs that need to be signed: cms1a. 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.

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 encoding to your Certificates folder on PC1 and name the file cmslab-root-ca. 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. All of the devices used in this document started with a cleared default configuration. If your network is live, ensure that you understand the potential impact of any command. Since CMS 2.

Since CMS 3. Also, it is important for any service that you recognize how certs are to be built when you make bundles. When you build a certificate trust chain, as required for Web bridge 3, you must build it as shown in the image, with entity cert on top, and intermediates in the middle, and root CA at the bottom, then a single carriage return. Anytime that you create a bundle, the certificate must have a single carriage return at the end. Just one. CA bundles would be the same as shown in the image, only, of course, there would be no entity certificate.

If you need to replace an expired certificate for all services, except database certificates, the easiest method is to upload new certs with the SAME name as the old certificates. If you do this, the service just needs to be restarted, and you do not need to reconfigure the service.

If you perform 'pki csr If the production is live, and you proactively create a new CSR and Key, use a new name. You can rename the currently active name before upload the new cert to the servers. Configure Step 1. Verify the CMS license status. In a brand new CMS server you can see the warning message This CMS is currently unlicensed when a local license has not been installed yet, as shown in the image: Step 2.

Generate a license. You get a zip file via email as shown in the image: Step 3. Upload the license file to CMS. Download the zip file, unzip it and rename it as cms. Step 4. Otherwise the licensing warning remains and call bridge service cannot be activate. Navigate to Servers and select Add Call Bridge. As shown in the image: A new pop-up window is displayed.