Implementing Different Certificates for each service On Cisco CMS

[Meddane]

When integrating Cisco Meeting Server, we can use a single Multi-SAN certificate where the same certificate can be deployed on multiple servers and multiple services. OR different certificates where each service requires its own certificate, for WebAdmin, WebBridge, CallBridge and Database services.

This article shows how to use different certificates for each service CallBridge, WebBridge and Scheduler and using multiple CA Server to sign different certificates.

The CallBridge, Scheduler and WebBridge services are running in the same node.

1. The CallBridge service should use the CA-1 Server to sign the CallBridge certificate called CALLBRIDGE.cer.
2. The WebBridge service should use the CA-2 Server to sign the WebBridge certificate called WEBBRIDGE.cer.
3. The CallBridge must use the subordinate CA generated from CA-1 Server.
4. The WebBridge must use the subordinate CA generated from CA-2 Server.
5. Create a Bundle CA Called CB-Bundle.cer for CallBridge service using the Subordinate CA and Root certificate of CA-1 server.
6. Create a Bundle CA called WB-C2W-Bundle.cer for WebBridge service using the Subordinate CA and Root certificate of CA-2 server.
7. Create a chain certificate called WEBBRIDGE-CHAIN.cer for WebBridge3 using the previous subordinate CA, the Root certificate of CA-2 server and the WebBridge certificate.
8. Make sure that the CallBridge service will trust only the WebBridge certificate chain signed by only the certificate WB-C2W-Bundle.cer.
9. Make sure that the WebBridge service will trust only the CallBridge's certificate signed by only the CB-Bundle.cer certificate. 
10. Enable the Scheduler, Since the Scheduler is required to run on a server which also has a colocated Callbridge, it is possible to use the Callbridge certificate and C2W trust cert for the Scheduler service, but a chain certificate is required for Scheduler, therefore bundle the certificates CALLBRIDGE.cer and CB-Bundle.cer used previously for CallBridge to create chain certificate SCHEDULER-CHAIN.cer.

 Create a CSR named CALLBRIDGE for the CallBridge.

Create a CSR named WEBBRIDGE for the WebBridge.

Generate a CSR named SuborCB for a Subordinate CA of the CA Server lab.local.

Generate a CSR named SuborWB for a Subordinate CA of the CA Server collab.com.

From the CA Server lab.local. Submit the CSRs named SuborCB and CALLBRIDGE to generate the certificates, use the Certificate Template Subordinate Certificate Authority, and Client and Server Authentication CMS respectively.

Save the certificates with the name Subordinate-CB.cer and CALLBRIDGE.cer respectively.

From the CA Server collab.com. Submit the CSRs named SuborWB and WEBBRIDGE to generate the certificates, use the Certificate Template Subordinate Certificate Authority, and Client and Server Authentication CMS respectively.

Save the certificates with the name Subordinate-WB.cer and WEBBRIDGE.cer respectively.

Download the Root Certificates of lab.local and collab.com.

Create a bundle CA for CallBridge.

Use a plain text editor such as notepad. Past the SuborCB.cer certificate first and then past the CA-lab.local.cer certificate at the end, save the file with .cer extension. Name it CB-Bundle.cer.

Create a bundle CA for WebBridge.

Use a plain text editor such as notepad. Past the SuborWB.cer certificate first and then past the CA-collab.com.cer certificate at the end, save the file with .cer extension. Name it WB-C2W-Bundle.cer.

A chain certificate is required for Webbridge3 in version 3.

Edit the certificate named WEBBRIDGE.cer created previously with nodepad.

Edit the WB-C2W-Bundle.cer certificate created previously with nodepad.

Past the WEBBRIDGE.cer certificate first and then past the WB-C2W-Bundle.cer certificate at the end, save the file with .cer extension. Name it WEBBRIDGE-CHAIN.cer.

Copy the certificates CALLBRIDGE.cer, WEBBRIDGE.cer, CB-Bundle, WB-C2W-Bundle.cer and WEBBRIDGE-CHAIN.cer to CMS1 using WinSCP.

Use the pki list command to verify that the certificates are present.

Configure the CallBridge service to listen on the interface a, specify the certificate CALLBRIDGE.cer with the relevant key, restart the callbridge.

Enable the webbridge3 service and c2w connection between the webbridge and callbridge. Use the WEBBRIDGE-CHAIN.cer with the relevant key.

