This document describes how to generate Certificate Signing Request (CSR) and upload signed certificates to Cisco Meeting Server (CMS).
Cisco recommends that you have knowledge of these topics:
Basic knowledge of CMS Server
Putty or similar software
CMS 2.9 or later
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. 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.
Generate the CSR
There are two ways you can generate CSR, one of those is to generate the CSR directly on the CMS server from Command Line Interface (CLI) with admin access, the other is to do it with external 3rd party Certificate Authority (CA) such as Open SSL.
In both cases, the CSR has to be generated with the correct syntax for CMS services to work properly.
<key/cert basename> is a string that identifies the new key and CSR name. It can contain alphanumeric, hyphen or underscore characters. This is a mandatory field.
<CN:value> is the Common Name. This is the Fully Qualified Domain Name (FQDN) that specifies the server’s exact location in the Domain Name System (DNS). This is a mandatory field.
[OU:<value>] is the Organizational Unit or Department Name. For example, Support, IT, Engineer, Finance. This is an optional field.
[O:<value>] is the Organization or Business name. Usually the legally incorporated name of a company. This is an optional field.
[ST:<value>] is the Province, Region, County or State. For example, Buckinghamshire California. This is an optional field.
[C:<value>] is the Country. The two-letter International Organization for Standardization (ISO) code for the country where your organization is located. For example, US, GB, FR. This is an optional field.
[subjectAltName:<value>] is the Subject Alternative Name (SAN). From X509 Version 3 (RFC 2459), Secure Socket Layers (SSL) certificates are allowed to specify multiple names that the certificate must match. This field enables the generated certificate to cover multiple domains. It can contain IP addresses, domain names, email addresses, regular DNS hostnames, etc, separated by commas. If it is specified, you must also include the CN in this list. Although this is an optional field, the SAN field must be completed in order for Extensible Messaging and Presence Protocol (XMPP) clients to accept a certificate, otherwise the XMPP clients display a certificate error.
Step 2. Generate callbridge, xmpp, webadmin and webbridge CSR.
Access the CMS CLI with Putty and Log in with the admin account.
Run the next commands in order to create CSR for every service needed on CMS. *It is also acceptable to create a single cert that has a wild card (*.company.com) or has the cluster FQDN as CN, FQDNs of each CMS server and join URL if necessary.
In order to apply certificates to the Database or replace expired certificates on the existing DB cluster, run the next commands:
database cluster remove (on all servers, noting who was master before beginning)
database cluster certs <server_key> <server_certificate> <client_key> <client_certificate> <Root ca_crt> database cluster initialize (only on Master node) database cluster join <FQDN or IP of Master> (only on slave node) database cluster connect <FQDN or IP of Master> (only on nodes that are not part of the database cluster)
In order to apply certificates to TURN, run the next commands:
Since CMS 3.0, you are required to use Certificate trust chains or full chain trusts. Also, it is important for any service that you recognize how certs are to be built when making bundles.
When constructing a certificate trust chain, as required for Webbridge 3, you must build it like the image below, with entity cert on top, and intermediates in the middle, and root CA at the bottom, followed by a SINGLE CARRIAGE RETURN:
Anytime that you are creating a bundle, the certificate MUST have a single carriage return at the end. Just one.
CA bundles would be the same as the image above, only, of course, there would be no entity certificate.
If you need to replace an expired certificate for all services, excluding 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 a customer performs 'pki csr <certname>... ' and that cert name matches an existing key, it will immediately break the existing service. If the production is live, and you are proactively creating a new CSR and Key, use a new name. You can rename to the currently active name before uploading the new cert to the servers.
If the database certificates have expired, you should check with 'database cluster status' who the database master is, and on all nodes, run the command 'database cluster remove'. Then you can follow the instructions from the above, Step 3. Generate the Database cluster CSR and use built in CA to sign them, beginning on step 3.