Explore Cisco
How to Buy

Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco UCM Admin Security Token EoL and Transitioning to Tokenless CLI White Paper

White Paper

Available Languages

Download Options

  • PDF
    (728.6 KB)
    View with Adobe Reader on a variety of devices
Updated:March 9, 2021

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Available Languages

Download Options

  • PDF
    (728.6 KB)
    View with Adobe Reader on a variety of devices
Updated:March 9, 2021
 

 

Introduction

Cisco® Unified Communications Manager (Unified CM) provides endpoint registration and call processing. The signaling between Unified CM is based on Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) and can be encrypted using Transport Layer Security (TLS). The media to and from the endpoints is based on Real-Time Transport Protocol (RTP) and can also be encrypted using Secure Real-Time Transport Protocol (SRTP). Those types of traffic are illustrated in Figure 1.

Encrypted signaling and media

Figure 1.            

Encrypted signaling and media

Enabling mixed mode on Unified CM enables the ability to perform encryption of the signaling and media traffic to and from Cisco endpoints. There are two methods to enable mixed mode: 1) using the Unified CM Admin Security Tokens (USB eTokens), or 2) using the Unified CM CLI (tokenless).

1.     Unified CM Admin Security Tokens (USB eTokens)

This method requires the administrator to install the Certificate Trust List (CTL) client on a Microsoft Windows desktop and to use a minimum of two hardware USB eTokens: KEY-CCM-ADMIN-K9= or KEY-UCM-ADMIN2-K9=. The role of the USB eTokens is to sign the CTL file. This is the original method to enable mixed mode.

2.     Unified CM CLI (tokenless)

This method does not require any software installation on a desktop, or any USB tokens. It is based on a CLI command whereby the CTL file is signed by an internal private key corresponding to the public key of the CallManager certificate in Unified CM release 11.5 or earlier, or corresponding to the public key of the ITLRecovery certificate in Unified CM release 12.0 onward. This key is also used to sign the ITL file and is not accessible via the network or by the Unified CM administrators. This is the newer method to enable mixed mode. It was introduced in Unified CM release 10.

Cisco has announced the End of Sale (EoS) of the Unified CM Admin Security Token KEY-UCM-ADMIN2-K9=. Refer to the End-of-Sale and End-of-Life announcement for the Cisco CUCM Admin Security Token, 7.1 or Newer for more details. Customers with existing Unified CM Admin Security Token (USB eTokens) can still use their existing keys to enable mixed mode, but note that the CTL client is also reaching end of support and is no longer supported with Unified CM release 14. Therefore, the Unified CM CLI (tokenless) method will become the only method to enable mixed mode going forward.

This document covers:

      How to enable mixed mode with the Unified CM CLI (tokenless)

      How to migrate from the Unified CM Admin Security Token to the Unified CM CLI (tokenless) method

      Considerations with some special scenarios

Note:      In Unified CM release 12.5(1), a new option to enable encryption of signaling and media based on SIP OAuth instead of mixed mode/CTL was added for Cisco Jabber® clients and Webex app. In Unified CM release 14, this option was also added for the Cisco 7800 and 8800 series IP Phones. The following table illustrates the support of those two options.

Supported methods to enable signaling and media encryption

Mixed-Mode (with CTL file)

SIP OAuth

Jabber

Yes

Yes (from Unified CM 12.5)

Webex application

No

Yes (from Unified CM 12.5)

Cisco 7800/8800 series IP Phones

Yes

Yes* (from Unified CM 14)

Other Cisco IP Phones

Yes

No

* Except for the Cisco 8831 and 8821 Phones

Note:      With Mobile and Remote Access (MRA) endpoints, the signaling and media is always encrypted between the MRA connected endpoints and Cisco Expressway nodes. However, encryption of the signaling and media between Expressway-C and the internal Unified CM servers, internal endpoints, or other internal devices requires mixed mode or SIP OAuth.

Enabling Unified CM mixed mode for the first time

Prerequisites:

      Unified CM release 10.0 or later

      US Export Restricted software for Unified CM

      Encryption license for Unified CM release 11.5 or “Allow export-controlled functionality” enabled in Smart Software Licensing for Unified CM release 12.x and later

Note that the last two requirements apply to Unified CM deployments with mixed mode or with SIP OAuth.

Procedure:

To enable Unified CM mixed mode, perform the following steps:

1.     On the Unified CM Publisher, enter the utils ctl set-cluster mixed-mode command on the CLI and press Enter to move the cluster to mixed mode. When prompted, confirm you want to continue by typing ‘y’ and pressing Enter.

