Tuesday, December 23, 2014

VCS Certificate Creation and Use Notes

Q1: The "Cisco TelePresence VCS Certificate Creation and Use Deployment Guide Cisco VCS X8.2" indicates when generating the CSR on Expressway Core for MRA, you need to include the FQDNs of all the CUCM phone security profile names.  Given the phone security profiles are typically in the format of  "Cisco 7841 - Standard SIP Non-Secure Profile", what would be the FQDN of this profile?

A1: The answer is actually in the "Unified Communications Mobile and Remote Access via Cisco VCS Deployment Guide Cisco VCS X8.2", not the certificate guide.

“The Phone Security  Profiles in Unified CM  (System  > Security > Phone  Security Profile ) that are configured for TLS and are used for devices  requiring remote access must have a name in the form of an FQDN that includes the enterprise domain, for example jabber.secure.example.com. (This is because those names must be present in the list of Subject Alternate Names in  the VCS Control's server certificate.)”  

So, instead of adding a profile called “Standard Secure EX90 Profile”, you need to add a profile called EX90.secure.example.com and add each of those profile FQDNs to the CSR on Expressway Core.


Q2:  In a working MRA (Mobile Remote Access) environment, you upload new certificates signed by a public CA / certificate authority to both your VCS / Expressway Edge and Core.  The MRA (Mobile Remote Access) Traversal Zone looks good on both VCS / Expressway servers but your remote Jabber clients return a "cannot communicate with the server" message.  Checking the VCS logs, you find errors like this:

portforwarding: Level="ERROR" Detail="Client control socket open failed" forwarding="localhost:8191:localhost:8192" host="expressway-edge1.mydomainname.com" id="59XXXXXX-9XXXX-1XXX-9XXX-0010XXXXXXXX" retcode="255" err="ssh_x509store_cb: subject='OU=Domain Control Validated,OU=COMODO SSL Unified Communications,CN=expressway-edge1.mydomainname.com', error 20 at 0 depth lookup:unable to get local issuer certificate
 ssh_verify_cert: verify error, code=20, msg='unable to get local issuer certificate'
 key_verify failed for server_host_key
 " UTCTime="2014-12-31 17:42:12,345"

A2: The issue is when you receive the new certificate for the server and install it, you should / need to install the entire certificate chain your CA provided.   This includes the trusted CA root certs. As an example, here where we used a certificate signed by Comodo, there were three other root and intermediate certificates supplied by Comodo that need to be installed as well.  They also need to be installed on both the Edge and Core servers.  Do not assume that since you already see your CA name on the VCSs' trusted lists that new certificates issued for the servers will work.


Q3:  You installed a publicly signed certificate on both the Expressway Edge and Core servers but MRA (Mobile Remote Access) users are still being challenged to accept certificates.  What do you look for?

A3:  From the "Cisco Expressway Certificate Creation and Use Deployment Guide" (note: this guide appears to be updated regularly with new information):
For Mobile and remote access deployments, the Expressway-C server certificate needs to include all the Unified CM phone security profile names, and all the IM and Presence chat node aliases. The Expressway-E server certificate needs to include all the Unified CM registrations domains, the XMPP federation domains and the IM and Presence chat node aliases.

Also note, the the Unified CM registrations domains need to be preceded with a "collab-edge".  So... if your CUCM domain is mydomain.com, you need to include an entry in the CSR that loks like collab-edge.mydomain.com.  Since this doesn't seem to make sense, you might try to use the SRV name format of _collab-edge._tls.mydomain.com when generating the CSR.  The current Expressway-E server has an option for this, makes total sense, but you'll likely find your CA doesn't support that name format.  Don't bother.  Use the DNS format with just the collab-edge prefix.

Tuesday, November 04, 2014

Cisco AnyConnect Secure Mobility Client list of networks drop down

Using the Cisco AnyConnect Secure Mobility Client vesion 3.1.04066, I found the first network you connect to is the only network that is automatically retained in the VPN drop down list.  I regularly need to connect to dozens of networks to provide support, so being able to populate that list and refer to it later is very helpful.

The older Cisco VPN Client allowed for a pretty simple method to add or import profiles.  Each network profile was stored in a seperate PCF file.  This would allow you to maintain a list of locations / networks in the client that you could connect to simply by choosing one on a list.

The newer Cisco AnyConnect Secure Mobility Client doesn't use provide the same method to create or maintain a list of networks. There is a drop down list though, so how does a user populate it?

On a Windows 7 machine you will find a single XML file in the C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile folder. The one on my machine is called AnyConnect_Essentials_client_profile.xml.

In that file you will find a section that looks something like:


I found that if you simply add a second HostEntry section, the VPN client drop down list will include the second network you want to connect to.


Choose you entry from the list, click connect and Ta-Da!

Sunday, September 21, 2014

Cisco CIMC - The maximum number of user sessions has been reached

I somehow ran into a "The maximum number of user sessions has been reached" error when working on a new Cisco BE6000 / UCS C220 chassis install.  I had previously updated all the chassis software using the Host Upgrade Utility so I imagine it may have somehow been just me. 

To fix things you can SSH to the CIMC address and run:

show user-session

To change to a particular session from the resulting list, note the session index numbers from the user-session list and run:

scope user-session sessionindex

To end the session you just switched to, run:


To exit the scope of that session, run:


Thursday, September 04, 2014

Cisco 8900 9900 slow response time and Simplified New Call UI

We recognized a bizarre issue during post-implementation support recently.  All 8961 series phones were very sluggish and they couldn’t keep up with the receptionists' fast fingers.  After investigation / research, we saw that “Simplified New Call UI” was set to “Disabled” on the root of the phone configuration.  The purpose of this feature is described below.  This was introduced in CUCM 9.x and carries through to the present Collaboration System Release.  After enabling the Simplified New Call UI” on all 8961s in the environment, response time was much faster.  Note that the same applies to the 9951 and 9971 series phones as well. Cisco Bug Tracker appears to indicate there are several related and open issues with the current firmware.

Simplified New Call Bubble
The Simplified New Call Bubble feature provides a simplified window for the user to place an off-hook call. The administrator enables or disables the feature in the Phone Configuration window using the Simplified New Call UI field. By default, the feature is disabled.
When the user start dialing a call with the Simplified New Call Window, the phone does not display possible phone number matches from the call history.
The feature is supported on the following SIP phones:

  • Cisco Unified IP Phone 8961
  • Cisco Unified IP Phone 9951
  • Cisco Unified IP Phone 9971