CWMS Self Signed Certificate

[Tarik Admani]

Hi,

I am helping a colleague of mine address a certificate question he is facing from the security department around their concerns on generating a certificate requested to be signed, The client is currently running on version 1.5.1.223a.

The concern the customer has is that they do not want any of their internal names/servers to be part of the SAN fields for the public facing cert...for example:

meet.example.com is the name of the public facing cert that clients use to connect externally for meetings, after looking at the default certificate it seems as if the entire deployment SANs are part of this certificate. I wanted to know when I have a certificate signed for this node and choose to use a certificate for only "meet.example.com" that I should be covered and I am not going to break the administration connection to this node.

Thanks,

Tarik Admani
*Please rate helpful posts*       

[Terry Cheema]

Tarik - if you move your query to conferencing section, you will get more feedback on this. CWMS is generally discussed there and Dejan, Arun, Derek are Cisco guys along with others who are very quick to respond generally.

-Terry

Sent from Cisco Technical Support iPhone App

[Tarik Admani]

Thanks Terry, I will get it moved.

Thanks

Tarik Admani
*Please rate helpful posts*

[Tarik Admani]

I wanted to know if anyone has run into this issue before. I do not think each of the boxes need the hostname of each other.


Sent from Cisco Technical Support Android App

[dpetrovi · Accepted solution]

Hi Tarik,

As you might know, CWMS support the use of either Wildcard or SAN certificates. Wildcard certs are more commonly used if the domain of the internal and external components is the same (e.g. *.cisco.com). If that is not the case, and you use different domains for public facing components and for internally facing components, you have to use the SAN certificate.

Since all the components are managed by Admin VM and all the administration is done on Admin VM, only a single cert is being used and is distributed by Admin VM to all other components. Hence, the use of SAN certificates. By design, SAN certificate includes all Subject Alternative Names (and in CWMS that is the list of FQDNs of all the components in the solution).

With that in mind, it is not possible to hide FQDN of the internal components included in the SAN certificate.

Here is a little bit more info about Wildcard and SAN certificates and their usage:

Wildcard Certificates

Wildcard certificates are widely used to secure multiple subdomains under a single unique fully qualified domain names. The benefit with this certificate is that that it not only makes it simple to manage the certificate, but it also helps you in lowering your administrative costs. It provides immediate protection to your current and future subdomains.

• Wildcard certificates help you in managing the certificate easily because one certificate is enough for all present and future subdomains. This in turn also reduces your administrative cost as you do not have to buy new SSL certificates often.  
• Wildcard certificates are no different than the normal SSL certificates, which support the wildcard character ‘*’ added as a prefix to the fully qualified domain names. This is how it is enabled to secure multiple services. With wildcard certificates there are no specific service names involved, instead they always contain a wildcard character as a prefix to the domain name.
• It is always advisable and preferable to use wildcard certificate, which is so much more flexible than that single purpose certificate and it can be applied to a number of different services. Moreover, you can even make changes like adding or replacing the services without updating or buying a new certificate.
• Take an example to understand how wildcard certificates work – for a domain name exmpl.com you buy a wildcard certificate, then that certificate will also work for exmple.com, xyz.exmpl.com and any other subdomain. Wildcard certificate refers to the fact that it is provisioned for *.exmpl.com

SAN Certificates

A SAN certificate is used to protect multiple domain names with a single certificate. They are different than wildcard certificates in a way that they can support an unlimited number of subdomains as long as the domain names are the same. SAN certificates only support the fully qualified domain names which are entered in the certificate. SAN certificates are impressive because they can support more than 100 different fully qualified domain names in a single certificate; this however, depends upon the issuing certificate authority.

• SAN certificates or Subject Alternate Name certificates are also known as Unified Communications Certificates as they are primarily structured to support real-time communications.
• SAN or UCC certificates are most useful to the businesses or organizations that are looking to use different root or domain names to perform internet facing services. For an example, if there is an organization which uses two domains, internal domain – abc.exmpl.net and external domain – abc.exmpl.com then only a SAN certificate will provide security to the unified communication of both these fully qualified domain names. While if the organization goes for a wildcard certification then it will need two wildcard certificates for .net and .com as they are two different domains.
• Application service providers (ASP), who host applications for different clients with each client using its own unique domain name, can benefit a lot by using SAN certificates. If ASPs use SAN certificates they can use a single certificate to provide security services to multiple clients. Here, it is important to note that the site seal and certificate provide security only to the primary domain names entered in the certificates and not to any other domain names. The certificate only includes the domain names which were verified at the time of purchase.

I hope this information will be helpful to you.

Thank you.

-Dejan

[ryan_oconnell]

Hello Dejan

My customer is using a SPLIT HORIZON install of CWMS 2.0. Given that the internal and external domain are the same .example.com and the Admin URL and internal meeting url are shared "wmsadmin.example.com" and "meeting.example.com" would the "Wildcard Certificate" be the best choice?

http://www.cisco.com/c/en/us/td/docs/collaboration/CWMS/2_0/Administration_Guide/Administration_Guide_chapter_01101.html#concept_71CACA22EBB84FE58867C71B177AD752

The URL above talks about the process. 

When I do this process and select Wildcard. I presume all i need to enter is *.example.com and generate the CERT Request. Then I get the Cert from a CA preferably one from a public CA that is already included on the trust lists for all devices such as Microsoft OS, Apple IOS, Android etc...

Given that the cert is for *.example.com this would cover requests internally and externally for url's wmsadmin.example.com and meeting.example.com

Are my assumputions correct?

[dpetrovi]

Hi Ryan,

Keep in mind that all the CWMS VM hostnames as well as WebEx Site and Admin Site URLs must belong to the same domain (e.g example.com) in order to use wildcard cert. If that condition is satisfied, then you should be good.

As for which one is better, I don't know what the price difference is between SAN and Wildcard certs. If you are going to use this wildcard cert for some other components in your network, then it might be a good choice for you.

I hope this helps.

-Dejan