Showing results for 
Search instead for 
Did you mean: 

Chalk Talk: An Insight to Cisco Unified Communications Manager (CUCM) Certificates


Cisco  Unified Communications Manager (CUCM) is the central piece to Cisco  Unified Communications/Collaboration solution. Many Collaboration  services, such as voice, video, conferencing and so on, depend on CUCM.  In order to provide secure CUCM access and various CUCM security  features (as well as secure integration with other Cisco and third party  applications) Cisco has bundled a Certificate Authority (CA) and  self-signed certificates with CUCM. CUCM comes with built-in certificate  authority and offers a plethora of certificates for various functions  and features.

A  very common notion is that certificates are used for security – which,  by the way, is 100% correct! However, you may ask, where is security  used? The simple answer is – Everywhere! The following list of services  or security functions offered by CUCM/Endpoints give a good insight to  where security is used in Cisco UC Paradigm: 

  • Encrypted Device Registration 
  • Encrypted Calls
  • Encrypted Phone Configuration Files
  • Secure H.323/SIP Trunks and Gateways
  • Secure Survivable Remote Site Telephony (SRST)
  • Security By Default (ITL, TVS)
  • Secure Conferencing
  • Secure LDAP
  • Secure Web Pages (Tomcat)
  • Single Sign-On (Open AM)
  • Extension Mobility Cross Cluster (EMCC)
  • Secure Voicemail ports
  • VPN Phone

And  so on. With that in mind let’s understand different types of  certificates and CUCM PKI model that empowers you to design, deploy, and  maintain a secure Cisco UC network, and is central to the security  construct of Cisco UC solution.

Demystifying Cisco Unified Communications Manager PKI

Cisco  UC PKI is not a single PKI system, but a distributed PKI where CUCM  server certificates are self-signed by default with CUCM playing as a  self-sustained CA. Moreover, CUCM has a wealth of certificates for  different purposes such as:

  • Manufacturing-Installed Certificates (MIC) on IP Phones - signed by Cisco Manufacturing CA
  • Locally Significant Certificates (LSC) on IP Phones - signed by Cisco CUCM CAPF
  • Tomcat  certificates - signed by Cisco Tomcat service and are available with  install of CUCM for secure CUCM Administration, OS Administration access

Table 1: Public Key Infrastructure (PKI) Construct

ScreenHunter_26 Feb. 20 10.34.jpg

Figure 1 provides an overview of X.509 v3 certificate.


Figure 1: Overview of CUCM certificate

CUCM  PKI is a disparate setup where a common trust provider is missing (for  device facing certificates). Figure 2 illustrates the CUCM PKI  construct.

Picture2.jpgFigure 2: CUCM PKI Construct

An Insight to Certificates Available in CUCM

Let’s  delve deeper into various CUCM certificates and understand their  function and relevance to different aspects of Cisco UC solution’s  security.

As  indicated earlier, CUCM PKI is not a singular but a multilevel and  disparate construct that enables and empowers you to secure various  aspects pertinent to Cisco UC network’s security – from endpoint  security to network security to application level security. The  following list contains certificates available in CUCM:

  • Security By Default (ITL, TVS)
  • Certificate Authentication Proxy Function (CAPF, CTL)
  • Tomcat (HTTPS)
  • IPSec
  • VPN Phone

Figure 3 gives an insight to the various certificates available within CUCM.


Figure 3: CUCM Certificates (click to enlarge)


Security  by Default (SBD) is a fairly recent introduction with CUCM 8.x and  later releases. It enables default protection of endpoints from spoofing  perspective. It allows endpoints to download a list of CUCM servers in  the cluster, in the form of a file called Initial Trust List (ITL). This  file is built automatically when the cluster is installed; no manual  intervention is needed to ensure that the file gets downloaded to each  endpoint. ITL facilitates – signing of phone configuration files, phone  configuration file encryption, HTTPS with Tomcat and other Web services  (Midlets). In other words, ITL is a smaller and leaner Certificate Trust  List (CTL) with certain limitations. SBD also facilitates a new service  known as Trust Verification Service (TVS). TVS runs on each CUCM server  and authenticates certificates on behalf of the phone such that,  instead of downloading all the trusted certificates, phones need only to  trust TVS. In fact, the ITL file contains TVS certificates and a few  key certificates:

  • The TFTP certificate - used to authenticate the ITL File signature and the phone configuration file signature
  • All TVS certificates in the cluster - which allow an endpoint to talk to TVS securely to request certificates authentication.
  • The CAPF certificate - to allow configuration file encryption.

CAPF – Certificate Trust List (CTL)

CTL  is a trust list built with CAPF as root certificate authority. CTL is  not implicit to a cluster unlike ITL and must be enabled explicitly for  each endpoint, trunk, or device. CTL is signed by the Cisco CTL client  using the private key from one of the administrator security tokens,  which are all signed by the Cisco CA. CTL acts as an authorization list  specifying which certificates belong to which function. The CTL client  helps enable either authenticated signaling or encrypted signaling and  media for endpoints including IP Phones, Gateways, Conference resources,  Trunks, and so on. For Cisco IP Phones, CTL can be installed with a MIC  or LSC certificate, with MIC being signed by Cisco CA and built into  the phone whereas, LSC is downloaded from CUCM to phone. For Cisco TFTP  function, the CAPF service can help provide encrypted TFTP configuration  and firmware file downloads.

