There has been a flurry of activity lately when it comes to Jabber and certificate warnings. Jabber adoption is growing and being exposed to a lot of different installations of Communications Manager and IM & Presence.

Not only do we have the adoption rate skyrocketing but we’re also seeing the development cycle becoming extremely fast. In the last 2 months I believe I’ve counted 4 minor releases to just 1 train of Jabber. This is presenting several challenges between the development and the deployment of Cisco Jabber. The technical information, deployment recommendations, and caveats are not being consumed fast enough in the field to understand the nuances of getting it to work. All of this is a great effort by Cisco but I do believe there could be a better way getting technical notes out to the field.

Certificate warnings are something that just isn’t acceptable. If your workaround is telling someone to ‘Click Accept’ then you’re not doing something right. We’re dealing with a client application and parts of the CUCM system that in the past have rarely needed to be touched. If communications manager and presence were installed for telephony only there are many things lacking to get these certificate warnings to go away.

Here is the latest information straight from Cisco regarding the certificates you need to adjust depending on the products you have deployed.

Required Certificates for On-Premises Servers On-premises servers present the following certificates to establish a secure connection with Cisco Jabber:

Server	Certificate
Cisco Unified Presence or Cisco Unified Communications Manager IM and Presence Service	HTTP (Tomcat) XMPP (cup, cup-xmpp, cup-xmpp-s2s, tomcat)
Cisco Unified Communications Manager	HTTP (Tomcat) and CallManager certificate (secure SIP call signalling for secure phone & CTI connection validation) (callmanager, tomcat)
Cisco Unity Connection	HTTP (Tomcat)
Cisco WebEx Meetings Server	HTTP (Tomcat)
Cisco VCS Expressway Cisco Expressway-E	Server certificate (used for HTTP, XMPP and SIP call signaling)

So let’s break this table down into something a little more understandable. On Communications Manager this involves uploaded valid CA certificates to callmanager-trust and tomcat-trust. Once those are uploaded you need to generate a CSR for callmanager.pem and tomcat.pem. Even though you can sign all your CUCM nodes with one SAN certificate there are several caveats with this and my personal recommendation is to continue signing each CUCM node with its own certificate.

On IM & Presence you need to upload valid CA certificates to cup-trust, cup-xmpp-trust, and tomcat trust. Once that is complete you need to generate the CSR and sign cup, cup-xmpp, cup-xmpp-s2s, and tomcat.

On Unity Connection you’ll only need to upload and sign the tomcat certificate.

One Expressway-CORE you’ll need to upload the valid CA certificate and generate a server certificate. On Expressway-EDGE you’ll 100% need a public signed CA certificate for the server certificate. If you’re not going to use Expressway for B2B communications and every device using Jabber MRA has managed certificates you MIGHT get away with a private CA signed certificate, but I still wouldn’t recommend it.

These certificates need to be x509v3 compliant for server authentication, client authentication, and ipsec. If you’re looking for the exact settings needed I have the certificate template EKUs below. All of the certificates can all be signed by a Microsoft CA with an x509v3 compliant template.

Version: V3
SignatureAlgorithm: SHA1withRSA (1.2.840.113549.1.1.5)

Extension: ExtKeyUsageSyntax (OID.2.5.29.37)
Critical: false
Usage oids: 1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.5, 1.3.6.1.5.5.7.3.2,

Extension: KeyUsage (OID.2.5.29.15)
Critical: false
Usages: digitalSignature, nonRepudiation,keyEncipherment,dataEncipherment

The callmanager certificate also has keyAgreement usage but this is mutually exclusive of keyEncipherment per RFC 3280. The keyCertSign is also not needed as an EKU because this isn’t a self-signed certificate. Your callmanger certificate is perfectly valid without these two EKUs. My x509v3 template typically includes nonRepudiation to allow the certificate template to be used for VMware servers.

A final reminder is if you truly want to support all client types without doing managed PKI go ahead and save yourself a lot of headache and get public CA signed certificates for all of this.

So you’ve done all of that and you still get a certificate warning?

There is a good possibility you have certificates correct but you’re still getting these prompts. Let’s understand this issue a little deeper before I get to the long term fix. SSL certificate validation is based on the client and server agreeing to the subject name or SAN name. For example, if you have a valid and trusted certificate on a web server and you browse to https://10.1.1.0 you’re going to get a certificate warning from your browser. This is because you told the browser you wanted a secure connection to 10.1.1.0 but the server sends back a certificate the the name webserver.domain.com. The same thing is happening underneath Jabber between CUCM, CUPS and Expressway. When Jabber connects to CUCM via UDS or CTI the server may be responding with an IP address even though you’ve requested the FQDN. SO WAIT – isn’t that a reverse of what you just said? Absolutely it is but the same principle applies. The CUCM and CUPS “System > Server” setting is giving you this problem. So while Jabber tries to connect to CUCM via cucm-node1.domain.com the UDS/CTI is responding with https://10.1.1.20 which will be the IP address of the node.

So now what – I can’t just go and change that “System > Server” value without breaking the whole cluster! This is where some additional pain points may come into play. The “System > Server” value controls quite a few communications between cluster nodes and endpoints. This value is essentially put into the phone configuration files that are downloaded. Over the years Cisco SRND and guides have flip flopped with the recommendation here. There have also been several bugs along the way using hostname or FQDN. Now we’re to a point where FQDN is the standard and any bugs will need to be fixed to support FQDN. My first recommendation is make sure you’re on the latest versions of CUCM and CUPS and this is super important if you’re serious about the Jabber deployment.

Some have opted to put the hostname or IP address of the “System > Server” values into the SAN certificate fields that are uploaded to the servers. While this sounds like an OK workaround that particular SSL certficate it still invalid per the CA/Browser forum. It may “work” but at this point in time it is more of a hack. You can read the full details of this CA/Browser change at https://www.digicert.com/internal-names.htm

I know this post got a little long but it’s really important stuff to get your deployment up to the new standards, using valid certificates, and keeping certificate warning prompts away from your users.

Thanks and feel free to comment or reach me on Twitter!