Cisco WebEx Meeting Server (CWMS) is Cisco’s on premise web conferencing platform and evolved from our SaaS based Cloud service, which has a similar look and feel. Architecturally, CWMS has a number of components that sit behind an organisation’s firewall, which perform administrative, management and conferencing functions. Depending on the system sizing and redundancy design, these reside on one or more Virtual Machines (VMs). The system also has an Internet Reverse Proxy (IRP) capability that normally sits in the DMZ; like the internal CWMS elements the IRP function will be comprised of one or more VMs.
To facilitate authentication and encryption of the various platform services CWMS will install with a self-signed SSL certificate. In today’s security conscious world the best practice recommendation is to always use an Enterprise or Public CA signed certificate and this of course also applies to the WebEx Meetings Server. I think it’s truthful to say that the guidance on how to create a CWMS SSL certificate has historically been a bit hazy, so I’ve written this blog to help you craft a valid SSL certificate for single and dual datacentre deployments. To get started let’s take a look at an example CWMS deployment for a company with a domain called acme.com.
Before CWMS 2.5 MR5:
Figure 1 – Example CWMS Deployment
Each of the VMs that make up the CWMS deployment has a Fully Qualified Domain Name (FQDN) and there are also URLs that provide web access to the Administration pages and Conferencing service. For example, in the drawing above the FQDN for the two CWMS servers in the internal network are dc1-cwms-pri.acme.com and dc1-cwms-ha.acme.com. The system URLs (that map to Virtual IP (VIP) addresses) are https:\\conf-dc1.acme.com and https:\\conf-dc1-admin.acme.com and these point to the web meetings service and web administration service respectively. The IRP VMs will also have FQDNs, but as we’ll discuss further a little later on these are not relevant with respect to the SSL certificate creation.
The two types of generic certificates supported by CWMS are wildcard and multi-server. Wildcards provide the flexibility to simplify the certificate configuration, as long as all the system elements reside in the same domain, down to a single entry in the Common Name (CN) field (e.g. *.acme.com). Although in my experience most Enterprise security teams I’ve encountered would not normally countenance the deployment of wildcards. The preferred option is to go with a multi-server certificate approach, so let’s see how we tackle this.
From a CWMS perspective the first thing we do is to choose whether we will use an Enterprise or Public CA to sign the system’s SSL certificate. If no one outside your organization will ever use the platform then you can use, if you have one, your Enterprise CA to sign the certificate. As long as the root certificates (for your CA hierarchy) are in the trusted root stores of your conferencing clients everything will work well. However, if you want to invite people from outside your company to join conferences, the advice is to use a Public CA to sign the SSL certificate. This avoids those nasty browser security warnings that your external guests will hate. Once we have chosen who will sign the certificate the next thing we need to determine is what we put into the CN and Subject Alternate Name (SAN) fields. The best way to do this is to use a couple of examples. Let’s start by looking at a single datacentre deployment that has redundant CWMS and IRP VMs.
Figure 2 – Single Datacentre Certificate Example
Once you have examples of the CN and SAN entries it is quite easy to determine how to create the Certificate Signing Request (CSR). You use the main service URL for the CN and the SAN field is made up of the FQDN of all the internal VMs and both the service and admin URLs. The notable exception is the absence of the IRP FQDNs. This is because these servers will never been accessed directly via their FQDN.
Since the release of CWMS 2.5 we’ve had the ability to deploy a redundant dual data centre configuration, so let’s look at how this affects the SSL certificate. The answer actually turns out to be quite straight forward. We just double up on certificates!
Figure 3 – Dual Datacentre Certificate Example
If you have read the literature on the redundant datacentre model then you will know that we use Common URLs to globally identify the admin and conference URLs, with each datacentre still retaining locally significant URLs. To create each datacentre’s SSL certificate we can legally use the global conferencing URL in the CN and then add the datacentre specific FQDNs and URLs (including the global ones) into the SAN field. Remember that we don’t add the IRP’s FQDNs. For the acme.com example this will give us the SSL certificate format shown above. Are we finished? Well not quite.
As I stated above we can legally use the global conferencing URL in each datacentre’s certificate CN, which I’ve seen deployed, but this is not actually best practice when we want to also secure the audio conferencing function using encryption.
Figure 4 – CN Requirement for Secure Audio Conferencing
In the case where we plan to secure audio conferencing we cannot use the global conferencing URL as the CN entry for both datacentre certificates. The reason for this is that CUCM treats certificates with the same CN as the same certificate and will overwrite the first uploaded certificate with the second one, so you will never be able to create a secure TLS trunk with the datacentre whose certificate you uploaded first. For this reason and to ensure you have complete flexibility on how you can trunk to your CUCM deployment, you should use the locally significant conferencing URL in the CN of each datacentre’s SSL certificate.
One of the common questions I’ve received is can we use a single SSL certificate for both datacentres? The short answer is no. The current CWMS administrative interface does not allow you to create a single certificate, and if you think about it having two separate certificates is a good thing from an operational perspective. Two certificates enable you to make changes to the certificate of one datacentre without disruption to the operations of the other one.
I’ve not gone into the detail of how to generate the Certificate Signing Request, but once you understand what elements of the system need to be included in the CN and SAN fields you can use the CWMS manual to guide you through the GUI CSR process. Hint: To make life easier the GUI actually pre-populates the SAN entries for you.
From CWMS 2.5 MR5:
In MR5 the SSL certification has been split into two. We now have a separate SSL certificate for the web conferencing service and an internal SSL certificate for the other components of the system. This allows us to use a Public CA for the web conferencing URL and either a self-signed or Enterprise CA signed certificate for the other elements. This change increases overall security of the system as it means none of the system’s FQDNs or its admin URL needs to be exposed outside of the organization. It also allows internal domain names, such as “.local”, to be used without causing issues when using a Public CA.
Figure 5 – Single Datacentre Split SSL Certificate Example
In the diagram above I’ve shown the resulting CWMS 2.5 MR5 certificates for a single DC deployment. A point to note is that the CN for the internal system SSL cert will now be the local admin URL, whereas in previous versions the system used the conferencing URL.
When we apply the changes introduced in MR5 to the dual datacentre deployment model we now end up with four SSL certificates. Two internal and two used for the conferencing URL. I’ve shown a representation of this for acme.com below:
Figure 6 – Dual Datacentre Split SSL Certificate Example
To guarantee we can always support encrypted audio conferencing with CUCM we ensure that the CN of each datacentre’s Internal System SSL certificate is different. In the example above it is conf-dc1-admin.acme.com and conf-dc2-admin.acme.com for dc1 and dc2 respectively.
Using the above guidance for pre and post CWMS2.5 MR5 dpeloyments you should now be able to create the necessary SSL certificates for the system. My advice would be to double check the release notes of any subsequent versions of CWMS to ensure no additional SSL certificate related enhancements have been made since this blog was created. However, once you’ve digested the contents of this document, understanding future incremental changes should be much easier.
