Cisco Collaboration Certificates and Security

A lot has changed with CUCM certificate management and requirements. I think it’s only starting to sink in that CUCM is an application and should be treated like any other application that requires certificates. Continuous development has extended to on-prem apps. 

PKI isn’t new and certificates are not new. We’re not talking about bleeding edge technology and the issues that I’m seeing are related to misunderstanding fundamental technologies. Subtract CUCM from the equation and SSL/TLS/PKI principles apply regardless of the product underneath. 

Just because we as voice engineers haven’t “done it this way” before doesn’t mean we should “keep doing it this way”.

I usually start with an assessment of the client and their ability to manage internal PKI. If my assessment is that they haven’t done their PKI correctly or do not understand the concepts I immediately divert to a managed PKI discussion. For example, if I see a single root CA that’s SHA1 and it’s also the issuing CA that’s a thumbs down. If I also see they are lacking MDM or ISE it’s pretty evident adding a single management CA isn’t going to accomplish the end goal.

What is the end goal? Easy.. You don’t want anyone to click through a certificate warning regardless of device. If you as an administrator are clicking through certificate warnings you should seriously consider fixing that. 

Do PKI right or let the professionals do it for you. 

You can save yourself a lot of time, effort, and management headache if you’ll use 3rd party verified certificates internally and externally. The reality is you’re going to spend a fraction of the cost of internal PKI management. 

This also means that your servers should be operating in a domain that is resolvable in the context of the Internet. The service domain and server fields of the collaboration applications should be within an FQDN of a domain that you own. This is a strong recommendation from Cisco and has been a personal recommendation for years. Microsoft has even been advocating this forever but it’s been ignored in a large way. 

Let’s keep it real and stop using IP addresses to define connection points in and out of applications. We’ve all complained to developers before as network engineers if they’ve hard coded IP addresses. However we as voice engineers are doing the same thing. Use fully qualified names and SRV records to connect services together. TLS relies on the naming context of each service connection point and IP addresses in certificates are not acceptable.

Also it’s not reasonable to accept wide use of wild card certificates. What wild cards are intended for and what they’re being used for these days are two drastically different things. If your issuing authority will re-key a wildcard for a single issue SAN that is a step in a better direction but I’m not a fan of that either. You’re putting all your eggs in one basket against that wildcard. 

My final soap box is about secure clusters. A large majority of CUCM clusters are non-secure meaning they use unencrypted communications. Yes the token management hasn’t always been the easiest but this should be a default configuration change moving forward. Version 11 of CUCM has introduced a lot of enhancements in this area. It’s still PKI we are talking but it’s a different key ring. SIP signaling and media encryption inside the network should be just as important as outside the network. More and more we are doing Ethernet handoffs to carriers for the WAN. In reality your voice communications are exposed on those connections unless you’re also running an encrypted WAN. How many of us are running an encrypted WAN? 

Encryption for telecommunications should be a high priority for all enterprises and engineers responsible for telecommunications. It’s been a high exposure area for quite a long time and the conversation needs to shift. We’re not behind the firewall anymore. 

  

Advertisements

Cisco UCM 11 and LDAP Group Filtering

Introduced in UCM version 11 is the ability to synchronize groups from Active Directory. The primary driver is to have Active Directory groups available in the Cisco Jabber contact list.

One problem this brings up is that if you’re synchronizing from the base DN you’ll import all security groups. So you’ll need an effective filter to only get the groups you want. Generally speaking distribution groups are an ideal target for what you want represented in UCM and Jabber. The more granular you get will require more administration in Active Directory.

I’ll first outline the LDAP filters that will look for security groups and filter different types of groups. These are the bit values for each group and you’ll end up using the bitwise value.

All Security Groups with a type of Global
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483650))

All Security Groups with a type of Domain Local
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483652))

All Security Groups with a type of Universal
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483656))

Values for the different group types:
Global = 2
Domain Local = 4
Universal = 8
Security Group = 2147483648
Distribution Group = no value

Using the above information we can then build LDAP filters to only import distribution groups. Since a distribution group doesn’t have a value you have to add the NOT operator to the query.

All Global Distribution Groups
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

All Domain Local Distribution Groups
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=4)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

All Universal Distribution Groups
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=8)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

Now what if you want distribution groups and security groups and want to select certain groups? Depending on how much additional administration you want in Active Directory you can pick a custom attribute. At this point all you have to do is look for the custom attribute not in use and populate it. Exchange 2010 SP2 and higher introduces 5 new multivalued attributes, but in this example we’re still using a custom attribute.

I recommend running some queries to determine if you have any custom attributes currently in use and then picking the next available value. You can use whatever value you would like just as long as it’s descriptive enough why it’s being used. In the examples below I’ve used “CiscoUCM” as a value to indicate the system thats using it in a query.

All Groups with Custom Attribute 1 – (Note the LDAP property is named extensionAttribute1)
(&(objectCategory=group)(extensionAttribute1=CiscoUCM))