Certificate pinning is introduced on cisco meeting server starting in CMS 3.0 to help prevent man in the middle attack.

But what is the Certificate Pinning?

Traditionally, SSL Handshake consists on the validation of the server's certificate, let's say collab.com. The validation is done using the CA's certificate located in the certificate store of the web browser.

The certificate store contains several CA Certificates, may be more than 100.

If at least one CA delivers by mistake or more likely to conduct an attack a valid certificate for example *.collab.com, attackers are able to launch a Man In The Middle Attack.

in order to prevent this attack, it is possible to use the SSL protocol in another way, by creating an association between the domain name of a site (www.collab.com) and the certificate or certification authority expected. Thus, only the a certificate (of collab.com) signed by one of the specific certification authorities will be accepted and if the certificate of collab.com signed by another CA is presented, it is not trusted.

Certificate pinning can be explained with a simple words: Is this connection secure with a valid certificate and is it signed by the CA I’m expecting?

For Cisco Meeting Server, the C2W connection between the WebBridge and CallBridge uses the concept of certificate pinning to prevent the Man In the Middle Attack.

This is done by the webbridge3 c2W trust < Call Bridge Trust certificate Chain > and callbridge trust c2W < Web Bridge Trust certificate Chain > command.

The webbridge will trust certificates of callbridges that have been signed by one of those in its trust store, set by the < webbridge3 c2W trust < Call Bridge Trust certificate Chain > command.

The callbridge will trust webbridges that have certificates signed by one of those in its trust store, set by the < callbridge trust c2W < Web Bridge Trust certificate Chain > command.

In this scenario two differents CA are used to sign :

1. The WebBridge certificate chain WEBBRIDGE-CHAIN.cer is signed by CA-collab.com server.
2. The CallBridge certificate CALLBRIDGE.cer is signed by the CA-lab.local server.

Basically:

You tell the CallBridge service ----> trust only the WebBridge's certificate WEBBRIDGE-CHAIN.cer signed by the certificate WB-C2W-Bundle.cer. It's enforced with the callbridge trust c2w WB-C2W-Bundle.cer command.

You tell the WebBridge service ----> trust only the CallBridge's certificate CALLBRIDGE.cer signed by the certificate CB-Bundle.cer. It's enforced with the webbridge3 c2w trust CB-Bundle.cer command.

Now, on cms1 GUI navigate to Configuration > API.

In the Filter section, type “webbridges”. Click Create New.  Populate the url field with the following: url: c2w://webbridge.collab.com:9999, then click Create.

Click the Status in the WebBridge configuration, you should see the status Success.

 From Jdoe-PC, open the Web Browser, type the guest URL https://join.collab.com to access a meeting.

Enable the Scheduler, each scheduler needs to be able to connect to each Web Bridge in a cluster, the scheduler requires configuration of a client certificate and key to be used for this connection, since the Scheduler is required to run on a server which also has a colocated Callbridge, it is possible to use the Callbridge certificate and C2W trust cert for the Scheduler service.

A chain certificate is required for Scheduler when establishing a secure connection to Webbridge servers, therefore, bundle the certificates CALLBRIDGE.cer and CB-Bundle.cer used previously for CallBridge to create chain certificate SCHEDULER-CHAIN.cer and copy the certificates into CMS using SFTP.

Configure the scheduler:

• Configure a certificate key pair for C2W, use the SCHEDULER-CHAIN.cer certificate created previously using a bungle of the CB-Bundle.cer and CALLBRIDGE.cer certificates.
• Configure the scheduler to be able to trust each Web Bridge it connects to. Use the WEBBRIDGE-CHAIN.cer certificate the WebBridge offers.
• Configure the HTTPS server listen interface.
• Configure a certificate key pair for HTTPS, use the SCHEDULER-CHAIN.cer certificate created previously using a bungle of the CB-Bundle.cer and CALLBRIDGE.cer certificates.

Verify the scheduler configuration.

Verify the scheduler status, you should see the status of the C2W connection is UP and the WebBridge CONNECTED.

The syslog follow command from the CLI shown that a list of configured Web Bridges is retrieved by the scheduler and C2W connections are established to each Web Bridge similar to how the Call Bridge also establishes a C2W connection to each Web Bridge.

From Jdoe-PC, open the Web Browser, type the guest URL https://join.collab.com to access a meeting. Login with the username jdoe@lab.local, you should see the Option Schedule Meeting displayed.