Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

Unlike classic enterprise PKI deployments, the PKI topology in CUCM is not a single PKI
system. Instead of having a single certification authority (CA) that issues all certificates,
different types of certificates are issued by different entities:
• Self-signed certificates: CUCM services (Cisco CallManager, TFTP, and CAPF)
issue their certificates on their own.
• Certificates signed by the Cisco manufacturing CA: Some Cisco IP Phone models
(including Cisco IP Phone 797*, 794[125], and 796[125] and 7911 models) have
manufacturing installed certificates (MIC).
• Certificates signed by CUCM Certificate Authority Proxy Function (CAPF) or by
an external CA: Locally significant certificates (LSC) can be assigned to Cisco IP
Phones that have MICs and to Cisco IP Phone 7940 and 7960 models. LSCs are issued
either by the CUCM CAPF acting as a CA or from an external CA. If LSCs are issued by
an external CA, CAPF acts as a proxy for the CA toward the IP Phones.
NOTE External CAs are supported in Cisco Unified CallManager Release 4.0 or later,
Cisco Unified CallManager Release 5.1 or later, and CUCM 6.0 or later. Cisco Unified
CallManager Release 5.0 does not support external CAs.
Self-Signed Certificates
Figure 15-8 illustrates several IP telephony services with self-signed certificates.
CUCM PKI 403
The self-signed certificates shown in the figure are as follows:
• Each CUCM server running the Cisco CallManager service has a self-signed
certificate.
• CUCM TFTP servers have self-signed certificates.
• If the CAPF is used (needed for LSC), it has a self-signed certificate.
All these services act as their own PK.1 root.
Manufacturing Installed Certificates
Figure 15-9 shows the PKI that is used for MICs.
The PKI that is used for MICs has the following characteristics:
• Cisco IP Phones with MICs have a public and private key pair, a MIC for their own
public key, and a Cisco manufacturing CA certificate, all of which are installed during
production.
• The IP Phone certificate (MIC) is signed by the Cisco manufacturing CA.
The Cisco manufacturing CA is the PKI root for all MICs. Cisco IP Phones that have MICs
include the 7911, 7941/5, 7961/5, 7970, and 7971 models.
Figure 15-9 Manufacturing Installed Certificates (MIC)
Cisco CA
404 Chapter 15: Understanding Native CUCM Security Features and CUCM PKI
Figure 15-10 Locally Significant Certificates (LSC)
Cisco IP Phone 7940 and 7960 models do not have a MIC installed. They have to request
an LSC from the CAPF, which is signed in one of two ways:
• The CAPF can issue the certificate on its own (acting as a CA).
• The CAPF can issue proxy enrollment requests to an external CA, and the external CA
issues the certificate.
Cisco IP Phones that have MICs can also request an LSC from the CAPF. If a phone has a
MIC and an LSC, the LSC has higher priority.
The CAPF or an external CA is the root for all LSCs.
NOTE External CAs currently are not supported with CUCM Release 5.0.
Multiple PKI Roots in CUCM Deployments
As illustrated in Figure 15-11, several PKI topologies may coexist in CUCM deployments.
Note how there is no single root. Instead, there are multiple independent PKI topologies.
All of them have to be trusted by an IP Phone. Like the built-in root certificate store in a
web browser, IP Phones require a list of PKI roots they should trust. The Cisco Certificate
Trust List (CTL) is used for that purpose.
CUCM PKI 405
Figure 15-11 Multiple PKI Roots in CUCM Deployments
Cisco Certificate Trust List
The Cisco CTL is a list of certificate issuers (PKI roots) that a Cisco IP Phone needs to trust.
It is created by an application, the Cisco CTL client, as shown in Figure 15-12.
Figure 15-12 Cisco CTL
406 Chapter 15: Understanding Native CUCM Security Features and CUCM PKI
The Cisco CTL client collects certificates of PKI roots (including the certificates of the
Cisco CTL client, which are its security tokens), builds the Cisco CTL, and then signs
the list by using a security token.
NOTE A security token is like a "mini computer" that acts like a CA. It has a public and
private key, and a certificate, and it can sign data by using its private key. The private key
never leaves the token. An application such as the Cisco CTL client, which has data (the
Cisco CTL) that needs to be signed, first passes the data to the security token. Inside the
security token, the data is signed. Then the data, along with its signature, is returned to
the application.
The Cisco CTL needs to be updated (and signed again) only if there are any changes to one of
the PKI roots: the CallManager, TFTP, or CAPF services or Cisco CTL client (security tokens).
The Cisco CTL also acts as an authorization list that specifies what certificate can be used
for what purpose.
Cisco CTL Client Function
Figure 15-13 shows how the Cisco CTL client creates and signs the Cisco CTL:
Step 1 The Cisco CTL client obtains the certificates of all entities that issue
certificates (self-signed certificates only or certificates for other devices).
Step 2 The certificates of the Cisco CTL client itself have to be added to the list.
They are stored on security tokens (together with a public and private key
pair). A Cisco CTL must include at least two different security tokens
(for backup reasons). The recommendation is to have one security token
per administrator plus one spare security token.
Step 3 The certificates of the security tokens are added to the list one by one.
Step 4 The Cisco CTL client signs the list of these certificates, the Cisco CTL,
by using one of its security tokens that were added to the Cisco CTL.
Step 5 Finally, there is a single, trusted introducer in the system again: The Cisco
CTL client "introduces" trusted devices such as the TFTP or CUCM
servers. It does this not by signing their certificates, but by signing a list
of these trusted devices—all PKI roots that exist in the system.
CUCM PKI 407
Figure 15-13 Cisco CTL Client Function
NOTE The Cisco CTL can be compared to the root certificate store of a web browser.
Both are a list of trusted certificate-issuing entities.
The Cisco CTL usually includes these certificates:
• Cisco Unified Communications Manager CallManager certificates: Each Cisco
CallManager service has a self-signed certificate. It allows IP Phones to verify the
authenticity of the Cisco CallManager service during registration.
• TFTP server certificate: The TFTP server that provides the IP Phone with files, such
as the IP Phone image or the IP Phone configuration file, is trusted by the IP Phone only
if the TFTP server is listed in the Cisco CTL.
• CAPF certificate: When you are using LSCs, the CAPF issues certificates to the IP
Phones. The certificate of the CAPF allows the CAPF to authenticate to an IP Phone
during the enrollment. The IP Phone verifies that certificate by comparing it to the one
in the Cisco CTL.
408 Chapter 15: Understanding Native CUCM Security Features and CUCM PKI
• Cisco manufacturing certificate: MICs and the certificate of the security tokens
(storing the keys that are used by the Cisco CTL client) are issued by the Cisco
manufacturing CA. To allow the phone to verify certificates issued by this Cisco CA,
the phone needs the certificate of the Cisco manufacturing CA.
• Cisco CTL client certificate: The Cisco CTL client signs the CTL by using one of its
security tokens. The IP Phone must know the certificates of the Cisco CTL client (one
per security token) to allow the CTL's signature to be verified.
Initial CTL Download
After the Cisco CTL client has been used to create a Cisco CTL, IP Phones obtain the Cisco
CTL during the next boot, as shown in Figure 15-14.
The first download of a CTL to an IP Phone is not secure. The IP Phone accepts any Cisco
CTL. The reason for this is that the IP Phone cannot verify the signature of the Cisco CTL
because it does not yet know the public key of the Cisco CTL client (it does not know any
of the security tokens).
This problem occurs only at initial deployment, when the phone does not yet have a local
Cisco CTL. In this case, any security token could pretend to be a valid security token of the
Cisco CTL client. An attacker could either replace the Cisco CTL file on the TFTP server
with a falsified file or change the Cisco CTL file in the path between the IP Phone and the
TFTP server.
Figure 15-14 Initial CTL Download
The problem can be solved by downloading the initial Cisco CTL over a trusted network to
ensure that no falsified initial Cisco CTL is loaded to the phone. When the phone has a valid
CUCM PKI 409
Cisco CTL, it trusts new Cisco CTLs only if they are signed using a security token that is
already known to the IP Phone.
If the Cisco CTL file in the IP Phone is erased, the same problem occurs. Again, you must
ensure that the next Cisco CTL download is done over a trusted network path, because the
IP Phone will blindly accept any Cisco CTL.
After the IP Phone is deployed, it is usually difficult to trust the network path between the
phone and CUCM. Therefore, a user should not be able to erase the initially installed Cisco
CTL. There are two ways to remove a CTL from an IP Phone: a factory reset or by using
the IP Phone Settings menu. A factory reset is not simple, but using the Settings menu is
rather easy. To prevent users from using the Settings menu to remove the CTL, you should
disable settings access at the phone.
NOTE When you use authentication strings as the authentication method during CAPF
phone certificate operations, you have to enable settings access during the enrollment.
After successful enrollment, you should disable settings access again. This process is
explained in detail in the next section.
IP Phone Verification of a New Cisco CTL
Every time an IP Phone receives a new Cisco CTL, the new Cisco CTL is verified, as shown
in Figure 15-15. The new Cisco CTL is accepted by the IP Phone only if it was signed by
the Cisco CTL client with one of its security tokens.
Figure 15-15 IP Phone Verification of a New Cisco CTL
410 Chapter 15: Understanding Native CUCM Security Features and CUCM PKI
The phone can verify the signature by using the public key (the certificate) of the Cisco
CTL client (the certificate of the appropriate administrator token), which must be included
in the currently installed ("old") Cisco CTL.
This certificate of the security token is signed by the Cisco manufacturing CA. This
signature is also validated by using the certificate of the Cisco manufacturing CA, which
also must be included in the currently installed Cisco CTL.
This process works well after an initial Cisco CTL has been deployed to the Cisco IP Phones.
IP Phone Usage of the CTL
The Cisco CTL inside a Cisco IP Phone is used in the following situations:
• Encrypted signaling: When SCCP or SIP over TLS is used, two-way certificate-based
authentication is performed. The Cisco IP Phone verifies the received, self-signed
certificate of the Cisco CallManager service against its Cisco CTL.
• LSC enrollment: When a Cisco IP Phone requests an LSC (enrolls with the CAPF by
using TLS), CAPF-to-IP phone authentication in TLS is certificate-based. The Cisco
IP Phone verifies the received, self-signed certificate of the CAPF against its Cisco CTL.
• Signed IP phone configuration files: When signed configuration files are used, the IP
Phone configuration file is signed with the private key of the TFTP server. The Cisco
IP Phone needs to know the corresponding public key to be able to decrypt the
configuration file.
• Signed Cisco CTL file: As stated earlier, Cisco CTL files are signed by the Cisco CTL
client. The Cisco IP Phone only accepts a new Cisco CTL file if it was signed by one
of the security tokens of the Cisco CTL client. To check whether the new Cisco CTL
file has been signed by an authorized token and to verify the signature of the new Cisco
CTL file, the Cisco IP Phone needs to know the trusted Cisco CTL client certificates
(certificates of the Cisco CTL client security tokens).
PKI Topology with Secure SRST
Figure 15-16 illustrates a portion of the PKI topology that is used by secure SRST when an
IP Phone has a conversation through a voice gateway.
An SRST gateway at a remote site can provide call control services in the event of central
site failure. If cryptography is used with CUCM, the same security services are often
required in SRST mode as well.
CUCM PKI 411
Secure SRST allows Cisco IP Phones to continue using TLS for signaling and SRTP for
media exchange when in SRST failover mode. Secure SRST therefore prevents impersonation
of the SRST gateway and IP Phones, as well as falsification and eavesdropping of
signaling and media packets.
Figure 15-16 IP Secure SRST Overview
IP Phone
IP Phone
The SRST gateway acts like a Cisco CallManager service when in failover mode, because
it provides signaling to the IP Phones. Therefore, it needs its own certificate, as shown in
Figure 15-17. It will use this certificate to authenticate itself to the phone in a TLS protected
signaling session. The SRST gateway obtains this certificate from a CA, either via Simple
Certificate Enrollment Protocol (SCEP) or via manual cut-and-paste enrollment performed
by the administrator.
Figure 15-17 PKI Topology with Secure SRST
Certificate Trust List (CTL)
IP Phone
412 Chapter 15: Understanding Native CUCM Security Features and CUCM PKI
The SRST gateway cannot generate a self-signed certificate or enroll with the CAPF.
Instead, it has to obtain a certificate from a proper CA. This CA can be a Cisco IOS CA,
which can even run on the same router.
Trust Requirements with Secure SRST
IP Phones and the secure SRST gateway need to trust each other when in SRST mode.
When the IP Phone registers with the secure SRST gateway, the secure SRST gateway
presents its certificate to the IP Phone. This certificate was issued by an external CA, which
the IP Phone does not know about. The IP Phone does not verify the certificate of the secure
SRST gateway by its signature. Instead, CUCM obtains the certificate of the secure SRST
gateway during configuration time and then adds it to the phone configuration file. After
CUCM receives the certificate of the SRST gateway, the certificate has to be out-of-band
verified.
The IP Phone can now check the certificate received from the secure SRST gateway against
the one found in its configuration file.
On the other hand, the IP Phone has to authenticate to the secure SRST gateway. IP Phone
certificates are issued either by CAPF (in case of LSCs) or by a Cisco manufacturing CA
(in case of MICs). Therefore, the secure SRST gateway must know CAPF and Cisco
manufacturing CAs. These certificates are added manually to the secure SRST gateway.
The IP Phone can now check the signature of received IP Phone certificates by using the
public key of the issuer.
This process is illustrated further in the next chapter.
Secure SRST: Certificate Import: CUCM
When the secure SRST gateway is configured, CUCM pulls the SRST gateway certificate
from the credentials service over the network. The authenticity of the certificate is verified
out-of-band. CUCM presents the fingerprint (Secure Hash Algorithm 1 [SHA-1] hash) of
the received certificate. As a result of adding the SRST Reference, as shown in Figure 15-18,
the administrator sees an Internet Explorer (IE) popup and must manually compare the
entries with the known authentic fingerprint of this certificate.
Alternatively, this initial contact between CUCM and the SRST router could be performed
over a trusted network. Then no out-of-band verification is needed.
CUCM PKI 413
Figure 15-18 Secure SRST: Certificate Import: CUCM
414 Chapter 15: Understanding Native CUCM Security Features and CUCM PKI
On the SRST router, the Cisco manufacturing certificates and the CAPF certificate have to be
pasted into the configuration of the gateway. The certificates are copied from CUCM manually
into the SRST gateway configuration and therefore do not need to be out-of-band verified.
Certificate Usage in Secure SRST
Figure 15-19 illustrates the complete process of certificate usage with secure SRST.
Certificate usage in secure SRST consists of the following steps:
• The scenario begins with a secure CUCM deployment that includes IP Phones with
certificates issued by either Cisco manufacturing or the CAPF.
• The secure SRST gateway enrolls with a CA.
At this point, the IP Phones and the secure SRST gateway have certificates.
• When the secure SRST gateway into the CUCM configuration is added, CUCM
obtains the certificate of the secure SRST gateway from the gateway and manually
verifies it out-of-band.
• If the verification is okay (and the administrator accepts the certificate), CUCM adds
the certificate to IP Phone configuration files.
Summary 415
• The Cisco manufacturing and CAPF certificates are manually copied into the secure
SRST gateway configuration.
Now both sides have the means to verify each other:
• When an IP Phone registers with the secure SRST gateway by using TLS, the secure
SRST gateway sends its certificate to the IP Phone.
• The IP Phone does not verify the signature of that certificate. Instead, it compares the
certificate itself against the one in the phone configuration file. If the thumbprints of
these two are identical, the received certificate is considered to be authentic.
• The IP Phone presents its certificate to the secure SRST gateway.
• The SRST gateway has the certificate of the issuer of the received phone certificate
(either CAPF or Cisco manufacturing) in its configuration. It can now verify the
signature of the certificate of the IP Phone. If the signature is valid, the received
certificate is considered to be authentic.
The IP Phone and secure SRST can now establish the TLS session that is used for
authenticated and encrypted signaling. The result is a secure communication between
the IP Phone and the SRST gateway.