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.