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.