Note: When typing ‘y’, you might not see the ‘y’ on the screen until after you press the Enter key.

Procedure

This also creates the Certificate Trust List (CTL) file. This file is signed by the private key corresponding to the CallManager certificate with Unified CM release 11.5 and earlier or by the private key corresponding to the ITLRecovery certificate with Unified CM release 12.0 and later.

2.     Restart the CallManager and CTIManager services on all Unified CM nodes. With Unified CM releases prior to 12.x, also restart the Trivial File Transfer Protocol (TFTP) service on the Unified CM TFTP nodes.

3.     Restart all the IP phones and endpoints in order to ensure they download the CTL file.

For more details on the procedure and verification steps, refer to the CUCM Mixed Mode with Tokenless CTL TAC TechNote.

Once the cluster is in mixed mode, if a certificate that is part of the CTL file is changed, the CTL file needs to be updated manually. When using the CLI (Tokenless CTL) to enable mixed mode, updating a CTL file is very simple; it can just be done with the CLI command, utils ctl update CTLFile.

Once the Unified CM cluster is in mixed mode, endpoints can be configured to be in encrypted mode, whereby the media and signaling for those endpoints will be encrypted.

Migration

The procedure to migrate from the Unified CM Admin Security Token to the Unified CM CLI (tokenless) is simple and does not require the USB eTokens.

1.     On the Unified CM Publisher, enter the utils ctl update CTLFile command on the CLI and press Enter to move the cluster to mixed mode. When prompted, confirm you want to continue by typing ‘y’ and pressing Enter.

Migration

Note: When typing ‘y’, you might not see the ‘y’ on the screen until after you press the Enter key.

2.     Restart the CallManager and CTIManager services on all Unified CM nodes. With Unified CM releases prior to 12.x, also restart the TFTP service on the Unified CM TFTP nodes.

3.     Restart all the IP phones and endpoints in order to ensure they download the CTL file.

For more details on the procedure and verification steps, refer to the CUCM Mixed Mode with Tokenless CTL TAC TechNote.

Scenarios

1. Proxy TFTP

The CTL client with the hardware USB eTokens provides the ability to add Cisco Unified CM TFTP certificates (which are, in fact, CallManager certificates from the Unified CM TFTP nodes) to the CTL file. The CLI with Tokenless method does not have this capability. This is not an issue and this section will explain why.

The ability to add Cisco Unified CM TFTP certificates to the CTL file with the CTL client was designed for deployments using Proxy TFTP (or Centralized TFTP in the past) with Unified CM releases prior to Unified CM release 8.0, when Trust Verification Service (TVS) and Initial Trust List (ITL) were not available.

Unified CM release 8.0 introduces the Trust Verification Service (TVS) and Initial Trust List (ITL) file, which removes the requirement of adding the Unified CM TFTP certificates to the CTL file. Let us consider the deployment with a dedicated Proxy TFTP cluster and multiple home (or remote) clusters, all running Unified CM release 8.0 or later. When a Cisco endpoint powers up, it requests two types of files from the Proxy TFTP servers: dynamic files and static files.

      The dynamic files, including the CTL, ITL, and configuration files, are proxied by proxy TFTP servers. The endpoints request those files from the Proxy TFTP servers, which in turn, request the files from the Unified CM Home cluster. The Home cluster builds the files, signs them, and sends them back to the Proxy TFTP servers, which then merely forward the files to the endpoints without altering the files or resigning them. Those files are built and signed by the home Unified CM servers and the Proxy TFTP servers simply relay those files to the endpoint without modifying them or without changing the signature.

      The static files, such as the application dial rules, soft key button template, ring tones, phone background images, and phone loads, are handled differently. If they are already present in the proxy TFTP server, the proxy TFTP server itself signs and delivers the files back to the endpoint. If not, the proxy TFTP server requests the file from the remote clusters, gets the signed file from the remote cluster that responds first, and then relays the file back to the endpoint.

File download flow with Proxy TFTP

Figure 2.            

File download flow with Proxy TFTP

When an endpoint boots up, it first requests the CTL and ITL files from the Proxy TFTP server. Those files are dynamic files, they are built by the home cluster, and they include certificates from the home cluster. When the endpoint downloads its configuration file and other dynamic files from the proxy TFTP server, it can validate the signature of those files using the certificates from the CTL and ITL files it just received since dynamic files are also built and signed by the same home cluster.