Only Universal Distribution Groups with Custom Attribute 1
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=8)(extensionAttribute1=CiscoUCM)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

I personally prefer the highest granular approach based on universal distribution groups and a custom attribute. This way the control is based on the source information and synchronized Cisco UCM/IMP information is kept to a minimum.

Happy filtering!

Cisco Jabber 11 Links and Videos

Cisco Jabber version 11 is significant in many ways and it’s difficult to outline all of the details in a single post. First and foremost Cisco is continuing to show that cross-platform feature parity, mobile first, and secure first is a leading part of the strategy.

Enterprise groups, persistent chat, and WebEx CMR escalation are three things significant enough to mention. There are some future integrations that will be better shown than blogging about.

There is a lot of work happening back at Cisco and I’m sure the Jabber team backlog is growing. In the meantime I highly recommend taking a look at the videos below to become a little more familiar with Cisco Jabber 11.

Check out these new Jabber 11 Videos

The release notes detailing the new features:

Jabber_Blue

SSL Errors and WordPress custom domains

I’ve recently been informed that since I’m using a custom domain that some browsers are giving an SSL warning when trying to visit my blog. I’m not 100% sure if WordPress has it in their ability to fix this because this would imply they would start allowing private key changes for each hosted site. Most likely they do not support this.

In the meantime I’m NOT going to be updating my links to point to the HTTP URL. If you’ve got a browser giving warnings to the site I recommend you try without the HTTPS.

I will look more into this issue and if necessary I’ll drop the custom domain and head back to a wordpress named blog to eliminate domain validation SSL errors. SSL is more important than the name associated with the site.

Thanks! (I’m still recovering from Cisco Live so there hasn’t been a wrap-up post. I’ve also been very busy at work.)

Cisco UC and VMware Latency Sensitivity

With VMware 5.5 showing up everywhere including Cisco collaboration specific hosts I found it was time to look into the use of latency sensitivity. Please don’t run off and turn this on without a proper understanding of what you’re changing on your UC cluster especially if you’re not follow co-residency guidelines. (That was a disclaimer and why wouldn’t you follow co-res guidelines anyway?)

When scoping or designing a UC cluster that involves Unity Connection there was always an extra core reservation for the VMware scheduler. With VMware 5.5 and the ability to specify latency sensitivity we don’t need to have one core sitting idle.

The reason this is important was due to core oversubscription and the co-residency guidelines published by Cisco. For example; if your host has 12 cores you can now safely lay out the VM reservations across all 12 cores and not 11 cores. This only applies if you have an active Unity Connection VM on the host machine. All other VMs on the host must have the latency sensitivity set to “normal”. Only the Unity Connection VMs will be set to “high”.

So now you’re wondering how do I cut it on? First it has to be modified while the machine is powered off, and if you have vSphere Web Client it is simple as “VM Options | Advanced settings | Edit | Latency Sensitivity = High”.

vsphere_web_latency_sens

OK – I see this yellow exlaimation point and what is about to happen? The warning is to let you know this should be performed on a VM that has CPU reservation. If you used the OVA to deploy Unity Connection and have not changed vCPU amounts or reservations you’re in the clear to proceed.

Since most UC clusters and ESXi hosts specific for collaboration are not joined to vSphere you need a way to turn on latency sensitivity without vSphere Web.

  • Using the vSphere client edit the settings of the Unity Connection VM.
  • Click Options | Advanced-General | Configuration
  • First scan to see if “sched.cpu.latencySensitivity” is in the configuration parameters.
  • If the setting does not exist click “Add Row”
    • Name = sched.cpu.latencySensitivity
    • Value = high
  • Click OK | OK

vsphere_gui_latency_sens

Don’t forget to power it back on. 🙂

Cisco Jabber Certificate Warning Again?

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!

Expressway 8.5 and Unity Connection

Expressway 8.5 adds the capability to add Unity Connection directly to the Expressway Unified Communications configuration. This gives Jabber mobile and remote access clients the ability to manage voicemail messages via HTTPS to the VMREST(CUMI) API.

In previous versions of Expressway we had to manually add the Unity Connection servers to the HTTP allow list. With this version once we add Unity Connection it automatically updates the HTTP allow list.

A caveat to be aware of similar to the CUCM and IM&P caveat is if you’re using host names or IP addresses for the “System -> Server” setting. In many cases your Unity Connection server is going to be defined by hostname which is default. The thing to note is if your Unity Connection is hostname only and you add this to Expressway your HTTP allow list is going to be incorrect. Expressway will detect hostname only and add only the hostname to the HTTP allow list.

So what’s the fix? Change your Unity Connection server value to FQDN. If you’re running a cluster this does have a little impact where you’ll need to restart services but if it is a single node you can make this change without impact.

Once Unity Connection server value is FQDN go ahead and add or refresh the server on Expressway and the HTTP allow list will update correctly. Just one of the little nuances if you head down this road on Expressway and Jabber MRA cannot connect to voice mail.

Thanks!