In  a nutshell, each CUCM service (CCM, TFTP) has a self-signed certificate  for Publisher, TFTP, Subscriber functions and, once CAPF is activated  and CTL client is executed, it also has a self-signed certificate. All  in all, all CUCM encryption and authentication functions related to CAPF  act as their own PKI root, which are self-signed by default, however,  can be signed by external CA as well.

Cisco Tomcat Certificate

Cisco  Tomcat service, as the name suggests, is used by the Web Server of CUCM  and helps display the administration, operating system, disaster  recovery, and other GUI interfaces of CUCM. The service leverages a  built-in CA for Tomcat in that it redirects the incoming HTTP requests  to HTTPS using the default self-signed certificate. It’s interesting to  know that prior to CUCM version 8.5, Tomcat was used only for web  interface; however, starting with CUCM version 8.5 and later releases,  it is also used for secure LDAP integration using SLDAP. The Tomcat  certificate can be signed by an external CA, which may be a requirement  in an organization, to ensure that all certificates used for web-based  interfaces adhere to the organizational security policy. This also  mitigates the user side warnings pertinent to accessing an untrusted  site – particularly when the CUCM Tomcat root certificate is not in the  certificate store of the user’s browser certificate store.

CUCM IPSec Certificate

More  often than not, CUCM need to interoperate with voice gateways, which  can be MGCP, H.323, or SIP protocol-based communication. While SIP has  inherent capacity for securing voice media and signaling with a SIP TLS  profile for SIP Trunks, H.323 and MGCP gateways offer limited support  for secure signaling and, in such case, the signaling must be encrypted  within an IPSec tunnel to H.323 or MGCP gateway. This can be done by  creating an IPSec tunnel from CUCM to destination gateway using  certificates (or pre-shared key).


Cisco’s  VPN phone is a relatively new feature introduced with CUCM version 8.x  that allows remote workers or telecommuters to have their Cisco Unified  IP Phone 7900, 8900, and 9900 series connected to enterprise network  from their home, hotel, or any place with internet access. The IP Phone  enrolls itself with CUCM within the enterprise to download the  certificates from CUCM and Cisco VPN concentrator. CUCM is, in turn,  enrolled with Cisco ASA or Cisco IOS VPN device and exchanges  certificates with VPN concentrator and vice-versa.


CUCM  has a whole spectrum of certificates for various functions and Cisco  empowers you to leverage them to have a strong and manifold security  construct in place for your UC solution. While some certificates may be  commonly used, some have very specific uses. Services like TLS for  signaling and SRTP for media require CAPF certificates to be enabled and  deployed, whereas secure web access leverages default Tomcat secure web  services. CUCM certificates help organizations and IT departments  harness the power of PKI to deploy the simplest to the most complex  security functions and to help an organization achieve its business  vision and goals by being in line with its security requirements.

Author Bio


Akhil Behl is a Solutions Architect with Cisco Advanced Services, focusing on  Cisco Collaboration and Security Architectures. He leads collaboration  and security projects worldwide for Cisco Advanced Services and the  Collaborative Professional Services (CPS) portfolio. Prior to his  current role, he spent ten years working in various roles at Linksys as a  Technical Support Lead, as an Escalation Engineer at Cisco Technical  Assistance Center (TAC), and as a Network Consulting Engineer in Cisco  Advanced Services. Akhil has a bachelor of technology degree in  electronics and telecommunications from IP University, India, and a  master’s degree in business administration from Symbiosis Institute,  India.

Akhil  is a dual Cisco Certified Internetwork Expert (CCIE No. 19564) in Voice  and Security. He also holds many other industry certifications, such as  Project Management Professional (PMP), Information Technology  Infrastructure Library (ITIL) professional, VMware Certified  Professional (VCP), and Information Security Management. He’s a prolific  speaker and over the course of his career, he has presented and  contributed in various industry forums such as Interop, Enterprise  Connect, Cloud Connect, Cloud Summit, Computer Society of India (CSI),  Cisco Networkers, IT Expo, and Cisco SecCon. He has several research  papers published to his credit in various international journals.


Securing Cisco IP Telephony Networks

By Akhil Behl

Series: Networking Technology: IP Communications.

Published: Aug 31, 2012

ISBN-10: 1-58714-295-3

ISBN-13: 978-1-58714-295-6

Published by Cisco Press.

This article was featured in the February 2013 issue of the Cisco TS Newsletter. Are you subscribed?

1 Comment


I bought your book and it is very good. But I still havea problem and maybe you can help me.

a) I have two Callmanager  (publisher and subscriber) and they are configured mixed-mode. I checked that the CAPF.pem in the subscriber was issued after the CTL file ( the publisher was before), maybe someone regenerate the CAPF.pem in the subscriber and does not rerun the CTL Client. The question is: If I regenerate CAPF in the publisher and  the rerun the CTLClient, the new CAPF certificate will be installed in the publisher and subscriber ? This certificate should be identical int the both servers?

b) Due the CAPF.pem in the publisher and subscriber are different, the CAPF can not works fine? I tried install LSC but it is not working, in the 9971 phones status messages show "No valid CAPF server" .

c) Your last answer about 7940, so if i just regenerate CAPF and rerun ctl client (not change TFTP adrress) will not be necessary delete manually the ctl file?

d) I also checked that the itl file does not has a entry for CAPF. It could  impact the CAPF functionality?

Kind Regards


CreatePlease to create content
Content for Community-Ad
FusionCharts will render here