However, when the endpoint requests static files and those static files exist on the proxy TFTP servers, it cannot verify the file signature using the ITL and CTL files since static files are built and signed by the proxy TFTP servers. The endpoint will then connect to the home cluster TVS servers in order to verify the signature of those static files. In order for this operation to be successful, the proxy TFTP CallManager certificates need to be imported into the phone-sast-trust of the home clusters. If this is done, the home cluster TVS servers can then send the appropriate proxy TFTP CallManager certificate to the endpoint, which in turn, can validate the signature of the static files. Once the endpoint downloads all the files from the proxy TFTP servers, it connects and registers directly to the home cluster.

In summary, Proxy TFTP is supported in Unified CM clusters in mixed mode, whether the USB eTokens or the CLI (tokenless) methods are used.

2. Extension Mobility Cross Cluster

Extension Mobility (EM) allows users to temporarily access their phone settings, such as line appearances, services, and speed dials, from phones that do not belong to those users but that are registered to the same Unified CM cluster as the ones the users are provisioned in. Extension Mobility Cross Cluster (EMCC) extends this functionality to phones that are registered to different Unified CM clusters (visiting clusters) from the cluster the users are provisioned in (home clusters).

A simplified EMCC flow is shown in Figure 3. A user is provisioned in their Unified CM Home Cluster (HC). This is step 1. The user could move and want to log in a phone that is registered to another Unified CM cluster. We call this cluster the Unified CM Visiting Cluster (VC). When the user logs into this phone, the visiting cluster looks for the home cluster the user is provisioned in (step 2), then information is exchanged between the visiting cluster and home cluster (step 3). The phone downloads some files from the original Unified CM cluster (VC), including its mini-config file that provides the IP address of the home cluster TFTP servers (step 4). Then the phone connects to the user’s home cluster TFTP server, downloads the CTL, ITL, full configuration file, and other TFTP files, and registers to the user’s home cluster (step 5).

Simplified EMCC login flow

Figure 3.            

Simplified EMCC login flow

EMCC is supported with phones configured in encrypted mode. Unified CM mixed mode can be enabled with the USB hardware eTokens or the CLI (tokenless).

Exchanging certificates between the Unified CM clusters is required most of the time. The general recommendation is to use the Bulk Certificate Management tool and to select the option to exchange “all” certificates between the Unified CM clusters in order to support all scenarios. This option consists in exchanging the CallManager, Tomcat, and CAPF certificates. With Unified CM releases 12.0 or later, the ITLRecovery certificates are also exchanged as part of this bulk certificate management operation.

The general recommendation to use the Bulk Certificate Management tool and to exchange all certificates does not change, whether mixed mode is enabled on the Unified CM clusters with the USB eTokens or with the CLI (tokenless). The EMCC functionality is also not affected by whether USB hardware eTokens or CLI (tokenless) is used.

For the sake of better understanding which certificates are used during EMCC, we will provide some information on why the certificate exchange between clusters is required.

Tomcat certificates

During an EMCC login flow, the Tomcat certificate is mainly used between the clusters when the VC cluster is searching for the user’s HC. This connection uses HTTPS. Therefore, the Tomcat certificates of the remote clusters need to be trusted. With self-signed Tomcat certificates, the Tomcat certificates need to be exchanged between the clusters. Specifically, the Tomcat certificates of each cluster need to be imported into the tomcat-trust of the other clusters. With CA-signed Tomcat certificates, if the Tomcat certificates are all signed by the same CA or if the CA certificates that sign all the Tomcat certificates are imported into the tomcat-trust store, exchanging Tomcat certificates between the clusters is not necessary anymore. This Tomcat certificate exchange requirement does not change whether mixed mode is enabled using the USB eTokens or the CLI (tokenless) method.

CallManager and ITLRecovery certificates

If mixed mode is enabled using the same USB eTokens on all Unified CM clusters, in general, it is not necessary to exchange the CallManager and ITLRecovery certificates anymore. When a user logs in via EMCC and the phone connects to the user’s home cluster, it downloads the CTL file first. Since the same USB eTokens have been used on all clusters in this example, and since the phone already trusts the USB eTokens, it will then be able to verify the CTL file signature and will accept the CTL file. Once the CTL file is accepted, the phone will be able to verify the signature of the other signed files it downloads from the home cluster TFTP servers.

