cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays

CWMS SSL Certificates and Local/Internal Domain names

2406
Views
5
Helpful
0
Comments

As you might have heard, Certification Authorities announced that starting November 1, 2015, certificates for internal domain names will no longer be trusted: https://www.digicert.com/internal-names.htm . Starting with November 1, 2014, Certification Authorities stopped issuing SSL certs for internal domain names.

As you know, CWMS solution uses SAN (Subject Alternative Names) SSL Certs or Wildcard SSL Certs. When you generate Certificate Signing Request (CSR) on CWMS, hostnames of internal CWMS VMs, Admin page FQDN, and WebEx Site FQDN are included in this CSR. Hence, when you request SAN SSL Cert, Certification Authority needs to provide you an SSL cert for all the hostnames listed in CSR.

 

The problem occurs if you use internal domain names in the names of internal CWMS VMs (e.g. adminvm.domain.local, or mediavm.domain.internal, etc.). If you have such domain names configured, Certification Authorities won't issue you a publicly signed SSL cert.

At this time, to work around this issue you can do one of the following:

1. Change FQDNs of your Internal CWMS VMs to use public domain names (e.g. adminvm.domain.com, adminvm.domain.org, etc.) and configure your Internal DNS server to host a Public Domain Zone (e.g. domain.com, domain.org, etc.). - Note: make sure you configure DNS first before you make the change on CWMS.

2. Configure a Public DNS that is hosting your public domain to resolved your CWMS Internal VM hostnames to the appropriate IP addresses of those VMs (e.g. adminvm.domain.com => resolved to Admin VM IP), and configure your Internal DNS server that CWMS VMs are referencing to forward all requests for domain.com to the Public DNS. Even in this case, you will of course need to change FQDNs of your Internal CWMS VMs to use public domain names (e.g. adminvm.domain.com, adminvm.domain.org, etc.)

 

Here is a link to the official documentation about the FQDN change: http://www.cisco.com/c/en/us/td/docs/collaboration/CWMS/2_5/Administration_Guide/Administration_Guide/Administration_Guide_chapter_01110.html#task_69757B2D9BF5405FB95E144F4E6EA054

Here is my recommendation for the process to be on a safe side:

1. Put the system into Maintenance Mode
2. Gracefully Power OFF the VMs (in vCenter, right click the VM > Power > Shut Down Guest)
3. Once the VMs are down, take a VM snapshot of each VM
4. Power the VMs ON
5. Verify on DNS server that for the new public domain (.com, .net, .org) you defined each CWMS VM FQDN, as well as Admin URL (We assume WebEx site URL is using public domain name by default).
6. Once the system is ON, browse to Administration > System > View More to list all the VMs FQDNs and IPs
7. Click on each VM and change FQDN. If the DNS has the new hostnames configured and pointing to the appropriate IP addresses, just change the FQDN and save the changes.
8. Once you changed all the VMs FQDNs, change the Admin URL to reflect the new domain (Administration > System > Configuration – View More > Edit WebEx Administration Site Settings
9. Once all the changes are applied, save them, and bring the system out of Maintenance Mode.
10. If all looks good, remove the VM snapshots. Make sure you don’t keep the VM snapshots more than 24h, as they can cause serious performance issues.
NOTE: If you experience any issues, revert the system by using VM snapshots you've taken in step 3.
 

 

We had an enhancement request opened (https://tools.cisco.com/bugsearch/bug/CSCum98717) to change the way CWMS handles SSL certs which should address this issue, and this is included in 2.0 MR9 and 2.5 MR5 version levels (you can search for Split Certificate options in the Release Notes and Administration guides)

 

I hope this will help.