If mixed mode is enabled using the CLI (tokenless), some certificates need to be exchanged between the Unified CM clusters. With Unified CM release 11.5 and earlier, the CallManager certificates of the TFTP servers need to be exchanged since the CTL and ITL files are signed by the private key corresponding to the CallManager certificates in those releases. Specifically, the HC CallManager certificates need to be uploaded to the phone-sast-trust of the VC. With Unified CM release 12.0 onward, the ITLRecovery certificates need to be exchanged since the CTL and ITL files are signed by the private key corresponding to the ITLRecovery certificate in those releases. Specifically, the HC ITLRecovery certificates need to be uploaded to the phone-sast-trust of the VC. Indeed, when the phone connects to the HC and downloads the CTL file, it will need to connect to the VC TVS servers in order to verify the signature of the HC CTL file (and signature of the HC ITL file). Hence, the requirement of uploading the HC CallManager (release 11.5 and earlier) or ITLRecovery (release 12.0 onward) certificates to the VC phone-sast-trust.

With both USB eTokens and CLI (tokenless) methods, there could be some corner cases where the CallManager certificates would also need to be exchanged, if not already done. For example, if the user is provisioned with one locale, and the VC phone is provisioned with a different locale, and if both Unified CM clusters have both locale files installed, then the VC CallManager certificates would need to be imported into the HC phone-sast-trust. Indeed, after the phone connects to the HC and gets the CTL, ITL, and config files from the HC TFTP server, the phone attempts to download the locale file from the VC TFTP server first instead of the HC TFTP server. At this point, the phone already switched to HC, and therefore needs to connect to the HC TVS server in order to verify the locale file signature coming from the VC. Hence, the VC CallManager certificates need to be added to the HC phone-SAST-trust store.

Using the Bulk Certificate Management tool to exchange “all” certificates takes care of exchanging the CallManager certificates. With Unified CM release 12.0 onward, it also takes care of exchanging the ITLRecovery certificates.

CAPF certificates

CAPF certificates need to be exchanged if Locally Significant Certificates (LSC) are installed on the phones and the phones are configured in encrypted mode (encrypted media and signaling). CAPF certificates also need to be exchanged if TFTP file encryption is configured on the phones. This is true whether mixed mode is enabled using the USB eTokens or the CLI (tokenless) method and whether the CAPF certificates are self-signed or signed by the same CA. CAPF certificates are exchanged when using the Bulk Certificate Management tool with the option to exchange “all” certificates between the Unified CM clusters.

3. Unified Communications and Cisco Adaptive Security Appliance

The CTL client with the hardware USB eTokens provides the ability to add Cisco Adaptive Security Appliance (ASA) certificates to the CTL file. This was designed for the ASA TLS proxy for encrypted voice inspection feature. Unfortunately, this ability to add Cisco ASA certificates to the CTL file is not available with the CLI (tokenless) method in Unified CM releases prior to 12.0. Since the ASA TLS proxy for encrypted voice inspection feature is not supported with Unified CM release 11.0 and earlier, this could become a gap for the rare scenario where Unified CM release 10.x is deployed with the legacy ASA TLS proxy feature and where mixed mode is enabled using the CLI (tokenless) method. Note that this ability to add Cisco ASA certificates to the CTL file using the CLI (tokenless) method has been added in Unified CM release 12.0, should a need arise to do so. The ASA certificates would be added to the CTL file by adding them to the Phone-CTL-ASA-trust.

Note that the Cisco phone VPN functionality with Cisco ASA is a completely different feature and has different requirements. It does not require mixed mode. If mixed mode is enabled, it does not matter whether the hardware USB eTokens or CLI (tokenless) method was used and it does not require ASA certificates to be added to the CTL file.

Conclusion

Cisco has announced the end of sale of the Unified CM Admin Security Token KEY-UCM-ADMIN2-K9= and customers are encouraged to use the Unified CM CLI (tokenless) method when enabling Unified CM mixed mode.

Enabling mixed mode with the CLI (tokenless) method or migrating from the USB eTokens to the CLI (tokenless) method is very simple.

There are no known gaps using the CLI (tokenless) method in order to enable mixed mode, except for the rare scenario where Unified CM 10.x is deployed with the legacy ASA TLS Proxy for encrypted voice inspection feature.

References

[1] End-of-Sale and End-of-Life Announcement for the Cisco UCM Admin Security Token, 7.1 or Newer: https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-manager-callmanager/eos-eol-notice-c51-744595.html

[2] Security Guide for Cisco Unified Communications Manager: https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html

[3] Cisco Technical Assistance Center (TAC) Note: CUCM Mixed Mode with Tokenless CTL: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118893-technote-cucm-00.html

 

 

 

Learn more