Lab Guide

Cisco dCloud

Collaboration Security for the Enterprise

On-Premises Preferred Architecture
12.5 – Lab Guide

Created by Collaboration Technology Group TME, dCloud Collaboration, and Cisco Sales Teams
Last Updated: 08-October-2019

About This Lab

Upon completion of all scenarios, users will gain a good working knowledge of the latest Unified CM
collaboration capabilities and the security implications including SLR, SIP OAuth, end-to-end encrypted calling
with MRA, ICE media path optimization, online CA mode, granular TLS/SSH cipher control, secure calling with
CUBE, and secure phone on-boarding. This guide for the preconfigured demonstration includes:

About This Lab

Requirements

About This Solution

Topology

Session Users

Getting Started

Scenario 1. Specific License Reservation

Scenario 2. SIP OAuth (line side) for On-Premises Jabber Encrypted Calling

Scenario 3. Encrypted Calling with Expressway MRA and ICE Media Path Optimization

Scenario 4. Online CA Mode for Automatic Enterprise CA Endpoint Certificate Enrollment

Scenario 5. Unified CM TLS/SSH Interface Granular Administrative Cipher Control

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 185
Lab Guide
Cisco dCloud

Scenario 6. Secure Integration with Cisco Unified Border Element (CUBE)

Scenario 7. Secure Hardware Endpoint Onboarding

Appendix A. ECC Certificates for 7800 and 8800 Series Endpoints

What’s Next?

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 185
Lab Guide
Cisco dCloud

Limitations

In production environments, it is best practice to have the Expressway-E certificate signed by a Public
Certificate Authority (CA). In this lab, the Expressway-E is on an internal network and not exposed to the
Internet. As such, the enterprise Microsoft CA in this lab was used to sign the Expressway-E certificate. This
internal network and the enterprise CA signed Expressway-E certificate are intentionally introduced to simplify
the lab/demo rollout and maximize dCloud session capacity. From a technical perspective, Jabber clients can
handle an Enterprise CA signed Expressway-E certificate, but Cisco phones and video devices used in MRA
mode require that Expressway-E have a supported public CA-signed certificate.

Requirements
There are no hardware requirements for this lab. It is meant to be done without the need for endpoints or
routers.

NOTE: If you choose to connect a router to this lab, you can then connect 7800 and 8800 series hardware
phones over the VPN connection and perform the secure hardware endpoint onboarding (Scenario 7, section B)
as well as ECC certificate enrollment (Appendix A).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 185
Lab Guide
Cisco dCloud

About This Solution

In the past, the deployment of end-to-end authentication and encryption in Cisco Collaboration has not been
widespread. Many customers chose to consider their internal networks as secure and that the privacy of their
communications as being subsequently assured. Over recent years, this mind set has begun to shift, and more
and more customers have started to investigate leveraging cryptography as an additional layer of defense. Also,
with the rise in “VPN less” access technologies, the requirement for signaling and media privacy has become
standard for any device or client that is traversing the firewall perimeter to access corporate collaboration
services.

With the above in mind, this collaboration security lab educates users on the practical steps required to enable
the latest security features and functions available with the Collaboration Solution Release (CSR) 12.5,
including:

• Cisco Jabber SIP OAuth based authorization and encryption for both SIP signaling and RTP media and MRA
media path optimization with direct interactive connectivity establishment (ICE).

• Online CA mode with automatic Microsoft Certificate Authority certificate enrollment as an alternative to
Certificate Authority Proxy Function CA issued endpoint locally significant certificates (LSCs).

• Administrative granular cipher control for all Unified CM TLS/SSH interfaces.

• Specific License Reservation (SLR) as an alternative to Cisco Smart Software Manager satellite for highly
secure deployments with strict airgap requirements between the DC and cloud-based services.

• Secure hardware endpoint onboarding with activation codes.

This collaboration security lab is based in part on the Preferred Architecture for Cisco Collaboration 12.x On-
Premises Deployments as documented in the Cisco Validated Design (CVD). The CVD is available at
https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/12x/120/collbcvd.html
Some of the topics covered in this lab are not part of the documented Preferred Architecture; however, they
have been included here because they are new security-related features that may be of value to some
customer deployments.

• Scenario 1: Specific License Reservation

This scenario explores specific license reservation (SLR) as an option for highly secure deployments where
applications in the DC are unable to communicate with Internet-based services.
(Components: Unified CM, Unity Connection)
• Scenario 2: SIP OAuth (line side) for On-Premises Jabber Encrypted Calling

This scenario investigates configuration of OAuth2 for SIP line side enabling encrypted calling for Jabber
without the need for certificates or the Unified CM cluster being in mixed-mode.
(Components: Unified CM, Jabber)

• Scenario 3: Encrypted Calling with Expressway MRA and ICE Media Path Optimization

This scenario examines Jabber encrypted calling through Expressway Mobile and Remote Access (MRA) with
SIP OAuth. After looking at encryption, point-to-point media path optimization with ICE is enabled and verified
(Components: Unified CM, Expressway, Jabber)

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 185
Lab Guide
Cisco dCloud

• Scenario 4: Online CA Mode for Automatic Enterprise CA Endpoint Certificate Enrollment

This scenario covers configuration and operation of the new Online CA endpoint certificate enrollment mode
enabling automatic enrollment with the enterprise certificate authority.
(Components: Unified CM, Microsoft Certificate Authority, Jabber)

• Scenario 5: Unified CM TLS/SSH Interface Granular Administrative Cipher Control

This scenario investigates Unified CM granular cipher control configuration for administrators.
(Components: Unified CM)

• Scenario 6: Secure Integration with Cisco Unified Border Element (CUBE)

This scenario covers the concepts and configuration for secure integration between CUBE and Unified CM (TLS,
certificates).
(Components: Unified CM, CUBE (vCUBE), Microsoft Certificate Authority)

• Scenario 7: Secure Hardware Endpoint Onboarding

The scenario discusses the configuration and operation of secure hardware endpoint onboarding with system
generated 16-digit activation codes.
(Components: Unified CM, Expressway)

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 185
Lab Guide
Cisco dCloud

Topology
This overall topology for this lab is shown in the figure below. The topology consists of:
• An on-premises “internal” network where the collaboration applications (e.g. Unified Communications
Manager) and other application servers (e.g. Microsoft Active Directory / Certificate Authority / Domain
Name Service [DNS]) are deployed.
• A remote “external” network representing the outside world available/connected to the Internet. Reaching
the internal on-premises collaboration applications and services requires connectivity from this network
through Expressway Mobile and Remote Access (MRA).
• Four Windows Workstations (two on-premises and two remote) with Cisco Jabber for Windows serving as
the endpoints used throughout this lab. The on-premises workstations are also used for all configuration as
outlined in this guide.

This lab includes preconfigured users and components to illustrate the features and functions of the solution.
Most components are fully configured with predefined administrative user accounts. Refer to the Server and
Application Credentials and Details table (Table 1) below for application server IP addresses and administration
account credentials for accessing lab components and preforming the required configuration and operations.
The appropriate credentials and hostnames are also provided throughout the lab guide as required for each set
of steps.

Note: You might not use all the components listed in Table 1 for this lab.

Refer to the Session Users section below for lab user information including user name, associated endpoints,
assigned directory numbers, and account credentials for completing lab exercises.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 185
Lab Guide
Cisco dCloud

Name Description Host Name (FQDN) IP Address Username Password

Active Microsoft Windows Server ca.dcloud.cisco.com 198.18.133.1 administrator dCloud12345!

Directory, 2016
Certificate
Authority, DNS

Certificate Microsoft Windows Server ca2.dcloud.cisco.com 198.18.133.2 administrator dCloud12345!

Authority 2016
(ECDSA)

Unified CM Cisco Unified Communications cucm1.dcloud.cisco.com 198.18.133.3 administrator dCloud123!

Manager 12.5(1) SU1

Unified CM IM & Presence 12.5(1) SU1 cup1.dcloud.cisco.com 198.18.133.4 administrator dCloud123!

IM & P

Unity Unity Connection 12.5(1) SU1 cuc1.dcloud.cisco.com 198.18.133.5 administrator dCloud123!

Connection

Expressway-C Expressway X12.5(2) exp-c- 198.18.133.152 admin dCloud123!

1.dcloud.cisco.com

Cisco Meeting Cisco Meeting Server 2.5 cms1.dcloud.cisco.com 198.18.134.175 admin dCloud123!
Server

Workstation 1 Windows Workstation 10 with wkst1.dcloud.cisco.com 198.18.133.36 amckenzie dCloud12345!

Jabber 12.6(1)

Workstation 2 Windows Workstation 10 with wkst2.dcloud.cisco.com 198.18.133.37 aperez dCloud12345!

Jabber 12.6(1)

CUBE Cisco Unified Border Element, cube1.dcloud.cisco.com 198.18.133.213 admin dCloud123!

IOS XE 16.6(1) (Internal, GE 1)

198.18.2.213
(External, GE 2)

Expressway-E Expressway X12.5(2) exp-e- 198.18.1.152 admin dCloud123!

1.dcloud.cisco.com (Internal NIC)

198.18.2.152
(External NIC)

DNS (external) Microsoft Windows Server dns- 198.18.2.11 administrator dCloud12345!

2016 ext.dcloud.cisco.com

Workstation 3 Windows Workstation 10 with wkst3.dcloud.cisco.com 198.18.133.38 mcheng dCloud12345!

Jabber 12.6(1) (Internal NIC)

* 198.18.2.38
(External NIC)

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 185
Lab Guide
Cisco dCloud

Workstation 4 Windows Workstation 10 with wkst4.dcloud.cisco.com 198.18.133.39 wwhitman dCloud12345!

Jabber 12.6(1) (Internal NIC)

* 198.18.2.39
(External NIC)

Asterisk (*) = active interface for dual interface components (you will not use the inactive interface for this lab)
No asterisk = both interfaces active (dual interface components)

Session Users
The table below contains details on preconfigured users available for your session.

User Name User ID Password Endpoint Devices Phone Extension

ON-PREMISES / INTERNAL

Adam Mckenzie amckenzie dCloud12345! CSFAMCKENZIE +1 408 555 1116 1116

(WKST1 – Jabber)

Anita Perez aperez C1sco12345! CSFAPEREZ +1 919 555 2132 2132

(WKST2 – Jabber)

REMOTE / EXTERNAL

Monica Cheng mcheng dCloud12345! CSFMCHENG +1 408 555 1119 1119

(WKST3 – Jabber)

Walt Whitman wwhitman dCloud12345! CSFWWHITMAN +1 919 555 2130 2130

(WKST4 – Jabber)

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 185
Lab Guide
Cisco dCloud

Getting Started

Follow the steps to schedule a session of the content and configure your presentation environment.

Initiate your dCloud session. [Show Me How]

NOTE: It can take up to 45 minutes for your session to become active.

You should connect directly to the session from a stand-alone laptop or other device. Install and access
Cisco AnyConnect VPN client and enter the AnyConnect credentials provide in the Cisco dCloud UI. [Show
Me How]

Once the AnyConnect VPN client is connected, use the Remote Desktop Protocol (RDP) client on your
laptop or device to connect to appropriate lab servers / workstations as instructed in this lab guide. [Show
Me How] Perform all operations and configuration from the appropriate workstation as indicated in this lab
guide.

The Jabber clients running on the workstation virtual machines in the demo pod are the endpoints for this lab. In
addition to connecting to the workstations for endpoint operations, you will also use the web browsers and
other applications on the workstations (as indicated in this lab guide) to perform all lab operations and
configuration.
How to connect:

Start RDP client on your laptop or desktop.

Enter the appropriate hostname / IP (as indicated in this lab guide) in the computer/host field of your RDP
client.

When prompted, enter the appropriate credentials as indicated in this lab guide to complete the
connection to the remote server/workstation.

REMINDER: When using RDP to connect to Windows Servers/Workstations in this lab, you must initially specify
the domain (DCLOUD\) when providing login credentials. For example, when connecting to Workstation 1
(WKST1), on initial log in, you should specify the username as DCLOUD\amckenzie.

Logins to workstations and servers are user-specific. Login to each workstation/server with the login
credentials specified in the lab guide.

NOTE: You will know you have logged in with the correct domain and user account if the desktop background is
gray and it is labeled with the name of the workstation or server you are connecting to. If the desktop
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 185
Lab Guide
Cisco dCloud

background of the workstation/server you login to is the default blue and has no label, you have logged in using
the wrong account or without specifying the domain (DCLOUD\).

Here is a summary of four workstations you will connect to in this lab:

• Workstation 1: wkst1.dcloud.cisco.com (198.18.133.36)
Username: DCLOUD\amckenzie / Password: dCloud12345!
• Workstation 2: wkst2.dcloud.cisco.com (198.18.133.37)
Username: DCLOUD\aperez / Password: dCloud12345!

• Workstation 3: wkst3.dcloud.cisco.com (198.18.2.38)

Username: DCLOUD\mcheng / Password: dCloud12345!

• Workstation 4: wkst4.dcloud.cisco.com (198.18.2.39)

Username: DCLOUD\wwhitman / Password: dCloud12345!

NOTE: WKST3 and WKST4 are deployed by default off-net (outside the enterprise). The Cisco Jabber clients
for Monica Cheng (WKST3) and Walt Whitman (WKST4) are capable of leveraging Expressway mobile and
remote access (MRA).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 185
Lab Guide
Cisco dCloud

Scenario 1. Specific License Reservation

Value Proposition: Specific License Reservation (SLR) enables collaboration with smart licensing deployments
for highly secure environments.

In order to enable media encryption on collaboration systems such as Cisco Unified Communications Manager
(Unified CM) and Unity Connection, the systems must be properly licensed from a user and device perspective
and must also have an encryption license. Cisco Smart Software Licensing, first introduced into the Cisco
Collaboration portfolio with the Collaboration System Release (CSR) 12.0, simplifies acquisition and
management of user, device, and encryption licensing by periodically synchronizing collaboration systems with
the online Cisco Smart Software Manager (CSSM) service and dynamically applying licenses to (or removing
from) the systems as required. For some customers, communication between their collaboration systems (for
example, Unified CM) and an online service on the Internet is not permitted due to security policy.

While communication between collaboration applications such as Unified CM and the online CSSM service may
be proxied through an HTTP web proxy or even an on-premises CSSM satellite service for enhanced security,
for highly secure customers this may still not be enough. In some cases, this restriction has prevented
customers from upgrading to CSR 12.0 versions. For this reason, with CSR 12.5, SLR was introduced for
collaboration applications allowing a fully offline method for licensing a collaboration system with Smart
Licensing.

Summary

There are two sections in this scenario:

A. Review Preliminary Specific License Reservation (SLR) Operations for Unified CM [Review Only]

B. Complete SLR on Unified CM

The figure below shows the topology and relevant components for this scenario.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 185
Lab Guide
Cisco dCloud

Collaboration Licensing with Cisco Smart Software Licensing

Unified CM and other collaboration applications, including Unified CM IM&P, Unity Connection, and Cisco
Emergency Responder began supporting Cisco Smart Software Licensing with the 12.0 Collaboration System
Release (CSR). In addition to smart licensing, encryption licensing was also introduced with the 12.0 CSR (this
was also backported to 11.5[1] SU3). To enable encryption and maintain a production collaboration system
once the 90-day evaluation period has expired, each of these systems must be properly licensed using Cisco
Smart Software Licensing.

The basic licensing flow for Cisco Smart Software Licensing involves the licensing service running on the
collaboration application communicating with the online Cisco Smart Software Manager (Cisco SSM) service
available over the Internet. The online smart licensing service applies valid licenses from the organization’s
smart licensing pool and provides authorization to the collaboration applications over the network to the system
such that encryption may be enabled, and the system remains operational and in-compliance. Failure to
properly license a system will result in reduced functionality, including an inability to enable media encryption or
change system configuration including adding users and devices.
The figure below shows Cisco Smart Software Licensing for collaboration applications and Cisco Smart
Software Management (CSSM).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 185
Lab Guide
Cisco dCloud

The requirement that the collaboration applications must communicate with the CSSM service presents
challenges for collaboration applications in highly secure deployments. For organizations that have restrictions
against internal applications communicating with services and hosts directly over the Internet, there are
alternative methods for enabling smart licensing.

In addition to direct connections between the on-premises collaboration applications and the Internet-based
Cisco SSM, the following alternative smart licensing methods are available:

• HTTP Proxy

• Cisco Smart Software Manager Satellite

• Specific License Reservation

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 185
Lab Guide
Cisco dCloud

The figure below shows Smart Licensing connection options for collaboration applications.

In this scenario, you will explore the Specific License Reservation method (SLR), which is new with the 12.5
Collaboration System Release (CSR).

There are four basic steps for licensing collaboration applications with SLR.

Administrator enables license reservation and generates a reservation code.

Reservation code submitted, and license(s) selected at Cisco SSM.

SSM generates authorization code.

Administrator installs authorization code to complete license reservation.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 185
Lab Guide
Cisco dCloud

The figure below shows Specific License Reservation information.

It is worth pointing out that while this method of licensing is highly secure, it is a manual operation and if the
required system license quantity or type exceeds the quantity or type of license available in the SLR, a new SLR
must be generated to replace the existing reservation. Further, because SLRs are explicitly tied to a set of
licenses in the Smart License account, unused licenses on a system with SLR will not be available to other
systems on the same Smart License account.

NOTE: SLR is not supported with Apple Push Notification Service (APNs) for iOS clients or with secure
onboarding with activation code over Mobile and Remote Access. Both features require access to cloud
services and SLR is specifically designed for systems that are not able to access cloud services, as such these
features are not compatible with nor supported with SLR deployments.

In the following sections, you will review the steps required to enable SLR for a collaboration application and
complete the license reservation on the Unified CM system.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 185
Lab Guide
Cisco dCloud

A. Review Preliminary Specific License Reservation (SLR) Operations for Unified

CM [Review Only]

In this section, you will review the specific license reservation (SLR) for Unified CM (cucm1.dcloud.cisco.com).
A license reservation has already been started for you.

IMPORTANT: The following operations have already been completed for you - you do not need to perform any
of these operations. Please review the information below, including the figures, before proceeding to the next
section entitled Complete SLR on Unified CM.

Confirm the system did not have any valid licenses and was in evaluation mode by browsing to Unified CM
administrative web interface to. The Unified CM system (System > Licensing > License Management) did
not have any valid licenses and was Unregistered and in Evaluation Mode. Because the system was not
licensed, Export-Controlled Functionality was Not Allowed. This meant the cluster could not be enabled for
SIP OAuth or moved to mixed-mode as both capabilities enable media encryption, which is export-
controlled. Note the system required four (4) Enhanced Plus user licenses to be properly licensed.

IMPORTANT: Your system will NOT look like the figure below. The figure shows what your system looked like
before the specific license reservation process was started. Your system has a pending-specific license
reservation, which you will complete in the next section. This section is for your review, so you understand
the full SLR process.

It was previously confirmed the system did not have any valid licenses and was in evaluation mode by
connecting to the SSH interface and entering the command show license status at the command line.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 185
Lab Guide
Cisco dCloud

Just as shown on the web administration interface, the system was not licensed and media encryption
(Export-Controlled Functionality) was not possible on this system.

IMPORTANT: Your system will NOT look like the figure below. The figure shows what your system looked like
before the specific license reservation process was started. Your system has a pending-specific license
reservation, which you will complete in the next section. This section is for your review, so you understand
the full SLR process.

Enable the system for smart license reservations by entering the command:
license smart reservation enable

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 185
Lab Guide
Cisco dCloud

Generate a license reservation request by entering the command:

license smart reservation request

Copy and paste this reservation request code to the clipboard. This code is entered / pasted at the Cisco
Smart Software Manager portal, as shown later in this step.
(See Reminder below.) Access the Cisco Smart Software management portal at
https://software.cisco.com/ and log in using appropriate credentials for organization’s smart account.

REMINDER: This section is just for review. You do NOT need to go to https://software.cisco.com. This has
already been done for you.

Once logged in, click the Smart Licensing Software link to load the Smart Licensing portal.

Select Inventory from the top menu to display the license and product instances.

Select the Licenses tab to display the list of licenses available on virtual account. After reviewing in use and
available licenses information, start a reservation by clicking License Reservation.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 185
Lab Guide
Cisco dCloud

Follow the Smart License Reservation wizard. The first step is to enter the reservation request code
generated previously and copy to the local clipboard. Paste the code from the clipboard and click Next.

Select the license(s) to include in the reservation by checking the Reserve a specific license box and
review the list of available licenses for the product type. As noted previously, the Unified CM system in this
lab has four (4) active users requiring Enhanced Plus licenses. Enter “4” in the Quantity to Reserve field
and click Next.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 185
Lab Guide
Cisco dCloud

Review the license reservation to confirm the right type and quantity of license has been selected. Click
Generate Authorization Code.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 185
Lab Guide
Cisco dCloud

Click Download as File to download the authorization code to the local computer. You will install this
authorization code file to the Unified CM system in the next section.

B. Complete SLR on Unified CM

IMPORTANT: You must complete the operations in the remaining steps of this scenario to properly license the
Unified CM system. Failure to do so will mean that later scenarios will not work.

Complete the specific license reservation (SLR) by installing the license reservation file. Begin by using the
local RDP client to open an RDP connection to WKST1 (wkst1.dcloud.cisco.com / 198.18.133.36) and
login with username and password: DCLOUD\amckenzie and dCloud12345!

NOTE: Do not forget to include the domain DCLOUD\ when entering the username.

Open the Firefox browser on WKST1 (wkst1.dcloud.cisco.com) and browse to the Unified CM
Administration portal (https://cucm1.dcloud.cisco.com/ccmadmin/). Login with username / password:
administrator / dCloud123!.
The system is enabled for license reservation and pending installation of a valid authorization code.
Navigate to System > Licensing > License Management and note that a license reservation is pending and
needed for four Enhanced Plus users. You will also notice that Export-Controlled Functionality is Not
Allowed on the system, which means media encryption will not be possible until the system is properly
licensed.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 185
Lab Guide
Cisco dCloud

The license reservation file has already been downloaded and saved to the Documents directory of WKST1
(wkst1.dcloud.cisco.com). Before proceeding, you must start the local SFTP server on WKST1.

Double-click the freeFTPd icon on the desktop to open the server console. Click SFTP on the
left-hand menu, click Start to start the SFTP server on the local workstation.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 185
Lab Guide
Cisco dCloud

Once the server status changes to Running... in the freeFTPd Settings window, double-click the PuTTY icon

on the desktop to launch the PuTTY client. Enter cucm1.dcloud.cisco.com in the Host Name (or
IP Address) field. Click Open.

Click Yes to cache the ssh-rsa2 key.

Log in to Unified CM SSH session with username/password: administrator / dCloud123!

Enter the command show license status at the command line. Just as shown on the web administration
interface, note again the system has a pending license reservation and media encryption (Export-Controlled
Functionality) that is not currently allowed on this system.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 185
Lab Guide
Cisco dCloud

The evaluation mode remaining time in figure above may not match the remaining time for your system.

Enter the command:

license smart reservation install-file
sftp://wkst1.dcloud.cisco.com:22/cucm1_SLR_AuthorizationCode.txt

When prompted for username / password, enter: demo / cisco

You will receive the message: “Authorization code installed successfully.” This indicates the license
reservation was successfully added to the system (see figure above).

NOTE: It can take as long as two minutes for the reservation file to install. If the license reservation file
installation fails and a message is displayed indicating the authorization code is invalid, this is often because the
password was mistyped. Re-enter the command license smart reservation install-file
sftp://wkst1.dcloud.cisco.com:22/cucm1_SLR_AuthorizationCode.txt command again and ensure you
enter the correct password (cisco).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 185
Lab Guide
Cisco dCloud

Confirm Unified CM has sufficient licensing and export-controlled functionality is allowed.

Enter show license status at the command line to confirm the Unified CM system is now licensed, and
that export-controlled functionality is allowed. The system is now properly licensed [REGISTERED –
SPECIFIC LICENSE RESERVATION / AUTHORIZED – RESERVED] and export-controlled encryption is now
Allowed.

Return to the Firefox browser and the Unified CM Administration web portal
(https://cucm1.dcloud.cisco.com/ccmadmin/) and log in again, if required (username / password:
administrator / dCloud123!). Navigate back to System > Licensing > License Management to re-confirm the
system is properly licensed.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 185
Lab Guide
Cisco dCloud

The registration, authorization, and usage details timestamps on your system will not match the timestamps
in the figure above.

Now that you have confirmed and completed specific license reservation on Unity Connection and Unified
CM, you have concluded this scenario. Enter exit at the command line to end and close the PuTTY SSH
session to Unified CM. Return to the freeFTPd server console and click Stop to stop the SFTP server and
then click the X in the upper right-hand corner to close the console.
*** END OF SCENARIO ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 185
Lab Guide
Cisco dCloud

Scenario 2. SIP OAuth (line side) for On-Premises Jabber Encrypted Calling
Value Proposition: Simplify Cisco Jabber encrypted calling deployments with SIP OAuth.

Building on the enhanced OAuth capabilities introduced in CSR 12.0 for Jabber client authorization, CSR 12.5
extended the use of OAuth beyond just service authorization to SIP line side in order to secure Jabber client
signaling and media. With SIP OAuth, Jabber SIP-based call flows can now be secured with encrypted SIP TLS
signaling and encrypted sRTP media without requiring CAPF enrollment to install a locally significant certificate
(LSC) on the client device. Further, in some deployments, this eliminates the requirement for putting Unified CM
clusters into mixed-mode.

Summary

This scenario examines SIP OAuth for on-premises Jabber secure line side encryption. This scenario is divided
into the following two sections:

A. Review Existing Environment: OAuth with Refresh Login and Unencrypted Calling

B. Enable SIP OAuth and Validate Encrypted Calling

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 185
Lab Guide
Cisco dCloud

Steps

A. Review Existing Environment: OAuth with Refresh Login and Unencrypted

Calling

Before enabling SIP OAuth, you should first confirm that OAuth with refresh login flow (a pre-requisite for SIP
OAuth) is enabled for the various collaboration applications and confirm basic on-premises Jabber client
connectivity and unencrypted calling.

NOTE: The OAuth with Refresh Login Flow feature was introduced with CSR 12.0 and applies to 11.5(1) SU3+
and 12.0 and above versions of collaboration applications (Unified CM, Unified CM IM&P, Unity Connection),
X.8.10 and above versions of Expressway, and Jabber 11.9 and above clients. This feature extends the use of
OAuth, a standard-based authorization framework (RFC 6749) enabling client applications to securely access a
service or API on behalf of a user, to all Jabber client connections. The OAuth framework has been used for
Single Sign-On (SSO) enabled deployments previously, but with the OAuth with Refresh Login Flow, the OAuth
framework was extended to other non-SSO connection types and is supported across all authentication
methods (SSO, local Unified CM end-user database, and LDAP directory).

To confirm OAuth with Refresh Login Flow is enabled on Unified CM, if not already connected, open an RDP
connection to WKST1 (wkst1.dcloud.cisco.com / 198.18.133.36) and login with username / password:
DCLOUD\amckenzie / dCloud12345!
From the Firefox web browser on WKST1, browse to the Unified CM Administration interface at
https://cucm1.dcloud.cisco.com/ccmadmin/ and login with username / password: administrator /
dCloud123!. Once logged in, navigate to System > Enterprise Parameters and scroll down to the SSO and
OAuth Configuration section near the bottom of the parameters page.

Confirm the parameter OAuth with Refresh Login Flow is already set to Enabled on Unified CM.

Confirm this is a non-secure mode cluster and SIP OAuth is not enabled. While still on the Enterprise
Parameters page (System > Enterprise Parameters), scroll up to the Security Parameters section. The
Unified CM cluster is in non-secure mode (Cluster Security Mode = 0) and SIP OAuth is not enabled
(Cluster SIPOAuth Mode = Disabled).

Because Jabber users will utilize other services besides just calling, it is a good idea to ensure OAuth with
Refresh Login Flow is enabled for the other collaboration applications. Since the Unified CM and IM & P nodes
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 185
Lab Guide
Cisco dCloud

are part of the same cluster, enabling OAuth with Refresh Login Flow setting on Unified CM also enables the
setting for the IM&P node, so there is no need to confirm that. You will validate OAuth with Refresh Login Flow
on Expressway in the next scenario. This just leaves the Unity Connection system, which you should confirm
has the setting enabled.
Confirm OAuth with Refresh Login Flow on Unity Connection (along with Unified CM Authz Server). From
the Firefox web browser on WKST1 (wkst1.dcloud.cisco.com / 198.18.133.36), browse to the Unity
Connection Administration interface at https://cuc1.dcloud.cisco.com/cuadmin and login with username /
password: administrator / dCloud123!. Once logged in, scroll down and click Authz Servers (under
Systems Settings) in the left-hand navigation panel.

OAuth for Cisco collaboration applications depend upon the Authz service running on Unified CM cluster nodes.
This service handles authorization calls and distributes OAuth tokens (including refresh tokens) to collaboration
clients and applications. Authz server configuration is not required on Unified CM IM & P since it is part of the
Unified CM cluster. But, Unity Connection (and Expressway-C for MRA) rely on Unified CM Authz service for
OAuth.
The Unified CM server (cucm1) has already been added to Unity Connection as an authorization (Authz) server
for you. You would add each node of a Unified CM cluster as an Authz server for redundancy purposes. In this
lab, our cluster contains only a single Unified CM node.

Click Enterprise Parameter (under Systems Settings) in the left-hand navigation panel and on the
parameters page, scroll down to the SSO and OAuth Configuration section (near the bottom of the page).
Confirm the parameter OAuth with Refresh Login Flow is already set to Enabled.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 185
Lab Guide
Cisco dCloud

Next, we will launch Jabber on WKST1 and WKST2 and confirm connectivity of all services (contact/message,
visual voicemail, and calling).
Launch the Jabber client on WKST1 (wkst1.dcloud.cisco.com / 198.18.133.36). When prompted to login to
the client, enter the username / password: amckenzie / dCloud12345! and click Login. This will complete
the client connection process.

NOTE: This login prompt confirms that OAuth with Refresh Login is enabled and in use for the authorization (and
authentication) flow.

NOTE: You may have to scroll down or stretch the login window to locate the Login button.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 185
Lab Guide
Cisco dCloud

NOTE: If the login window disappears prior to logging in, you must exit and then relaunch the client to access
the login window again.

Open an RDP connection to WKST2 (wkst2.dcloud.cisco.com / 198.18.133.37) and login with username /
password: DCLOUD\aperez / dCloud12345!. Launch the Jabber client on WKST2. When prompted to login
to the client, enter the username / password: aperez / dCloud12345! and click Login.

NOTE: You may have to scroll down or stretch the login window to locate the Login button.

The IM & P services and calling services will connect once the login is complete. If you click the Voicemail
tab, you will also notice this service is connected as evidenced by the message “You have no voice
messages.”

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 185
Lab Guide
Cisco dCloud

Confirm Jabber client service connectivity by referring to the Jabber Connection Status window. Click the
Settings icon [ ] in the upper right-hand corner of the Jabber client. Select Help > Show connection
status. Note in the Connection Status window, the voice (Softphone), voicemail, and presence services (as
well as directory) are all successfully connected.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 185
Lab Guide
Cisco dCloud

Click Close to close the Connection Status windows.

Make a call between Jabber clients on WKST1 & WKST2 and confirm call is not encrypted (no lock icon
displayed).

Place a call from the Jabber client on WKST1 (CSFamckenzie) to the Jabber client on WKST2
(CSFaperez). To do so, select Anita Perez from the contact list, click the green call button, and select one
of the entries (SIP URI or directory number) to dial this user. On WKST2, click Answer to answer the
incoming call from Adam Mckenzie.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 185
Lab Guide
Cisco dCloud

After the call is answered, notice the call is not encrypted because there is NOT a lock icon in the upper-
left corner of the video window.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 185
Lab Guide
Cisco dCloud

Before proceeding to the next section where you will enable SIP OAuth for encrypted calling, hang up the
call between Jabber clients by clicking the end call softkey [ ] at either client.

B. Enable SIP OAuth and Validate Encrypted Calling

You will now enable SIP OAuth on Unified CM using the CLI. On WKST1 (wkst1.dcloud.cisco.com /

198.18.133.36), double-click the PuTTY icon [ ] on the desktop to launch the PuTTY client. Enter
cucm1.dcloud.cisco.com in the Host Name (or IP Address) field. Click Open. Log in with
username/password: administrator / dCloud123!
Enter the command: show ctl

Again, note the cluster is not in mixed mode (as evidenced by the error message CTL File not found….Error
parsing the CTL File.).

Now enable SIP OAuth on the system by entering the command: (Be patient, it can take as long as a minute
for the system to respond after enabling SIP OAuth.)
utils sipOAuth-mode enable

To fully enable SIP OAuth, you must restart the CallManager service. The steps are detailed below.

Once the system responds, type exit and press Enter to end the SSH session to Unified CM.

Restart CallManager Service to Complete SIP OAuth Enablement

Go to the Unified CM Serviceability interface at https://cucm1.dcloud.cisco.com/ccmservice/ and, if

prompted, login with username / password: administrator / dCloud123!. Navigate to Tools > Control
Center – Feature Services. Select cucm1.dcloud.cisco.com--CUCM Voice/Video from the Server
dropdown menu and click Go. On the subsequent page tick the Cisco CallManager service and click
Restart. Finally, acknowledge the confirmation by clicking OK.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 185
Lab Guide
Cisco dCloud

During the restart, you might notice the Jabber clients on WKST1 and WKST2 reconnecting to the phone
service as indicated by the Setting phone… message at the bottom of the client windows.

The clients will reconnect once the Cisco CallManager service is fully restarted. Once the Jabber clients
reconnect, proceed to the next step.
Confirm that SIP OAuth is enabled and again note that Unified CM is in non-secure mode.

Now that you have enabled SIP OAuth on the command line and restarted the CallManager service, verify that
SIP OAuth mode is enabled.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 185
Lab Guide
Cisco dCloud

Return to the Unified CM Administration interface at https://cucm1.dcloud.cisco.com/ccmadmin/

(administrator/dCloud123!) and navigate to System > Enterprise Parameters. Scroll down to the Security
Parameters section and note that Cluster SIPOAuth Mode is set to Enabled.

As a reminder, Cluster Security Mode is set to 0, indicating that the cluster is non-secure (mixed-mode is not
enabled).

Review the Default SIP OAuth Port Numbers on Unified CM

Before proceeding, it is worth considering that SIP OAuth uses a different set of TCP ports than regular SIP and
SIP TLS. Check to see what the default SIP OAuth ports on the system are.

Navigate to System > Cisco Unified CM and click Find to show the list of Unified CM nodes in the cluster –
in this lab you have a single node cluster, as shown in the figure below.
Click CM_cucm1 to load the Cisco Unified CM Configuration page for this node. Under the Cisco Unified
Communications Manager TCP Port Settings for this Server, note the default SIP OAuth Ports:
• SIP Phone OAuth Port: 5090
This port is used by on-premises endpoints configured for SIP OAuth

• SIP Mobile and Remote Access OAuth Port: 5091

This port is used by Mobile and Remote Access (MRA) endpoints configured for SIP OAuth

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 185
Lab Guide
Cisco dCloud

As you can see, these ports are different than the traditional SIP and SIP TLS ports (SIP Phone Port and SIP
Phone Secure Port) of 5060 and 5061.

NOTE: These default port numbers may be modified to meet specific deployment requirements. Like regular SIP
ports, SIP OAuth ports are node specific.

Configure New Device Security Profile with OAuth

Now that you have enabled SIP OAuth and confirmed the default SIP OAuth ports on the system, you must
create a new device security profile with SIP OAuth authentication.
Navigate to System > Security > Phone Security Profile. Enter “UDT”’ in the empty field next to “begins
with” and click Find to locate the pre-configured security profiles for this lab. There are three (3) pre-
configured device security profiles based on the Universal Device Template.
Click the Copy icon next to the UDT-Encrypted-NullString.dcloud.cisco.com profile to copy the existing
profile to a new profile.

NOTE: These pre-configured profiles match the recommended profile strategy explained in the Security chapter
of the Enterprise On-Premises Preferred Architecture CVD
(https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/12x/120/collbcvd/security.ht
ml).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 185
Lab Guide
Cisco dCloud

Enable SIP OAuth by ticking the box next to Enable OAuth Authentication on the new copied profile and
name the new profile UDT-Jabber-SIPOAuth and enter a description (Encrypted with SIP OAuth (UDT-
based), for example). Click Save to save this new profile.

NOTE: The Enable OAuth Authentication setting is only available today for Jabber product-type device security
profiles: Cisco Dual Mode for iPhone (TCT device), Cisco Dual Mode for Android (BOT device), Cisco Unified
Client Service Framework (CSF device), Cisco Jabber for Tablet (TAB device), as well as the generic Universal
Device Template.

NOTE: The Enable OAuth Authentication and TFTP Encrypted Config settings within the Phone Security Profile
should be considered mutually exclusive. When Jabber is in SIP OAuth mode, the client requires neither a
locally significant certificate (LSC) nor the Unified CM cluster in mixed-mode. On the other hand, to support
TFTP Encrypted Config, SIP OAuth cannot be enabled on the Jabber client and the Jabber client would require
an LSC with Unified CM in mixed-mode.

Assign the New UDT-Jabber-SIPOAuth Phone Security Profile to CSFAMCKENZIE (WKST1)

and CSFAPEREZ (WKST2) Jabber Clients

Navigate to Devices > Phone. Enter CSF in the Begins with field. Add a second filter by clicking the add
icon [ ]. Select LSC Issued By with the Begins with field blank. Click Find. Note that none of the CSF
devices (Jabber for Windows clients) have been issued locally significant certificates (LSCs).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 185
Lab Guide
Cisco dCloud

From the device list, click the device name CSFAMCKENZIE (WKST1 Jabber client) to load the device
configuration page.

On the device configuration page, under the Protocol Specific Information section, select the new device
security profile you just configured: UDT-Jabber-SIPOAuth from the dropdown menu. This enables
encrypted calling with SIP OAuth. Click Save to save the configuration. Click OK to acknowledge the Apply
Configuration warning. Next, click Apply Config and then OK to close the Apply Configuration window.

NOTE: As before when the CallManager service was restarted, after applying the configuration change to the
Jabber client, you may notice the Jabber client reconnecting to the phone service as indicated by the Setting
phone… message at the bottom of the client windows.

Repeat this configuration on the other on-premises Jabber client (CSFAPEREZ). Return to the phone list by
clicking Go next to Related Links: Back To Find/List in the upper right-hand corner of the configuration
page.

Click the device name CSFAPEREZ (WKST2 Jabber client) to load this device configuration page. As
before, assign the same device security profile (UDT-Jabber-SIPOAuth) to enable encrypted calling with
SIP OAuth for this Jabber client device as well. Click Save to save the configuration. Click OK to
acknowledge the Apply Configuration warning. Next, click Apply Config and then OK to close the Apply
Configuration window.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 185
Lab Guide
Cisco dCloud

Return to Jabber on WKST1 and WKST2 and confirm connectivity to phone service.
You may at some point during the previous step be prompted with a session renewal window at either or
both Jabber clients. After the session renewal window appears, click Refresh session.

If prompted, enter the appropriate Jabber login credentials and click Login:

• WKST1: amckenzie / dCloud12345!

• WKST2: aperez / dCloud12345!

NOTE: You might NOT be prompted to refresh the session or login, this will depend on whether the OAuth
authorization has expired.

Confirm that both Jabber clients have successfully re-connected to Unified CM phone services before
proceeding.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 185
Lab Guide
Cisco dCloud

Place a Call from WKST1 Jabber Client to WKST2 Jabber Client to Confirm Secure Calling
(Encrypted Call)

Once the Jabber clients re-connect, as before, place a call from the Jabber client on WKST1
(CSFamckenzie) to the Jabber client on WKST2 (CSFaperez). Select Anita Perez from the contact list,
click the green call button, and select one of the entries (SIP URI or directory number) to dial this user.

On WKST2, click Answer to answer the incoming call from Adam Mckenzie.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 185
Lab Guide
Cisco dCloud

Once the call is connected, note the lock icon in the upper left-hand corner of the video window. This lock
icon indicates that the call is encrypted.

This confirms that SIP OAuth enables encrypted calling without having to enable mixed-mode on the
Unified CM cluster and without the need for a certificate (MIC or LSC) on the endpoint.

Hang up the call by clicking the end call softkey .

*** END OF SCENARIO ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 185
Lab Guide
Cisco dCloud

Scenario 3. Encrypted Calling with Expressway MRA and ICE Media Path
Optimization
Value Proposition: Simplify Cisco Jabber mobile and remote access (MRA) encrypted calling deployments with
SIP OAuth and save bandwidth with optimized MRA media paths using ICE, STUN, and TURN to reduce media
hairpinning at the enterprise.

By extending SIP OAuth to Expressway, Jabber calls through MRA on both the remote and on-premises call
legs are encrypted without requiring Unified CM to be in mixed-mode and without LSC installed on the client
device. Further, there is no longer a requirement that the name of the device security profile assigned to the
Jabber client in Unified CM must match one of the subject alternative names (SANs) of the Expressway-C
server certificate(s). Also, by leveraging interactive connectivity establishment (ICE) with session traversal
utilities for NAT (STUN) and traversal using relay around NAT (TURN) MRA call media flows between remote
endpoints can now travel point-to-point rather than hairpinning at Expressway inside the enterprise.

Summary

In this scenario, you will explore SIP OAuth and media path optimization with ICE for Expressway Mobile and
Remote Access (MRA). This scenario is divided into the following three sections:
A. Review Existing Environment and Complete Mobile and Remote Access Configuration

B. Confirm Mobile and Remote Access Connectivity for Remote Jabber Clients with SIP OAuth (Before & After)

C. Configure and Validate Media Path Optimization with ICE for Jabber MRA

The figure below depicts the topology and relevant components for this scenario.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 185
Lab Guide
Cisco dCloud

Steps

A. Review Existing Environment and Complete Mobile and Remote Access

(MRA) Configuration

In this section, you will first review the existing Expressway environment and next, you will complete the MRA
deployment configuration.

Ensure OAuth with Refresh Login Flow is enabled on Expressway-C. [Review Only]
If not already connected, open an RDP connection to WKST1 (wkst1.dcloud.cisco.com / 198.18.133.36)
and login with username / password: administrator / dCloud12345!
As with SIP OAuth for on-premises endpoints, OAuth token with refresh login flow is a pre-requisite for
MRA endpoints to leverage SIP OAuth as well. Before proceeding, you should make sure OAuth
authorization is enabled on the Expressway-C.
In the Firefox browser, browse to the Expressway-C administration page at https://exp-c-
1.dcloud.cisco.com/ and login with username / password: admin / dCloud123!. Once logged in, navigate to
Configuration > Unified Communications > Configuration. Notice that Authorize by OAuth token with
refresh is already set to On.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 45 of 185
Lab Guide
Cisco dCloud

Also notice that although an IM and Presence Service node and a Unity Connection server have already
been configured, no Unified CM servers have yet been added for this MRA configuration. You will add the
Unified CM server after reviewing the Expressway-C Zones and Search Rules lists.

Review Expressway-C Zones and Search Rules before Configuring Unified CM and Enabling
SIP OAuth [Review Only]

Navigate to Configuration > Zones > Zones to review the existing list of zones. There are only two zones
currently configured on the system: DefaultZone (system-generated zone) and mra-traversal (previously
configured traversal zone for MRA).

You will take a closer look at the mra-traversal zone later. For now, navigate to Configuration > Dial plan >
Search rules and notice there is only a single system-generated search rule: LocalZoneMatch.

Add Unified CM (cucm1) server to Expressway-C to complete MRA configuration and automatically
enable SIP OAuth for the traversal zone.

IMPORTANT: You must complete the step above to successfully connect Jabber clients over MRA.

Navigate to Configuration > Unified Communications > Unified CM servers and click Add to configure the
Unified CM server node in this lab (cucm1.dcloud.cisco.com). Enter the following values noting that most of
these are default settings:
• Unified CM Publisher Address: cucm1.dcloud.cisco.com

• Username: administrator

• Password: dCloud123!

• TLS Verify Mode = On [default]

• ACS GCM support = On

• SIP UPDATE for session refresh = Off [default]

• ICE Passthrough support = Off [default]

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 46 of 185
Lab Guide
Cisco dCloud

Click the Add Address to save the Unified CM configuration and add the server to the system.

NOTE: You are enabling AES GCM support for media encryption because it is a stronger security cipher and
thus a best practice recommendation. AES GCM support has already been enabled on the mra-traversal zone,
as you will see later in this scenario.

After you receive the connection success message and the connection to Unified CM becomes active, you
will review the new zones and search rules that have been added automatically on Expressway-C.

Review New SIP OAuth Zones and Search Rules on Expressway-C after the Unified CM
Server is Added and Connected [Review Only]

Navigate back to Configuration > Zones > Zones to review the existing list zones. Along with the two
previous zones, there are now two new neighbor zones configured on the system: CEtcp-
cucm1.dcloud.cisco.com and CEOAuth-cucm1.dcloud.cisco.com, both corresponding to
protocols/services available on Unified CM.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 47 of 185
Lab Guide
Cisco dCloud

CEtcp-cucm1.dcloud.cisco.com is the traditional non-secure neighbor zone automatically created for TCP
connections to and from each Unified CM subscriber node configured on Expressway-C.

NOTE: If the Unified CM cluster were in mixed-mode, a CEtls-cucm1.dcloud.cisco.com secure neighbor zone
for TLS connections to/from each subscriber node would also be automatically created. Since the Unified CM
cluster is currently in non-secure mode, this neighbor zone was not created.

CEOAuth-cucm1.dcloud.cisco.com is the new SIP OAuth neighbor zone automatically created for SIP OAuth
connections. It is worth examining this new zone in more detail.
Click CEOAuth-cucm1.dcloud.cisco.com in the zone list to load the zone details. SIP Mode for this zone is
On. Further, note the SIP port number in use is 5091, which corresponds to the SIP Mobile and Remote
Access OAuth Port number configured on the Unified CM server in Scenario 2.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 48 of 185
Lab Guide
Cisco dCloud

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 49 of 185
Lab Guide
Cisco dCloud

Navigate back to Configuration > Dial plan > Search rules. Notice there are two new system generated
zones in addition to the previous LocalZoneMatch.

CEtcp-cucm1.dcloud.cisco.com is the traditional search rule with target of the CEtcp-

cucm1.dcloud.cisco.com neighbor zone, which is automatically created for TCP connections.

NOTE: If the Unified CM cluster were in mixed-mode, a CEtls-cucm1.dcloud.cisco.com search rule with target
of the CEtls-cucm1.dcloud.cisco.com neighbor zone would also be automatically created for TLS
connections. Again, because the Unified CM cluster is currently in non-secure mode, this search rule was not
created.

CEOAuth-cucm1.dcloud.cisco.com is the new SIP OAuth search rule created for SIP OAuth connections. It is
worth examining this new search rule in more detail.
Click CEOAuth-cucm1.dcloud.cisco.com in the Search rules list to load the rule details.The target of this
rule is the CEOAuth-cucm1.dcloud.cisco.com neighbor zone shown earlier. As shown in the Pattern string
field, the transport security protocol for SIP OAuth connections is TLS using port number in use is 5091,
again corresponding to the Mobile and Remote Access OAuth Port number configured on the Unified CM
server in Scenario 2.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 50 of 185
Lab Guide
Cisco dCloud

B. Confirm Mobile and Remote Access Connectivity for Remote Jabber Clients
with SIP OAuth (Before & After)

Now that the MRA configuration has been completed and SIP OAuth has been activated on the system, you can
begin logging in the MRA Jabber clients and confirm call encryption.

Open and login the Jabber client on WKST3 (CSFmcheng) to confirm MRA connectivity.
Open an RDP session to WKST3 (wkst3.dcloud.cisco.com / 198.18.2.38) and login with username /
password: DCLOUD\mcheng / dCloud12345!

Once connected, double-click the Jabber desktop icon (or click the Jabber icon on the task bar). The
Jabber client will begin the sign in process and a security alert is displayed indicating there is no certificate
revocation information available for the Expressway-E certificate the Jabber client is receiving during
authentication. Click Yes to acknowledge the alert. (See the figure below.)

NOTE: This alert makes sense given that the Expressway-E certificate was signed by the enterprise CA in this
lab. Because the enterprise CA is not reachable from outside the enterprise, the remote Jabber clients are
unable to validate whether this certificate has been revoked. If the Expressway-E certificate were signed by a
public CA, the client would be able to get revocation information from the public CA over the Internet.

At the OAuth authentication prompt, enter username / password: mcheng / dCloud12345! and click Login.

After entering the credentials, ensure the client successfully connects to the various collaboration services.
The IM and presence service and the calling service will connect once the login completes. If you click the
Voicemail tab, you will also notice this service is connected as evidenced by the message, You have no
voice messages. Open the Connection Status window by clicking the settings icon [ ] and select Help >
Show connection status.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 51 of 185
Lab Guide
Cisco dCloud

This gives you more details about the various services the Jabber client is connected. Review the Softphone
and Presence entries in the Connection Status window where you will see the client is connected to these
services through Expressway MRA.

Now that the Jabber client on WKST3 (CSFmcheng) is logged in and connected, make a call from the
Jabber client on WKST3 (CSFmcheng) to the Jabber client on WKST1 (CSFamckenzie) to confirm
unencrypted calling. To place a call from Monica’s WKST3, select Adam Mckenzie from the contact list,
click the green call button, and select one of the entries (SIP URI or directory number) to dial this user. On
Adam’s WKST1, click Answer to answer the incoming call from Monica Cheng.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 52 of 185
Lab Guide
Cisco dCloud

Once the call is connected, notice there is no lock icon present in the upper left-hand corner of the call
video window indicating the call is not encrypted on all legs. With MRA connections, calls are always
encrypted between the Jabber client and the Expressway-C server. However, in this case the signaling
connection between Expressway-C and Unified CM is not encrypted and, as such, the call media between
Expressway-C and the on-premises Jabber client on WKST1 (CSFamckenzie) is not encrypted either.

Once you assign a secure phone security profile with SIP OAuth to the MRA Jabber clients later in this scenario,
the signaling and media from Expressway-C to on-premises Unified CM and endpoints will be encrypted.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 53 of 185
Lab Guide
Cisco dCloud

Hang up the call by clicking the end call softkey [ ].

Now you will open and login the Jabber client on WKST4 (CSFwwhitman) to confirm MRA connectivity.
Before assigning SIP OAuth security profiles to the MRA Jabber clients, bring up the Jabber client on
WKST4 (CSFwwhitman) and make sure it successfully connects over MRA.

Open and RDP session to WKST4 (wkst4.dcloud.cisco.com / 198.18.2.39) and login with username /
password: DCLOUD\wwhitman / dCloud12345!
Once connected, double-click the Jabber desktop icon (or click the Jabber icon on the task bar). The
Jabber client begins the sign-in process and, as before, a security alert displays indicating there is no
certificate revocation information available for the Expressway-E certificate the Jabber client is receiving
during authentication. Click Yes to acknowledge the alert. Finally, at the OAuth authentication prompt, enter
username / password: wwhitman / dCloud12345! and click the Login button.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 54 of 185
Lab Guide
Cisco dCloud

After entering the credentials, ensure the client successfully connects to the various collaboration services.
The IM and presence service and the calling service will connect once the login completes. If you select the
Voicemail tab, you will also notice this service is connected as evidenced by the message “You have no
voice messages.” Now, open the Connection Status window by clicking the Settings icon [ ] and select
Help > Show connection status.

NOTE: It can take as long as 15 minutes for the contact photos/avatars to initially show up for Walt Whitman’s
Jabber client on WKST4.

Update with SIP OAuth Device Security Profile to Enable Secure Calling

Now that both MRA Jabber clients are successfully connecting and registering, you can ensure that
encryption is occurring on all legs of a Jabber MRA call by assigning the SIP OAuth phone security profile
you configured earlier (UDT-Jabber-SIPOAuth) to both MRA clients: CSFmcheng (WKST3) and
CSFwwhitman (WKST4).

Return to the Firefox browser on WKST1 (wkst1.dcloud.cisco.com / 198.18.133.36) and browse again to
the Unified CM administration interface at https://cucm1.dcloud.cisco.com/ccmadmin/. If prompted, login
with username / password: administrator / dCloud123!

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 55 of 185
Lab Guide
Cisco dCloud

Navigate to Device > Phone. Enter CSF in the begins with field. Add a filter by clicking the plus icon [ ]
and selecting LSC Issued By with the begins with field left empty. Click Find to list the devices on the
system. (See the figure below.)

Click CSFMCHENG (WKST3 Jabber client) in the list to load the device configuration page. On the device
configuration page under the Protocol Specific Information section, select the SIP OAuth device security
profile you configured previously (UDT-Jabber-SIPOAuth) from the dropdown menu.

This enables encrypted calling with SIP OAuth. Click Save to save the configuration. Click OK to
acknowledge the Apply Configuration warning. Finally, click Apply Config and then OK to close the Apply
Configuration window.
Repeat this configuration on the other MRA Jabber client (CSFwwhitman). Return to the phone list by
clicking Go next to Related Links: Back To Find/List in the upper right-hand corner of the configuration
page.

Click the device name CSFwwhitman (WKST4 Jabber client) to load this device configuration page. As
before, assign the same device security profile (UDT-Jabber-SIPOAuth) to enable encrypted calling with
SIP OAuth for this Jabber client device as well. Click Save to save the configuration. Click OK to
acknowledge the Apply Configuration warning. Finally, click Apply Config and then OK to close the Apply
Configuration window.

NOTE: You may notice the phone service momentarily disconnect and reconnect when you apply the
configuration to each of the MRA CSF devices. Ensure the phone services at both CSFmcheng (WKST3) and
CSFwwhitman (WKST4) are re-connected before proceeding to the next step.

Make a call between CSFmcheng (WKST3) and CSFamckenzie (WKST1) to confirm encrypted calling. From
the Jabber client on WKST3 (CSFmcheng), place a call to the Jabber client on WKST1 (CSFamckenzie)

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 56 of 185
Lab Guide
Cisco dCloud

by selecting Adam Mckenzie from the contact list, clicking the green call button, and selecting one of the
entries (SIP URI or directory number) to dial this user. On WKST1, click Answer to answer the incoming call
from Monica Cheng.

NOTE: If you receive a fast busy when placing the call from WKST3/CSFmcheng to WKST1/CSFamckenzie,
hang up and wait 90 seconds before placing the call again. This ensures the MRA firewall traversal connection
is fully re-established for all collaboration flows after the last configuration change.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 57 of 185
Lab Guide
Cisco dCloud

Once the call is connected, note that this time there is a lock icon in the upper left-hand corner of the video
window. This lock icon indicates that the call is encrypted.

This confirms MRA SIP OAuth encrypted calling to on-premises endpoints without having to enable mixed-
mode on the Unified CM cluster and without the need for a certificate (MIC or LSC) on the endpoint. Further,
unlike with traditional certificate-based media encryption, with SIP OAuth the name of the device security
profile used for SIP OAuth does not have to match a Subject Alternative Name (SAN) in the Expressway-C
server certificate in order to encrypt media on all call legs.

Hang up the call by clicking the end call softkey [ ].

Start a Wireshark Packet Capture with a Filter to Only Capture Media Packets Directly
between the Two MRA Jabber Clients

Before you enable ICE media path optimization, you should confirm the current call media path between the two
MRA Jabber clients on WKST3 and WKST4 traverses Expressway and does not flow directly between the
clients.
An easy way to confirm the media path is to use Wireshark with a capture filter on one of the MRA Jabber client
workstations to sniff the network wire and look for media (UDP) packets traversing the network directly
between the two Jabber clients. If there are no UDP packets sent directly between the two clients, then you can
be sure that the media of the call is hairpinning at Expressway.

Set up the Wireshark with capture filter on WKST3 (wkst3.dcloud.cisco.com / 198.18.2.38). Double-click

the Wireshark icon [ ] on the desktop to open the Wireshark sniffer application.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 58 of 185
Lab Guide
Cisco dCloud

On the welcome screen, click to select the External network interface.

On the same welcome screen, click the capture field and enter the following capture filter:
udp and host 198.18.2.38 and host 198.18.2.39

NOTE: This is a capture filter, NOT a display filter. Capture filter syntax is different.

When applied to a capture, this filter will only capture:

• UDP packets – UDP is the transport layer (layer 4) protocol used to carry voice and video over IP packets

• Packets sourced from IP addresses 198.18.2.38 (WKST3) and 198.18.2.39 (WKST4) and destined for one
of those same addresses (i.e. packets sent directly between the two IP addresses)
With this combination, Wireshark will only capture media packets (and other UDP-based traffic like STUN used
to implement ICE) traveling directly between the MRA Jabber clients on WKST3/198.18.2.38 (CSFmcheng) and
WKST4/198.18.2.39 (CSFwwhitman).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 59 of 185
Lab Guide
Cisco dCloud

Click the Wireshark icon just under the File menu to begin capturing using the capture filter. At this point,
you should not see any packets in the capture window. Leave the capture running and proceed to the next
step.

Make a call between CSFmcheng (WKST3) and CSFwwhitman (WKST4) to confirm encrypted calling
without media path optimization. To do so, from the Jabber client on WKST3 (CSFmcheng), select Walt
Whitman from the contact list, click the green call button, and select one of the entries (SIP URI or
directory number) to dial this user.

On WKST4, click Answer to answer the incoming call from Monica Cheng.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 60 of 185
Lab Guide
Cisco dCloud

Once the call is connected, note there is again a lock icon in the upper left-hand corner of the video
window. This lock icon indicates that this call is encrypted and confirms that SIP OAuth enables MRA to
MRA encrypted calling without having to enable mixed-mode on the Unified CM cluster, without the need
for a certificate (MIC or LSC) on the endpoint, and without the name of the device security profile assigned
to the CSF devices having to match a SAN of the Expressway-C server certificate.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 61 of 185
Lab Guide
Cisco dCloud

Return to the Wireshark window on WKST3 and notice the live capture is still in progress, but zero (0)
packets have been captured by the Wireshark capture filter even though the MRA Jabber clients are in a
call. This shows that the media traffic (UDP) is not traveling directly between the clients (198.18.2.38 and
198.18.2.39) and as such must be traversing Expressway.

Leave the Wireshark capture running as you will return to this later, but before proceeding to the next
section, hang up the call by clicking the end call softkey [ ].

C. Configure and Validate Media Path Optimization with ICE for Jabber MRA

In this section you will explore media path optimization (MPO) with ICE for Jabber MRA clients.

Configured ICE Passthrough Expressway-C mra-traversal Zones

You now need to enable support for ICE Passthrough on the Expressway-C mra-traversal zone.
If not still connected, open an RDP connection to WKST1 (wkst1.dcloud.cisco.com / 198.18.133.36) and
login with username / password: amckenzie / dCloud12345!
From the Firefox browser on WKST1, navigate to the Expressway-C server administrator interface at
https://exp-c-1.dcloud.cisco.com/ and login with username / password: admin / dCloud123!. Once logged
in, navigate to Configuration > Zones > Zones. In the resulting zone list, click the mra-traversal zone.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 62 of 185
Lab Guide
Cisco dCloud

Select On from the drop-down menu for the ICE Passthrough support field.

NOTE: Media path optimization with ICE requires ICE Passthrough support to be enabled, not ICE support.
Leave ICE support set to Off.

Click Save at the bottom of the page to update the traversal zone configuration.

Configure ICE Passthrough on the Unified CM Server in Expressway-C

Navigate to Configuration > Unified Communications > Unified CM servers and click
cucm1.dcloud.cisco.com in the server list.
On the Unified CM servers page, set ICE Passthrough support to On and click Save. You should receive a
“Connection success:…” message indicating the settings have been saved.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 63 of 185
Lab Guide
Cisco dCloud

Enable the TURN server on Expressway-E

Using the Firefox browser on WKST1, navigate to the Expressway-E server administrator interface at
https://exp-e-1.dcloud.cisco.com/. If prompted, login with username / password: admin / dCloud123!
Navigate to Configuration > Traversal > TURN. Select On from the TURN services dropdown. Click Save to
save the updated setting.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 64 of 185
Lab Guide
Cisco dCloud

After saving and before proceeding, ensure the TURN server’s status is active.

NOTE: The final step required to enable ICE for MRA endpoints is to configure several endpoint settings under
the Interactive Connectivity Establishment (ICE) section of the device configuration pages on Unified CM. This
can be done on an individual device basis or in the case of this lab using a custom Common Phone Profile,
which allows bulk configuration of many devices at once.

Configure ICE / TURN Settings in Common Phone Profile

Using the Firefox browser on WKST1, return to the Unified CM administrator interface at
https://cucm1.dcloud.cisco.com/ccmadmin/ and if prompted, login with username / password:
administrator / dCloud123!
Navigate to Device > Device Settings > Common Phone Profile and click Find to pull up a list of phone
profiles on the system.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 65 of 185
Lab Guide
Cisco dCloud

Click the Copy icon next to the Standard Common Phone Profile row to create a new profile based on the
standard profile.

Configure the following settings for the new Common Phone Profile ticking the Override Enterprise
Settings check box next to the ICE section settings as indicated (bold values are non-default):

• Common Phone Profile Information section:

o Name: Jabber MRA ICE

o Description: Common Phone Profile for Jabber MRA ICE

• Interactive Connectivity Establishment (ICE) section (scroll-down to find this section):

o ICE: Enabled

o Default Candidate Type: Host:

o Server Reflexive Address: Enabled

o Primary TURN Server Host Name or IP Address: 198.18.2.5

o Secondary TURN Server Host Name or IP Address:

o TURN Server Transport Type: Auto

o TURN Server Username: admin123

o TUIRN Server Password: dCloud123!

NOTE: The TURN server username / password specified above (admin123 / dCloud123!) are the credentials
previously added to the Expressway-E local authentication database when the Mobile and Remote Access
traversal zone was initially configured. The same credentials have been used here. Alternatively, you could have
added another set of credentials to the Expressway-E local authentication database.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 66 of 185
Lab Guide
Cisco dCloud

IMPORTANT: Please ensure your configuration look exactly as shown above including all the check boxes. If
your configuration does not match, the endpoints will not be able to reach or connect to the TURN server. This
will cause ICE media path optimization to fail.

Click Save to save this new Jabber MRA ICE common phone profile. You do not need to Apply Config or
Reset after saving because this new phone profile has no device associations yet.

NOTE: You will recall previously you used the Wireshark sniffer on WKST3 to verify the media for MRA to MRA
calls was not going directly and was instead hairpinned at Expressway.

Now, you will associate the new Jabber MRA ICE common phone profile to the two MRA Jabber clients
(CSFMCHENG and CSFWWHITMAN) to enable ICE media path optimization.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 67 of 185
Lab Guide
Cisco dCloud

Enable MRA Jabber Clients on WKST3 (CSFMCHENG) and WKST4 (CSFWWHITMAN) for ICE
with Common Phone Profile

Navigate to Device > Phone. If required, enter CSF in the Begins with field. As before, add a second filter.
Click the plus icon [ ], and select LSC Issued By with Begins with value left blank. Finally, click Find to
list the devices on the system. Click CSFMCHENG (WKST3 Jabber client) in the list to load the device
configuration page.

On the Phone Configuration page, under the Device Information section near the top of the page, select
the Common Phone Profile you configured previously: Jabber MRA ICE from the dropdown menu.

This enables ICE and TURN services for the device. Click Save to save the configuration. Click OK to
acknowledge the Apply Configuration warning. Finally, click Apply Config and then OK to close the Apply
Configuration window.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 68 of 185
Lab Guide
Cisco dCloud

Now, you should repeat this configuration on the other MRA Jabber client (CSFwwhitman). Return to the
phone list by clicking Go next to Related Links: Back To Find/List in the upper right-hand corner of the
configuration page.

Click the device name CSFwwhitman (WKST4 Jabber client) to load this device configuration page. As
before, assign the same Common Phone Profile (Jabber MRA ICE) to enable ICE media path optimization
for this Jabber client device as well. Click Save to save the configuration. Click OK to acknowledge the
Apply Configuration warning. Finally, click Apply Config and then OK to close the Apply Configuration
window.

NOTE: You may notice the phone service momentarily disconnect and reconnect with the message “Setting
phone…” when you apply the configuration to each of the MRA CSF devices. Please ensure the phone services
at both CSFmcheng (WKST3) and CSFwwhitman (WKST4) are re-connected before proceeding to the next
step.

Make Test Call between MRA Jabber Clients on WKST3 (CSFmcheng) and WKST4
(CSFwwhitman) to Confirm Encrypted Calling with TURN and ICE Media Path Optimization

Before making this test call, on WKST3 make sure that the Wireshark sniffer is still running and that there
are still no packets captured.
From the Jabber client on WKST3 (CSFmcheng), place a call to the Jabber client on WKST4
(CSFwwhitman) by selecting Walt Whitman from the contact list, clicking the green call button, and
selecting one of the entries (SIP URI or directory number) to dial this user. On WKST4, click Answer to
answer the incoming call from Monica Cheng.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 69 of 185
Lab Guide
Cisco dCloud

Once the call is connected, note there is again a lock icon in the upper left-hand corner of the video
window. This lock icon indicates this call is encrypted.

Return to the Wireshark window on WKST 3 / 198.18.2.38. Notice the packet capture is still live, and some
packets have been captured.

Click the Stop capture icon in the upper-left corner.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 70 of 185
Lab Guide
Cisco dCloud

Scroll down to the captured packet list. Stop when you see the first UDP packet with source or
destination of 198.18.2.38 (WKST3) and 198.18.2.39 (WKST4). This marks the transition from STUN / ICE
negotiation (also UDP) to full media between the two clients.

NOTE: It may take up to 30 seconds for ICE media path optimization to engage. If you hang up the first call, and
then place the call again, media path optimization will engage sooner given that the ICE and TURN reflexive
routes have been cached from the previous call. Also note, because the media packets are encrypted, you will
have limited visibility into individual packet detail.

Unfortunately, the ICE call statistics on Expressway-C (available under Status > ICE Passthrough metrics) take
24 hours to show up, so you will not be able to see ICE statistics for your calls for the first 24 hours after
configuration; however, the figure below shows information taken from a lab pod that was up for several days,
demonstrating the metric counters after a number of calls over a period of 24 hours.

In reviewing this example of the 24-hour ICE Passthrough metrics from an Expressway-C system (figure
below), it is worth noting the following:

• Total of 11 MRA client connected calls (see B2BUA connected calls counter)
• Of those 11 calls, 10 calls or 90.9% of calls engaged ICE media path optimization (see Calls with optimized
ICE media paths counter)

• 10 calls (90.9%) of the calls attempted ICE optimization (see Calls attempted with offered ICE candidates
counter) and were successful, only 1 call (9.1%) was not capable of ICE and thus ICE optimization was not
attempted (see Calls with ICE candidates offered by one endpoint counter)

This one call not capable of ICE because one of the endpoints in the call was on-premises (e.g. MRA Jabber
client on WKST3 [CSFmcheng] calls on-premises Jabber client on WKST1 [CSFamckenzie]). Remember, ICE
media path optimization only applies to MRA to MRA calls.

• 100% of these calls were 1:1 calls between MRA endpoints (see Host to host counter)

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 71 of 185
Lab Guide
Cisco dCloud

The system ICE Call Metrics History counters provide running historical and more granular detailed information
on MRA ICE calls. The figure below shows the ICE call metrics as well as the call history counter details on a
system that has been running for an extended period of time.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 72 of 185
Lab Guide
Cisco dCloud

Before proceeding, hang up the Jabber call by clicking the end call softkey [ ] and close the Wireshark
sniffer application on WKST3. Also, close the Jabber clients on all workstations (WKST1 – 4).

*** END OF SCENARIO ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 73 of 185
Lab Guide
Cisco dCloud

Scenario 4. Online CA Mode for Automatic Enterprise CA Endpoint Certificate

Enrollment
Value Proposition: Online CA Mode automates endpoint CAPF enrollment for LSC certificates from Enterprise
CAs simplifying endpoint security management and speeding up endpoint certificate deployments.

Introduced with Unified CM 12.5, Online Certificate Authority (CA) mode is a new CAPF mode that enables
automatic certificate enrollment with a Microsoft CA eliminating the manual CSR and certificate process with
external CAs previously required with the Offline CA mode.

Summary

In this scenario, you will explore the new Online CA mode for automatic endpoint certificate enrollment with a
Microsoft Enterprise certificate authority (CA). This scenario is divided into the following three sections:

A. Review the Required Microsoft Roles for the CA Server [Review Only]

B. Unified CM Configuration for the CAPF Online CA mode

C. Phone LSC installation and Encrypted Calling

The figure below details the topology and relevant components for this scenario.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 74 of 185
Lab Guide
Cisco dCloud

Endpoint Certificate Enrollment

There are now three methods of CAPF enrollment for installing locally significant certificates (LSCs) on
collaboration endpoints.

Prior to Unified CM 12.5, there were just two methods for CAPF enrolling an endpoint:
• Locally Significant Certificate (LSC) signed by the Cisco Certificate Authority Proxy Function (CAPF).

• Locally Significant Certificate (LSC) signed by an external Certificate Authority in Offline CA mode. The
main steps required for doing that are:
• Initiate the LSC installation which creates a private/public key pair on the phones. A tar file is created on
Unified CM which contains the CSR files for all the endpoints where you initiated the LSC installation.

• Export the CSRs from Unified CM

• On the Certificate Authority server, issue certificates for each CSR

• Tar all the certificates into one file and import that file into Unified CM

• Run Unified CM CLI command to install the LSC for the endpoints

An endpoint cannot reboot during those steps, otherwise a new public/private key pair will be created on the
endpoint and the certificate that was issued by the CA would not be valid anymore.

Beginning with Unified CM 12.5 a third method for endpoint LSC certificate installation was added.

Locally Significant Certificate (LSC) Signed by an External Certificate Authority in Online CA

Mode

This new method in Unified CM 12.5 is the focus this scenario. Be aware that the external Certificate Authority
server required for Online CA mode is an enterprise Microsoft Certificate Authority server, using NTLM v1.

NOTE: Kerberos is not a supported authentication method with Online CA mode.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 75 of 185
Lab Guide
Cisco dCloud

From the endpoint perspective, the LSC installation process is the same with Online CA mode as it is with
regular CAPF mode. Because this interaction between the endpoints and the CAPF service stays the same,
Online CA mode is not limited to just newer phones or newer firmware and is backward compatible with older
phone firmware models.

Steps

A. Review the Required Microsoft Roles for the CA Server [Review Only]

IMPORTANT: The steps in this section are for review only. This section covers the required configuration of the
enterprise Microsoft CA for the Online CA mode operations in the remainder of this scenario. This configuration
has already been done for you. The steps in this section have been included here for you reference. Please
review before proceeding to Section B.

RDP to the CA (ca.dcloud.cisco.com) and login with username / password: DCLOUD\administrator /

dCloud12345!
The roles required for the CA server includes the Certification Authority and the Certification Authority Web
Enrollment roles as well as the Web Server (IIS) role.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 76 of 185
Lab Guide
Cisco dCloud

These roles have already been enabled in the lab. To verify that, go to the Windows Start Menu and click
Server Manager.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 77 of 185
Lab Guide
Cisco dCloud

Click Add roles and features to start the Add Roles and Features wizard.

Click Next three times to reach the Server Roles window.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 78 of 185
Lab Guide
Cisco dCloud

Under the Active Directory Certificate Service, verify Certification Authority and Certification Authority
Web Enrollment roles are selected. Click the role to expand the list of sub-roles.

Likewise, if you scroll down and expand the Web Server (IIS) role, you should see Web Server selected
among other various sub-roles.

Since the above roles / sub-roles are already added to the system, click Cancel to close the Add Roles and
Features Wizard. Close the Server Manager window.

Create a New User and a New Certificate Template [Review Only]

IMPORTANT: You do not need to complete this step. This Create a New User and a New Certificate Template
section has already been done for you. It is included here for your reference.

Open the Active Directory Users and Computers console by clicking on the icon in the task bar.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 79 of 185
Lab Guide
Cisco dCloud

Right-click Users to bring up the context menu. Select New > User.

Enter the values as shown in the figure below and click Next.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 80 of 185
Lab Guide
Cisco dCloud

As shown in the figure below, enter “dCloud123!” in the Password and Confirm password fields, unselect
User much change password at next logon if necessary, and select Password never expires. Click Next.

Review the settings and click Finish to add the user.

Close the Active Directory User and Computers window.

Create a New Certificate Template for Online CA Mode Automatic Enrollment [Review Only]

IMPORTANT: You do not need to complete this step. This Create a New Certificate Template for Online CA
Mode Automatic Enrollment section has already been done for you. It is included here for your reference.

Click the Microsoft Windows Start Menu, type “mmc.exe”, and click mmc.exe – Run command.

Add a snap-in by navigating to File > Add/Remove Snap-in….

Select Certificate Templates and click Add >.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 81 of 185
Lab Guide
Cisco dCloud

Select Certification Authority and click Add >. Use the default option (Local computer) and click Finish.
You should see the console as shown below.

Click OK.

Navigate to Console Root > Certificate Templates (CA.dcloud.cisco.com).

Right click the ClientServer template and click Duplicate Template.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 82 of 185
Lab Guide
Cisco dCloud

Go to the General tab and change the Template display name and Template name to ciscoratemplate.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 83 of 185
Lab Guide
Cisco dCloud

Go the Security tab and add the new cisco ra user by clicking Add…, enter “cisco ra” in the Enter the
object names to select (examples): box, and click Check Names. Click OK. Provide the Read, Write, and
Enroll permissions to the cisco ra user. Click OK.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 84 of 185
Lab Guide
Cisco dCloud

Next, you will make the new ciscoratemplate available. On mmc, navigate to Console Root > Certification
Authority (local) > dCloud-CA > Certificate Templates. Right click Certificate Templates and select New
> Certificate Template to Issue.

Select ciscoratemplate and click OK.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 85 of 185
Lab Guide
Cisco dCloud

Restart the CA service by navigating to Console Root > Certification Authority (local) > dCloud-CA and
stop then start the service by using the icons located just below the menu bar near the top of the window.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 86 of 185
Lab Guide
Cisco dCloud

Now, you need to configure the IIS service. Open the Internet Information Services Manager console
using the Start menu and navigate to Windows Administrative Tools.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 87 of 185
Lab Guide
Cisco dCloud

Navigate to CA (DCLOUD\administrator) and double click Server Certificates in the main panel.

You will see three certificates. The first one is the CA certificate (Root CA certificate). The second one is the is
previous system generated IIS certificate. The third one is the current IIS certificate. It is a certificate that has
been signed by the root CA and that will be assigned to the HTTPS connections to IIS in the next step.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 88 of 185
Lab Guide
Cisco dCloud

Navigate to CA (DCLOUD\administrator) > Sites > Default Web Site. In the Actions panel on the right, click
Bindings….

Click the https row and click Edit… In the SSL certificate box, ensure the IIS certificate:
ca.dcloud.cisco.com is selected. Click Cancel (since you have not made any changes) and then Close.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 89 of 185
Lab Guide
Cisco dCloud

Restart the IIS service by clicking on the Restart link in the Actions panel.

The Microsoft Certificate Authority server configuration is complete.

NOTE: Unlike in the previous section where you just reviewed the existing configuration, you must complete all
the remaining configuration steps in the rest of the sections of this scenario.

B. Unified CM Configuration for CAPF Online CA Mode

In this section, you will configure Unified CM to automatically install phone LSCs signed by the enterprise
Microsoft CA.

Import the Enterprise Microsoft CA Root Certificate to the Unified CM Trust Stores

RDP to WKST1 (wkst1.dcloud.cisco.com) and login with username / password: DCLOUD\amckenzie /

dCloud12345! if not already connected.
Download the root CA certificate. For that, open Firefox and go to https://ca.dcloud.cisco.com/certsrv,
login with the administrator / dCloud12345! credentials, and then click Download a CA certificate,
certificate chain, or CRL.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 90 of 185
Lab Guide
Cisco dCloud

Click Download CA certificate (step 1), and click OK to save the file (step 2). Name the file “dCloud-CA”
(the .cer suffix will be added automatically) (step 3).

Browse to the Unified CM OS Administration interface (https://cucm1.dcloud.cisco.com/cmplatform/) from

the Firefox web browser. Login (if required) with username / password: administrator / dCloud123!

Navigate to Security > Certificate Management.

Click Upload Certificate/Certificate chain.

For the Certificate purpose, select CAPF-trust. Enter “dCloud-CA” in the Description field, click Browse…,
and select the CA certificate you just saved in the Downloads folder. Click Open.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 91 of 185
Lab Guide
Cisco dCloud

Click Upload. A message will indicate the Cisco CAPF service needs to be restarted, but this is not
necessary at this time. You will restart the CAPF service later in this scenario. Click Close.

NOTE: The same steps for the CallManager-trust would be necessary but this has already been done for you
when the CA-signed CallManager certificate was issued.

The CA certificate import to CAPF-trust is necessary so that CAPF/Cisco Registration Authority (Cisco RA) can
successfully connect to Microsoft IIS (IIS certificate signed by the same CA) through HTTPS. The CA certificate
import to CallManager-trust allows the CallManager service to trust the endpoint LSCs, which is required when
configuring encrypted mode for phones or TFTP file encryption.

Configure CAPF for Online CA Mode

From the Firefox browser, again navigate to the Unified CM Administration interface of cucm1
(https://cucm1.dcloud.cisco.com/ccmadmin) and log in with administrator / dCloud123!

Navigate to System > Service Parameters. Select the Unified CM server (cucm1.dcloud.cisco.com—CUCM
Voice/Video (Active)) in the Server drop-down menu and the Cisco Certificate Authority Proxy Function
(Active) in the Service drop-down menu.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 92 of 185
Lab Guide
Cisco dCloud

Configure the following non-default values as shown in the figure below:

• Certificate Issuer to Endpoints: Online CA

• Online CA Hostname: ca.dcloud.cisco.com

• Online CA Port: 443

• Online CA Template: ciscoratemplate (this template has been pre-configured for you on the CA server
as noted in section A)

• Online CA Username: ciscora (this user account has been pre-configured for you on the CA server as
noted in section A)
• Online CA Password: dCloud123! (this password was pre-configured for you on the CA server as noted
in section A)

Click Save. A pop-up window will inform you that the CAPF service needs to be restarted. Click OK to
acknowledge.
Before restarting the CAPF service, first activate the Cisco Certificate Enrollment Service by navigating to
the Cisco Unified Serviceability interface at https://cucm1.dcloud.cisco.com/ccmservice/. Navigate to Tools
> Service Activation. Select cucm1.dcloud.cisco.com—CUCM Voice/Video from the Server dropdown
field and click Go. Finally, tick the Cisco Certificate Enrollment Service checkbox (scroll down to the
Security Services section to find it).

Click Save. Click OK to acknowledge the warning about the service activation.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 93 of 185
Lab Guide
Cisco dCloud

Restart the Certificate Authority Proxy Function (CAPF) service. Navigate to Tools > Control Center –
Feature Services, select cucm1.dcloud.cisco.com—CUCM Voice/Video in the Server drop-down menu,
click Go, select the Certificate Authority Proxy Function radio button (again scroll down to the Security
Services section to find it), and click Restart. Click OK to acknowledge the restart message. Note the
Cisco Certificate Enrollment Service will then also be started automatically, which will take a few minutes.
Before proceeding ensure the Cisco Certificate Enrollment Service has started successfully. If not in
Started status, click the Refresh button until you verify that the service has started.

This concludes the Unified CM Online CA configuration portion of this scenario.

C. Phone LSC Installation and Encrypted Calling

Now that the Microsoft CA and Unified CM are configured, you will perform a CAPF enrollment to install an LSC
on the device. This results in a CA-signed LSC. This could be done for any of the Cisco phones that support
CAPF and LSC since this is transparent to the phones. The phones just connect to CAPF to get their certificate,
the fact that CAPF then connects to the enterprise Microsoft CA is unimportant to the phones.

NOTE: This feature is intended for hardware endpoints and not Jabber (Jabber does not need an LSC when
configured for SIP OAuth). Because there are no hardware phones in this lab, you will validate Online CA mode
with Enterprise CA by installing LSCs on the on-premises Jabber clients to illustrate the concept and confirm
the operation.

Enable Unified CM Mixed-Mode

Since Jabber only supports the CTL file and not the ITL file and since Jabber needs to connect securely to
CAPF to get a certificate, you must enable Unified CM mixed-mode.

NOTE: Hardware phones, such as the 7800 or 8800 phones, support the ITL file and therefore enabling Unified
mixed-mode is not required to install an LSC on those phones. However, mixed-mode would be required for
encrypted calling with the hardware phones.

On WKST1 (wkst1.dcloud.cisco.com) open PuTTY and connect via SSH to cucm1.dcloud.cisco.com.

Enter the username / password: administrator / dCloud123!
Before enabling the system for mixed-mode, first confirm the system is fully licensed and export-controlled
functionality (i.e. encryption) is allowed by entering the command: show license status

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 94 of 185
Lab Guide
Cisco dCloud

Notice the system is fully licensed (Registration Status: REGISTERED – SPECIFIC LICENSE RESERVATION,
License Authorization Status: AUTHORIZED - RESERVED) and encryption is allowed on the system (Export-
Controlled Functionality: Allowed).

If the system is not licensed (not registered and authorized), make sure you have completed the required
licensing operations on Unified CM as described in Scenario 1.
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 will not see the ‘y’ on the screen, until after press the Enter key.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 95 of 185
Lab Guide
Cisco dCloud

Enter exit on the CLI and press Enter to close the SSH session.

Restart CallManager Service

Return to the Unified CM Serviceability interface (https://cucm1.dcloud.cisco.com/ccmservice/) and if

prompted, login with username / password: administrator / dCloud123!. Navigate to Tools > Control
Center – Feature Services, select cucm1.dcloud.cisco.com--CUCM Voice/Video from the Server
dropdown menu and click Go. On the subsequent page tick the Cisco CallManager service and click
Restart. Acknowledge the confirmation window by clicking OK.

Issue CA-signed LSCs to On-Premises Jabber Clients Using CAPF

Once the Cisco CallManager service restarts, in the Firefox browser, return to the Unified CM Administration
interface of cucm1 (https://cucm1.dcloud.cisco.com/ccmadmin).
Navigate to Device > Phone. Enter ‘CSF’ in the Begins with field. Click Find. Click CSFamckenzie device in
the resulting list.
Perform the CAPF enrollment by selecting Install/Upgrade in the Certificate Operation field. Ensure the
Operation Completes By date is further than today’s date (some future date).

NOTE: You may have to enter a future month:day:hour (in 2-digit numeric format) in the Operations Complete
By field to complete the configuration.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 96 of 185
Lab Guide
Cisco dCloud

In addition, because you are installing a certificate on this Jabber endpoint, you should configure a Device
Security Profile without SIP OAuth. Set the Device Security Profile to UDT-Encrypted-
Nullstring.dcloud.cisco.com.

Click Save and then OK to acknowledge the confirmation. Click Apply Config and then OK to apply the
new configuration to the endpoint.

Repeat this same configuration for the CSFaperez device.

Start the Jabber client on WKST1 (CSFamckenzie) to CAPF enroll the client device by double-clicking the
Jabber icon on the desktop. The client should automatically log in. If prompted, enter the username /
password: amckenzie / dCloud12345!. Ensure the Jabber client connects to the phone service.
RDP to WKST2 (wkst2.dcloud.cisco.com) and login with username / password: DCLOUD\aperez /
dCloud12345!. Double-click the Jabber icon on the desktop to start the Jabber client on WKST2
(CSFaperez) to CAPF enroll the client device. The client should automatically log in. If prompted, enter the
username / password: aperez / dCloud12345!. Ensure this Jabber client also connects to the phone
service.
Return to the Unified CM administration and go back to the main phone page (Device > Phone). Add a
second filter by clicking the plus icon [ ] and selecting LSC Issued By with Begins with field blank. Click
Find. You should see that the LSC installation on both on-premises Jabber clients was successful (Upgrade
Success) and that the issuer is dCloud-CA (and not CAPF).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 97 of 185
Lab Guide
Cisco dCloud

If the Jabber clients on WKST1 and WKST2 do not fully connect, to troubleshoot, review the logs located in
the capf folder. To see the list of log files, run the CLI command:
file list activelog cm/trace/capf/sdi detail date

If you needed to examine the LSC, you could also configure the Certificate Operation field to Troubleshoot
(instead of Install/Upgrade) and examine the LSC with the CLI commands:
file list activelog cm/trace/capf/sdi (lists the log files and certificates obtained through the
troubleshoot certificate operation)
file get activelog cm/trace/capf/sdi/CSFAMCKENZIE-L1.cer (downloads the LSC)

The figure below shows an example of an LSC issued to Jabber.

Make a call between on-premises Jabber clients (CSFamckenzie and CSFaperez) to confirm encrypted
calling with Online CA installed LSCs.

REMEMBER: This feature is intended for hardware endpoints and not Jabber. SIP OAuth is the recommended
method for securing Jabber clients. Because there are no hardware phones in this lab, you are merely using the
on-premises Jabber clients to illustrate and confirm Online CA mode with Enterprise CA operations.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 98 of 185
Lab Guide
Cisco dCloud

Place a call from the Jabber client on WKST1 (CSFamckenzie) to the Jabber client on WKST2 (CSFaperez)
to confirm encrypted calling. On the Jabber client on WKST1 select Anita Perez from the contact list,
clicking the green call button, and selecting one of the entries (SIP URI or directory number) to dial this
user. On WKST2, click Answer to answer the incoming call from Adam Mckenzie.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 99 of 185
Lab Guide
Cisco dCloud

Once the call is connected, note the lock icon in the upper left-hand corner of the video window. This lock
icon indicates that the call is encrypted.

Hang up the call by clicking the end call softkey [ ] at one of the clients and then close both Jabber
clients (WKST1 and WKST2).
Congratulations, you have installed LSCs signed by the enterprise Microsoft CA using the online CA mode of
CAPF and confirmed encrypted calling. Please proceed to the next scenario.

*** END SCENARIO ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 100 of 185
Lab Guide
Cisco dCloud

Scenario 5. Unified CM TLS/SSH Interface Granular Administrative Cipher

Control
Value Proposition: Unified CM 12.5 introduced granular administrative control of ciphers across the server
interfaces providing improved security and simplified management.

Administrators can configure a list of specific ciphers for TLS, SIP TLS, and SSH based on deployment
requirements. This allows administrators to minimize or eliminate weaker cipher negotiations during TLS and
SSH connections improving security across the system.

Summary

In this scenario, you will configure a list of specific TLS and SSH ciphers that are allowed in Unified CM. The
scenario is divided into the following five sections:

A. Default Behavior without Customized Ciphers List

B. Custom Ciphers for All TLS Interfaces Configuration

C. Overwriting Cipher Configuration for the SIP Interface

D. Cipher String Format

E. Custom SSH Cipher Configuration

The figure below depicts the topology and relevant components for this scenario.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 101 of 185
Lab Guide
Cisco dCloud

TLS/SSH Cipher Control

This feature is targeted to customers who need to change the list of ciphers that are allowed by default in
Unified CM. For example, a customer might consider some ciphers as non-secure and might want to disable
them in Unified CM.

Steps

A. Default Behavior without Customized Ciphers List

In this section, you will review the default behavior, without configuring a list of ciphers. If there are no cipher
lists configured in the new Cipher Management page, then the available cipher suites are the same as in
Unified CM 12.0 and prior releases.

NOTE: In this scenario you will repeatedly move between the Unified CM Administration and Serviceability web
interfaces and the Unified CM Operating System web interface. When moving between these web interfaces,
you must login each time. If you have not done so already, consider saving the administration username /
password in Firefox to save time when moving between the web interfaces. You could also open a New Private
Window (Control-Shift-P) in the Firefox, browser and use your original browser window for the Unified CM
Administration and Unified Serviceability interfaces and the private window for the Unified CM Operating
System interface.

Review Default Cipher Configuration on Unified CM for the SIP Interface

RDP to WKST1 (wkst1.dcloud.cisco.com) and login with username / password: DCLOUD\amckenzie /

dCloud12345!

NOTE: By default, no ciphers are configured in the Cipher Management page, and the list of ciphers allowed for
the SIP interface come from the configuration in the Enterprise Parameter TLS Ciphers.

Browse to the Cisco Unified CM Administration interface (https://cucm1.dcloud.cisco.com/ccmadmin/)

from the Firefox web browser. Login (if required) with username / password: administrator / dCloud123!

Navigate to System > Enterprise Parameters. Look for the TLS Ciphers parameter and verify that it is set
to All Ciphers RSA Preferred.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 102 of 185
Lab Guide
Cisco dCloud

The list of ciphers allowed for this configuration is shown in the Help page. Click the TLS Ciphers hyperlink.

With the default value All Ciphers RSA Preferred, the list of available ciphers on the SIP interface is:

• TLS_ECDHE_RSA with AES256_GCM_SHA384

• TLS_ECDHE_ECDSA with AES256_GCM_SHA384

• TLS_ECDHE_RSA with AES128_GCM_SHA256

• TLS_ECDHE_ECDSA with AES128_GCM_SHA256

• TLS_RSA with AES_128_CBC_SHA1

NOTE: TLS_RSA_WITH_NULL_SHA would also be available for endpoints configured in Authenticated mode.

Confirm the Default Ciphers of the SIP Interface

Verify with the nmap tool that the SIP interface really allows those ciphers.

The nmap tool can also be very useful. With the ssl-enum-ciphers script that you could download from the
nmap web site, https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html, you can determine which TLS
version and which ciphers are allowed on a TLS server interface. In this lab, you will be using Zenmap
which is a GUI version of nmap and which is already installed on WKST1.

Open the nmap program on WKST1, called Nmap - Zenmap GUI [ ].

In the Command window, enter the following command and click Scan.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 103 of 185
Lab Guide
Cisco dCloud

nmap -sV --script ssl-enum-ciphers -p 5061 198.18.133.3

This command can take some time to complete.

Verify the reported Unified CM TLS v1.2 cipher suites match the cipher suites that were listed on the Help
page (refer back to the figure above).

B. Custom Ciphers for All TLS Interfaces Configuration

In this section, you will configure a custom list of ciphers that will be allowed for All TLS Interfaces in Unified
CM.

Configure Ciphers for All TLS Interfaces

Browse to the Unified CM OS Administration interface (https://cucm1.dcloud.cisco.com/cmplatform/) from

the Firefox web browser on WKST1 (198.18.133.36). Login (if required) with username / password:
administrator / dCloud123!

Navigate to Security > Cipher Management.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 104 of 185
Lab Guide
Cisco dCloud

Navigate to Help > This Page. A new tab will open. Click the Recommended Ciphers link to see the
recommended ciphers. This is the list of ciphers that are recommended and tested by Cisco in case you
want to customize the Cipher Suites allowed on your system.

Select the recommended ciphers for TLS and copy the list to your clipboard (select the ciphers and press
Control-C).

The list of recommended TLS ciphers is:

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:

ECDHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:

ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA

Go back to the Cipher Management tab and paste (press Control-V) this recommended TLS cipher list from
the clipboard to the All TLS input box. Click Save.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 105 of 185
Lab Guide
Cisco dCloud

You will see a notification that a reboot of each cluster node is necessary (in this case, in the interest of
time, you will simply restart the Cisco CallManager service as indicated in the next step).

Click OK in the pop-up message box.

Unified CM validates the ciphers and shows the list of ciphers that will be allowed on the interfaces after the
verification.

Restart the CallManager Service

Restart the CallManager service by browsing to the Cisco Unified Serviceability interface at
https://cucm1.dcloud.cisco.com/ccmservice/. When prompted, login with username / password:
administrator / dCloud123!
Navigate to Tools > Control Center – Feature Services, select cucm1.dcloud.cisco.com—CUCM
Voice/Video in the Server drop down list, and click Go. Next, select the Cisco CallManager radio button and
click Restart.

NOTE: This is only done on one node since there is only one node in the Unified CM cluster in this lab. If a
Unified CM cluster has multiple nodes, the CallManager service needs to be restarted on all nodes.

Run Zenmap again on WKST1. In the Command window, enter the following command and click Scan.
nmap -sV --script ssl-enum-ciphers -p 5061 198.18.133.3

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 106 of 185
Lab Guide
Cisco dCloud

You will see that the new list of allowed TLS v1.2 ciphers is shown.

NOTE: Not only can this feature remove ciphers, it also can add ciphers (if the Unified CM Services support
those ciphers).

In this case, the TLS_RSA_WITH_NULL_SHA (that would be allowed only for those phones configured in
authenticated mode), TLS_ECDSA_WITH_AES_128_GCM_SHA256, and
TLS_ECDSA_WITH_AES_256_GCM_SHA384 ciphers were removed.

But you also added new ciphers:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384

NOTE: Best Practice – For customers who need to restrict the ciphers allowed in their environment, it is
recommended to start with this list of recommended ciphers. Then you can remove individual ciphers but be
aware of possible interoperability issues. Perform all the testing in your lab before making this change in the
production.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 107 of 185
Lab Guide
Cisco dCloud

NOTE: TLS_RSA_WITH_NULL_SHA is removed. Also, for security reasons, TLS_RSA_WITH_NULL_SHA cannot

be added back since if it is configured in this page, it will apply to the entire interface(s) and not be limited to
phones that are configured in authenticated mode, as it is currently by default, and that will be a security
concern. Therefore, if you plan to use the authenticated mode for some of your phones, do not configure any
ciphers in the All TLS (or SIP) input box in the Cipher Management page. Alternatively, you can configure a list
of ciphers for the All TLS and/or SIP interface, but you would have to configure your phones in encrypted mode
or non-secure mode.

C. Overwriting Cipher Configuration for the SIP Interface

The previous cipher list applied to all TLS interfaces. You can overwrite this cipher list for two types of
interfaces: HTTPS and SIP. In this section, you will overwrite this list on the SIP interface and only allow very
strong ciphers.

Update the Unified CM SIP TLS Interface Ciphers

Return to the Cisco Unified OS Administration interface (https://cucm1.dcloud.cisco.com/cmplatform/)

and login with username / password: administrator / dCloud123!. Navigate back to the Cipher
Management page (Security > Cipher Management).

Scroll down to the SIP TLS input box and enter the following cipher list: ECDHE-RSA-AES256-GCM-
SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
Click Save. Click OK in the pop-up notification box to acknowledge the reboot cluster notification. Unified
CM validates the entered ciphers and shows the list of ciphers that will be allowed on the interfaces after
the verification.

You will need to restart the CallManager service for the changes to take effect. Browse to the Cisco Unified
Serviceability interface at https://cucm1.dcloud.cisco.com/ccmservice/. When prompted, login with
username / password: administrator / dCloud123!

Navigate to Tools > Control Center – Feature Services, select cucm1.dcloud.cisco.com—CUCM

Voice/Video in the Server drop-down list, and click Go. Next, select the Cisco CallManager radio button,
and click Restart.

Return to nmap. In the Command window, enter the following command and click Scan.
nmap -sV --script ssl-enum-ciphers -p 5061 198.18.133.3

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 108 of 185
Lab Guide
Cisco dCloud

This confirms the cipher suites that Unified CM supports as previously configured.
In this case, those two cipher suites will be allowed on the SIP interface. On the other TLS interfaces, the
allowed ciphers remain unchanged, they will be the ones you configured earlier, in the All TLS input box.

You could also repeat this process to overwrite the cipher list you configured in the All TLS input box for the
HTTPS interface, but you will not do that in this lab.
Be careful when using this feature. Not all TLS interfaces in Unified CM support all TLS Ciphers. And some
of the network devices in a deployment may not support all TLS ciphers. For example, be careful if
configuring the following strong cipher list:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 in
the All TLS box, as some Unified CM services (for example CAPF) and some other devices (for example
older phones) may not support it. Instead, for a customer that has very restrictive cipher requirements, the
best practice is to configure the recommended list of ciphers in the All TLS input box, and then further
restrict the list of allowed ciphers for the HTTPS and SIP interface.

D. Cipher String Format

Confirm Unified CM Handling of Erroneous and OpenSSL Formatted Cipher Notation

Return to the Cipher Management page (Security > Cipher Management) on the Cisco Unified OS
Administration interface at https://cucm1.dcloud.cisco.com/cmplatform/. When prompted for username /
password, enter: administrator / dCloud123!
In the SIP TLS input box enter the incorrect cipher string: FOOBAR:ECDHE-RSA-AES256-GCM-
SHA384:FOOBAR

Click Save and then click OK in the reboot cluster pop-up notification box.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 109 of 185
Lab Guide
Cisco dCloud

Observe that Unified CM ignores incorrect string values, in this case, FOOBAR.

It is also worth noting that instead of explicitly specifying each individual cipher, you can enter a string using
the openssl format. For example, enter the string “ALL:!MD5:!SHA” in the SIP TLS input window, click Save
and then OK. This would add all the ciphers that are available except for ciphers based on MD5 or SHA1 for
Message Authentication Code (MAC).

Entering the string “ALL” in the input box is a good way to see which cipher suites can be listed in this
page. But again, note that Unified CM interfaces may not be able to support all the cipher suites that are
listed here, and that the list of supported ciphers depends on each Unified CM interface which may support
a different set of cipher suites. By configuring a list of ciphers on the Cipher Management page, you are
configuring the list of ciphers that are allowed, from the cipher suites that are supported on the interface.
Before proceeding, remove the ciphers you just added by removing the string from the SIP TLS Cipher
String box, clicking Save, and then OK.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 110 of 185
Lab Guide
Cisco dCloud

E. Custom SSH Cipher Configuration

In this section, you will configure a list of cryptographic algorithms for SSH.

Configuring Custom SSH Cipher List

First, review the SSH algorithms that are allowed by default.

Re-run Zenmap on WKST1. In the Command window, enter the following command and click Scan.
nmap --script ssh2-enum-algos 198.18.133.3

You will see the SSH cipher information that are allowed by default on Unified CM.

NOTE: You may need to scroll down to see the full list of SSH ciphers.

Now, you will customize the list of allowed cryptographic algorithms.

Return to the Firefox browser and the Unified CM OS Administrator interface
(https://cucm1.dcloud.cisco.com/cmplatform/). Return to the Cipher Management configuration page
(Security > Cipher Management).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 111 of 185
Lab Guide
Cisco dCloud

Navigate to Help > This Page and a new tab should open. Click the Recommended Ciphers link to see the
recommended ciphers, as shown previously (refer to previous figure). Like the list for TLS, the
recommended SSH crypto parameters are provided on this page.

Copy (Control-C) and paste (Control-V) the SSH Ciphers, SSH KEX for Non-FIPS, and SSH MAC
parameters to the corresponding SSH input boxes on the Security > Cipher Management page.

Click Save and then OK.

In the case of SSH cipher suite changes, you must fully restart the Unified CM server for these changes to
take effect. In the interest of time, you may choose to bypass this step and simply review the remaining
figures in this section.

NOTE: If you decide to restart Unified CM, it could take as long as 25 minutes to fully return to service. While
you are waiting, you may proceed to Scenario 6 and begin work on the first two sections. Check back

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 112 of 185
Lab Guide
Cisco dCloud

periodically to confirm the Unified CM server has fully restarted. Once the restart is completed, you can
proceed with the remaining proceed with the rest of this scenario.

To restart the Unified CM server, from the Unified CM OS Administrator interface

(https://cucm1.dcloud.cisco.com/cmplatform/), navigate to Settings > Version and click Restart. Click OK
to confirm you want to restart the server.
To confirm the system has fully restarted, periodically attempt to access and login to the Unified CM
Administration web interface at https://cucm1.dcloud.cisco.com/ccmadmin/. Once you can successfully
login to the administration web interface, the restart is complete.
After the Unified CM server restart is complete, return to Zenmap and re-enter the following commandand
click Scan:
nmap --script ssh2-enum-algos 198.18.133.3

You should now see the output as shown in the figure below with all the SSH ciphers you added on the
Cipher Management page.

For SSH, the recommended list of crypto algorithms adds a few algorithms compared to the default list of
crypto algorithms:
• Key Exchange Algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256

• MAC Algorithm: hmac-sha2-256

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 113 of 185
Lab Guide
Cisco dCloud

NOTE: The MAC Algorithm hmac-sha2-512 is not part of the recommended list as it is not currently supported
with the Cisco DRS and CDR functionalities.

For your reference, to see SSH handshakes and the ciphers that are negotiated for SSH session, you should
rely on the logging capabilities of your SSH client. For example, with Unix/Linux/Mac, you can use the
option “-v” when opening an SSH session.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 114 of 185
Lab Guide
Cisco dCloud

In the case of Windows and the PuTTY SSH client, for example, you can enable Putty session logging to
validate the SSH cipher negotiation. In Putty, in addition to entering the Host Name (or IP address) (e.g.
198.18.133.3), select SSH packets under Session > Logging > Session logging and configure a log file
name (for example putty.log in This PC > Local Disk (C:) > Users > amckenzie.DCLOUD).

Before proceeding to the next scenario, close the Nmap – Zenmap GUI application.

*** END OF SCENARIO ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 115 of 185
Lab Guide
Cisco dCloud

Scenario 6. Secure Integration with Cisco Unified Border Element (CUBE)

Value Proposition: Collaboration security with encrypted calling not only applies to collaboration applications
like Unified CM and endpoints, but it also applies to traffic sent to and from IP or PSTN gateways. SIP traffic
between Unified CM and a Cisco Unified Border Element (CUBE) can be encrypted with TLS and media traffic
between endpoints and a CUBE can be encrypted sRTP. Encrypted traffic to the IP/PSTN gateway edge is
becoming an increasingly common requirement for many deployments.

Summary

In this scenario, you will enable secure integration between Unified CM and Cisco Unified Border Element
(CUBE) for secure calling to the PSTN / public network edge. You start this scenario by setting up, issuing, and
managing CUBE certificates. After this, you will enable encryption on CUBE, followed by configuring encryption
on the Unified CM SIP trunk to CUBE. Finally, you will make a test call to confirm encrypted integration with
CUBE.

This scenario is split into the following four sections:

A. Manage CUBE Certificates

B. Enable Encryption on CUBE

C. Unified CM Secure SIP Trunk Configuration for CUBE

D. Verify Encrypted Calling between Endpoints through CUBE

The figure below depicts the topology and relevant components for this scenario.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 116 of 185
Lab Guide
Cisco dCloud

Steps

A. Manage CUBE Certificates

In this section you will enable a security trustpoint on CUBE and manage certificates. This is required before you
can enable encryption and secure integration with Unified CM.

For this trustpoint, you will create an RSA key pair (crypto key generate rsa command), create the trustpoint
(crypto pki trustpoint command), import the CA certificate (crypto pki authenticate command), generate a
CSR (crypto pki enroll command), and import the certificate (crypto pki import certificate command) after
issuing it with the enterprise CA.

Create an RSA Key Pair

The first step for managing and enabling encryption on CUBE is to generate a general-purpose key pair to be
used as the foundation for system encryption.

If not already connected, RDP to WKST1 (198.18.133.36) and login with username / password:
DCLOUD\amckenzie / dCloud12345!
Next, SSH to the CUBE (cube1.dcloud.cisco.com) command line interface by using PuTTY on WKST1.

Double-click the PuTTY icon [ ] to launch. In the Host Name (or IP Address) field, enter
cube1.dcloud.cisco.com. Click Open. If prompted, click Yes to cache the ssh-rsa2 key.

Log in with username/password: admin / dCloud123!. Once logged in, enter configuration mode by
entering:
config t

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 117 of 185
Lab Guide
Cisco dCloud

Enter the following command to generate a secure key pair:

crypto key generate rsa general-keys label cube1 modulus 2048

Create a PKI trustpoint for Cisco Unified Border Element (CUBE)

Next, you will create a trustpoint and associate the key pair you created in the previous step. This is the trust
anchor for generating our certificate signing request.

Enter the following commands at the configuration mode prompt:

crypto pki trustpoint cube1-certificate
enrollment terminal pem
subject-name CN=cube1.dcloud.cisco.com
revocation-check none
rsakeypair cube1
hash sha256

Authenticate the trustpoint with the CA and accept the CA certificate.

Next, you must authenticate the trustpoint using the Enterprise CA root certificate, which will sign the CUBE
certificate. This effectively imports the CA certificate into the trustpoint. To begin you must download the
Enterprise CA root certificate in base 64 format and copy the contents to the CLI. From the Firefox browser
on WKST1 (198.18.133.36, DCLOUD\amckenzie / dCloud12345!), browse to
https://ca.dcloud.cisco.com/certsrv. Login with username / password: administrator / dCloud12345!

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 118 of 185
Lab Guide
Cisco dCloud

Click the Download a CA certificate, certificate chain, or CRL link. On the next screen, tick the Base 64
encoding method, and then click Download CA Certificate.

Put a tick beside Open With and click Browse. Select Windows Wordpad Application (or Notepad) and
click OK. Click OK again to open the Certificate.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 119 of 185
Lab Guide
Cisco dCloud

The Wordpad application will open and the base 64 encoded certificate will be displayed. Select and copy
(press Control-C) the contents of the base 64 encoded CA root certificate (including the blank line at the
end) to the clipboard.

NOTE: The certificate string shown above may be different in your demo pod.

Return to the SSH PuTTY session to CUBE. If the previous session has ended, open a new SSH connection
and log back in (cube1.dcloud.cisco.com, admin / dCloud123!).
If not already in configuration mode, enter that mode with conf t and then enter the following command to
start the authentication process:
crypto pki authenticate cube1-certificate

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 120 of 185
Lab Guide
Cisco dCloud

At the resulting authentication prompt, Paste (right click) the CA root certificate you just copied to the
clipboard. Press Enter to signify the end of the certificate and then type ‘yes’ when prompted and press
Enter to import the certificate.

NOTE: The certificate string shown above may be different in your demo pod.

Enroll the trustpoint with the CA Server

Now that you have imported the Enterprise CA root certificate, you can proceed with enrolling or generating a
certificate signing request (CSR) for the CUBE certificate.

At the configuration prompt, enter the following command:

crypto pki enroll cube1-certificate

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 121 of 185
Lab Guide
Cisco dCloud

When prompted to include the router serial number and IP address, type ‘no’. When prompted to display
the certificate request to the terminal, type ‘yes’. The figure below shows the enrollment sequence and the
resulting CSR.

NOTE: The certificate request string shown above may be different in your demo pod.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 122 of 185
Lab Guide
Cisco dCloud

Type ‘no’ at the redisplay enrollment request prompt and then copy the CSR contents to the clipboard
(select with mouse to automatically copy to clipboard). You will use this to sign the certificate with our
Enterprise CA.

NOTE: The certificate request string shown above may be different in your demo pod.

Issue the CUBE Certificate with the Enterprise CA

Now you will generate a CA-signed certificate for the CUBE using our enterprise CA (ca.dcloud.cisco.com)
Use the Firefox web browser on WKST1 (198.18.133.36) and return to https://ca.dcloud.cisco.com/certsrv.
Log in using the username / password: administrator / dCloud12345! if prompted to authenticate.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 123 of 185
Lab Guide
Cisco dCloud

Click Request a certificate. Click Or, submit an advanced certificate request.

Paste (Control+V) the contents of the clipboard (copied from the CSR in the previous step) to the Base-64-
encoded certificate request field.

NOTE: When pasting the CSR, make sure there are not extra spaces or carriage returns at the end of the
certificate request. The last character of the request should be a ‘-‘ (hyphen).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 124 of 185
Lab Guide
Cisco dCloud

Select the ClientServer Certificate Template and click Submit >.

NOTE: The certificate request string shown above may be different in your demo pod.

On the subsequent screen, select/tick Base 64 encoded and then click Download Certificate.

As before, select to Open the downloaded file in the Windows Wordpad Application (click Browse…, select
Wordpad from the applications list, click OK to select, and click OK to open the certificate). Select the
contents of the file, including the blank line at the end and copy (Ctrl+C) to the clipboard.

NOTE: The certificate string shown below may be different in your demo pod.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 125 of 185
Lab Guide
Cisco dCloud

Import the Certificate That Was Just Generated into the CUBE

Now that you have a signed certificate from the Enterprise CA, you must import the certificate to CUBE.

Return to the SSH PuTTY session to CUBE. If required, open a new SSH connection and log back in
(cube1.dcloud.cisco.com, admin / dCloud123!).
Enter configuration mode (conf t), and then enter the following command to import the CA-signed
certificate:
crypto pki import cube1-certificate certificate

At the resulting prompt, paste (right mouse click) the CA-signed CUBE certificate to the terminal and press
Enter to import the certificate. Ensure the certificate is successfully imported before proceeding.

NOTE: The certificate string shown below may be different in your demo pod.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 126 of 185
Lab Guide
Cisco dCloud

Before proceeding, if you have not already done so, close any open Wordpad files to clean up the desktop.

B. Enable Encryption on CUBE

With the certificate management operations out of the way, you now need to enable encryption on CUBE.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 127 of 185
Lab Guide
Cisco dCloud

Enable Secure Signaling

First, you will enable secure signaling by associating the previously created cube1-certificate trustpoint to our
Unified CM.
Return to the SSH PuTTY session to CUBE. If required, open a new SSH connection and log back in
(cube1.dcloud.cisco.com, admin / dCloud123!).
Enter configuration mode (conf t), and then enter the following command to bind the trustpoint to the
Unified CM signaling path:
sip-ua
crypto signaling remote-addr 198.18.133.3 255.255.255.255 trustpoint cube1-certificate

NOTE: The crypto signaling command above is truncated by the terminal and not fully displayed.

Enable TLS Transport for the Dial-Peers

With the secure trustpoint now associated to the Unified CM signaling path, the next step is to enable TLS
encryption for appropriate dial-peers. In this case you will enable TLS encryption on two existing dial-peers:
300 and 400. These dial-peers correspond specifically to inbound call legs from Unified CM (300) and
outbound call legs to Unified CM (400) and ensure encryption is used for the call flow you will be testing.

You should also enable SDP content pass-thru on the inbound dial-peer (300) to ensure that the SDP is
transparently passed through CUBE from inbound call leg to the outbound call leg with no media negotiation.
This provides media cut-through in both directions as quickly as possible.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 128 of 185
Lab Guide
Cisco dCloud

To enable SDP content pass-thru as well as secure signaling for dial-peers 300 and 400, enter the
following commands at the configuration prompt (conf t):
dial-peer voice 300
session transport tcp tls
voice-class sip pass-thru content sdp
!
dial-peer voice 400
session transport tcp tls
!

Configure SRTP Pass-Thru

Once signaling encryption is configured, RTP encryption (SRTP) needs to be configured next. In this step, you
will enable SRTP pass-thru mode. With SRTP pass-thru, stronger ciphers may be used between the source and
destination devices since CUBE simply forwards the encrypted RTP packets without engaging the B2BUA to
decrypt.
Configure SRTP pass-thru mode by entering the following commands at the configuration prompt:
voice service voip
srtp pass-thru

Type ‘Control-Z’ to exit configuration mode. Finally, save the CUBE configuration before proceeding by
entering the following command at the command prompt:
write memory

Close the PuTTY SSH session before continuing.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 129 of 185
Lab Guide
Cisco dCloud

C. Unified CM Secure SIP Trunk Configuration for CUBE

NOTE: If you did a full Unified CM server node restart at the end of Scenario 5 to pick up the new SSH ciphers
you configured, you must wait for the administrative interface to return to service before continuing with this
scenario.

Now that CUBE certificate is signed by our enterprise CA and CUBE can trust certificates signed by our CA, you
are ready to complete the required configuration on the Unified CM system for enabling secure encrypted
integration to CUBE. In this section, you will first configure a secure SIP trunk security profile for CUBE and then
assign that profile to the existing SIP trunk to CUBE.

Configure Secure Encrypted SIP Trunk Profile for the Trunk between Unified CM and CUBE

Using the Firefox web browser on WKST1 (198.18.133.36), navigate to the Unified CM Administrative
interface: https://cucm1.dcloud.cisco.com/ccmadmin and login with username / password: administrator /
dCloud123!

Select System > Security > SIP Trunk Security Profile. Click Add New to create a new profile.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 130 of 185
Lab Guide
Cisco dCloud

In the Name field, type ‘Secure_CUBE_Trunk_Profile’. In the Description field, type ‘Secure SIP Trunk
Security Profile for CUBE’. From the Device Security Mode dropdown, select Encrypted. The fields
Incoming Transport Type, Outgoing Transport Type, and Incoming Port automatically update to TLS, TLS,
and 5061 respectively. For the X.509 Subject Name, enter the common name (CN) used in your CUBE
certificate: cube1.dcloud.cisco.com. Click Save to create the new profile.

Apply the Encrypted SIP Trunk Profile to the SIP Trunk to CUBE

Now secure the existing SIP trunk to CUBE by applying this new encrypted SIP trunk security profile.

On Unified CM (cucm1.dcloud.cisco.com) navigate to Device > Trunk and click Find. Locate the SIP trunk
for CUBE: cube1_SIP_Trunk. Click the trunk name to pull up the configuration page.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 131 of 185
Lab Guide
Cisco dCloud

To update the trunk configuration, put a check mark by SRTP Allowed. Select the SIP trunk security profile
you just created (Secure_CUBE_Trunk_Profile) from the SIP Trunk Security Profile dropdown and change
the SIP Trunk Destination Port to 5061.

Click Save [ ].

NOTE: If clicking Save returns the error “Update failed. Cannot use UnknownStripDigits when the Default prefix
is used”, click Clear Prefix Settings for both the Incoming Calling Party Settings and for the Incoming Called
Party Settings.

Click OK on the subsequent dialog and then click Reset [ ]. Click Reset on the subsequent dialog
to reset the trunk. Once the message “Reset request was sent successfully.” is returned, click Close.
Before proceeding, ensure this SIP trunk returns to service (takes approximately 1 minute).

D. Verify Encrypted Calling between Endpoints through CUBE

Now you will make a test call between the on-premises Jabber clients through the CUBE to confirm the secure
integration to CUBE.

Make a Call through CUBE to Confirm Secure Integration with Encryption

On WKST1 (wkst1.dcloud.cisco.com), open the Jabber client by double-clicking the Jabber icon on the
desktop and ensure the client fully connects and registers.
If not already connected to WKST2 (wkst2.dcloud.cisco.com), RDP there and login with DCLOUD\aperez /
dCloud12345!. Once connected, open the Jabber client by double-clicking the Jabber icon on the
desktop. Ensure the client fully connects and registers.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 132 of 185
Lab Guide
Cisco dCloud

Once both clients are fully connected, place a call from Anita Perez’s Jabber client (WKST2) through CUBE
to Adam Mckenzie’s Jabber client (WKST1) by dialing: 915025551116 and click green Call icon.

This call routes to CUBE by virtue of the 91 prefix. CUBE translates the number from 915025551116 to
4085551116 before routing back to Unified CM ,which prefixes +1 to reach Adam Mckenzie at +14085551116.
Answer the incoming call on Adam Mckenzie’s Jabber client. When the call is connected, note that lock
icons are displayed indicating not only that the media is encrypted, but also that the signaling path between
Unified CM and CUBE is encrypted.

The following commands can also be run at the command line on cube1 to verify the call is encrypted:
show sip-ua calls
show sip-ua connections tcp tls detail
show sip-ua srtp

Before proceeding, hang up the call by clicking the end call softkey [ ], exit the Jabber for Windows
clients (WKST1 and WKST2), and close any open SSH or browser sessions.
*** END OF SCENARIO ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 133 of 185
Lab Guide
Cisco dCloud

Scenario 7. Secure Hardware Endpoint Onboarding

Value Proposition: Onboard new hardware endpoints for users by entering a 16-digit code when the device
connects to Unified CM for the first time. This simplifies day-to-day maintenance and support for collaboration
deployments.

Summary

The scenario discusses the configuration and operation of secure hardware endpoint onboarding with system
generated 16-digit activation codes. The scenario is divided into the following three sections:

A. Setting up Secure Onboarding for On-Premises Devices

B. Complete and Validate Secure Onboarding for On-Premises Devices [Review Only]

C. Activation Code Onboarding for Expressway MRA Devices [Review Only]

NOTE: Section A is the only section that can be completed in this scenario without hardware (router and IP
phone). Section B is for your review. If you connect a router to your demo pod, you would be able to onboard
an 8865 (as provisioned in Section A) or another 7800 or 8800 series phone as outlined in Section B.
Section C is strictly for review as activation code onboarding for Expressway MRA is not supported with
Specific License Reservation (SLR). Activation code onboarding with MRA requires Unified CM to communicate
with cloud services (namely global data services) and SLR is intended for systems that are unable to
communicate with the Internet and thus cloud-based services. In addition, the versions available and running in
this lab are not officially supported. This section provides a review of activation code onboarding with MRA on a
fully supported system.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 134 of 185
Lab Guide
Cisco dCloud

The figure below depicts the topology and relevant components for this schedule.

Secure Onboarding

What does this feature do for the customer? What is the customer problem that this feature solves?

Activation Code Onboarding allows an administrator to create phone records in Unified CM without needing to
know the physical phone’s MAC address in advance and unlike auto registration keeps control over which
phones can be onboarded.
Phone onboarding is controlled using a simple 16-digit one time use activation code that is generated for each
phone record when the administrator creates phone records without MAC addresses in Unified CM.

This reduces the cost of installation of phones as any phones (of the correct model type) can be distributed to
users rather than having to install a specific phone with a known MAC address to each user and the activation
code onboarding process is simple enough to be carried out by the end users themselves.

As of this writing, the following phone models are supported:

7811, 7821, 7832, 7841, 7861, 8811, 8841, 8845, 8851, 8851NR, 8861, 8865, and 8865NR.

Functionality Details

The following guidelines apply to secure hardware phone onboarding:

• A phone can be added via the Unified CM Administrative GUI or via AXL and configured to require activation
code for onboarding. Note that activation codes are assigned to specific phone records and will only work
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 135 of 185
Lab Guide
Cisco dCloud

with that specific phone (if a MAC address is provided) or a phone of that record’s identical model (if no
MAC address is provided).

• An administrator can use BAT to enter several phones and enable each phone to require activation code for
onboarding. This method does not require the use of TAPS on an extra server, nor does it require auto
registration for the phone to convert the device name from BAT{mac} to SEP{mac}.

• Once a phone is marked to require activation code for onboarding, then that phone will be reset if it is
registered and will not be allowed to register until onboarding is complete and the activation code has been
verified. The phones MIC will also be verified to ensure that only genuine Cisco phones are onboarded.
• Distribution of the activation codes is manual, or if a user is assigned to the phone, then the user can view
the activation code on the Self Care Portal. Additionally, the codes are available via AXL to enable
automation of delivery.
• Auditing of access of the activation codes is provided by the system.

• Activation codes are 16 digits long (e.g. 1234-5678-9012-3456) These codes are verified by the system
during onboarding.

• Phones will poll Unified CM in the background for configuration changes while waiting for the user to enter
an activation code. This allows an admin to revert to MAC address configuration without needing the user to
interact with the phone.

• Administration GUI allows device name change between BAT{mac} and SEP{mac}.

Registration Flow

The figure below the hardware endpoint onboarding registration flow:

Administrator enables activation codes.

Administrator creates full device configuration without specifying MAC address (BAT, AXL, GUI).

Administrator requests activation code for this device.

Activation code is sent to the user by the administrator, or the end user gets it via the Self Care Portal.

Phone gets Unified CM target from DHCP opt 150/TFTP or uses statically configured alternate TFTP,
downloads the XMLDefault file, detects that activation code onboarding is in use, and the user enters the
activation code.

Phone authenticates to Unified CM using MIC + activation code in a secure remote password (SRP)
handshake.
Device activation service updates device configuration in the database with phone MAC and sends success
to the phone. The phone can now get its phone-specific configuration file from TFTP like normal, and
register with Unified CM.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 136 of 185
Lab Guide
Cisco dCloud

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 137 of 185
Lab Guide
Cisco dCloud

Steps

A. Setting up Secure Onboarding for On-Premises Devices

Set Device Default for the Phone Model(s) That You Want to Setup for Secure Onboarding
with Activation Code

From WKST1 (wkst1.dcloud.cisco.com), use Firefox to browse to the Unified CM Administration interface
(https://cucm1.dcloud.cisco.com/ccmadmin/). If prompted, login with username / password: administrator
/ dCloud123!. Navigate to Device > Devices Settings > Device Default.

The Device Defaults page is where the administrator specifies the phone model or models that will use secure
onboarding with activation code. In this case, you will enable activation code for the Cisco 8865 phone model.

Scroll down the Device Defaults Configuration page to find the 8865 phone model near the bottom of the
page. Set the onboarding method for the Cisco 8865 to Activation Code. Click Save to complete the
configuration change.

NOTE: If you plan to connect a VPN router and a Cisco 7800 or 8800 series phone to this demo pod, select the
phone model you plan to connect rather than the Cisco 8865 model shown below.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 138 of 185
Lab Guide
Cisco dCloud

Add the Device to Unified CM

Once the onboarding method is configured on the Device Defaults page, the next step is to add the device to
Unified CM.
Navigate to Device > Phone and click Add New (step 1). Then, select Cisco 8865 from the Phone Type
drop-down list (step 2) and then click Next (step 3).

NOTE: If you plan to connect a VPN router and a Cisco 7800 or 8800 series phone to this demo pod, select the
phone model you plan to connect rather than the Cisco 8865 model shown below.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 139 of 185
Lab Guide
Cisco dCloud

Configure the New Cisco 8865 Device

You do not need to enter a device MAC address. Leave the field blank, but ensure that you have selected
Require Activation Code for Onboarding.

Input additional configuration parameters (particularly those in required fields) for the onboarded phone
including: Device Pool (Default), Phone Button Template (Standard 8865 SIP), Calling Search Space
(Main-CSS), Device Security Profile (Cisco 8865 – Standard SIP Non-Secure Profile), and SIP profile
(OPTIONS Ping Standard SIP Profile).

NOTE: If you plan to connect a VPN router and a Cisco 7800 or 8800 series phone to this demo pod, select the
phone button template and security profile that matches phone model you plan to connect.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 140 of 185
Lab Guide
Cisco dCloud

Be sure to associate the phone to an end user (Owner User ID), in this case Adam Mckenzie. This in turn,
associates the user to the activation code for this device and helps if you are giving this phone directly to an
end user. By logging into the Unified CM end user Self Care Portal, the user can retrieve the phone
activation code and perform onboarding, with no requirement for the administrator to supply the code to the
user.

Click Save and then click OK to acknowledge the Apply Configuration warning. You do not need to apply
the configuration now as you still need to configure the line.
On the refreshed page, click Line [1] Add a new DN (step 1). On the next page, enter \+14085551116 in
the required Directory Number field (step 2). Click Save twice (step 3).

NOTE: After clicking Save the first time you will see the message “Directory Number Configuration has
refreshed due to a directory number change…” (figure above, step 3). When you click Save the second time,
you should see the “Update successful” message (figure above, step 4).

Click Go in the Related Links area in the upper right-hand corner of the page to return to the main device
configuration page.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 141 of 185
Lab Guide
Cisco dCloud

On the device page, you will now see the MAC address field on the phone configuration page is populated
with a ‘dummy’ / BAT MAC address placeholder, which will change to the actual MAC address of the phone
that is onboarded once the activation code is used. You should also see the View Activation Code link on
the device page.

NOTE: The ‘dummy’ MAC address of your new device will not match the MAC address shown in the figure
above.

Click the View Activation Code link to view the 16-digit Activation Code for this device.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 142 of 185
Lab Guide
Cisco dCloud

NOTE: The device name and activation code of your new device will not match the information shown in the
figure above.

View the user-facing activation code on the Self Care Portal. Because the new phone you just added was
associated to a user (Adam Mckenzie), that user can view the activation code from the Self Care Portal.
From the Firefox browser on WKST1 (wkst1.dcloud.cisco.com), open a New Private Window using the
keyboard shortcut Ctrl+Shift+P. You will use this window to navigate to the Self Care Portal at
https://cucm1.dcloud.cisco.com/ucmuser. Enter Username / Password: amckenzie / dCloud12345! and
click Sign In. Once logged in, the user will see any devices they have been provisioned for under My
Phones. Notice the new Cisco 8865 device you just configured with status of Requires Activation. The
user can retrieve the activation code by clicking on the device tile and selecting View Activation Code
from the context menu.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 143 of 185
Lab Guide
Cisco dCloud

The administrator can see the same onboarding Activation Code displayed on the device configuration page.

B. Complete and Validate Secure Onboarding for On-Premises Devices

[Review Only]

NOTE: Because there are no hardware phones required for this lab, this section is just for your reference, so
you understand the activation code onboarding operation at the phone. Should you choose to connect a router
to this lab, you can then connect a hardware phone over the VPN connection and complete the steps in this
section.

Complete Secure Phone Onboarding at the Phone by Entering the 16-digit Activation Code
[Review Only]

With all configuration now in place for secure phone onboarding, when the user connects the phone to the
network, they will receive the Scan QR code to get started because the phone has a camera that can be used
to scan the activation code QR code. The user can also enter the activation code manually by tapping the Enter
manually softkey (step 1). The phone now prompts the user to Enter activation code or service domain (step
2).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 144 of 185
Lab Guide
Cisco dCloud

NOTE: If you plug any 7800 or 8800 series phone into a VPN router connected to this lab, they will upgrade (or
downgrade) to the current default firmware version on the system: 12.5(1)SR3. These devices should still
register and operate as shown here, but you may notice a reboot of the device when the firmware
upgrade/downgrade completes.

NOTE: If a phone device other than a Cisco 8865 (or whichever phone model you chose to enable for activation
code) is plugged into a VPN router connected to this lab, it will auto register rather than prompting for an
activation code.

Once the prompt is displayed, the user simply enters the 16-digit activation code (step 1) and then touches
the Continue softkey (step 2).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 145 of 185
Lab Guide
Cisco dCloud

Once code is entered and the Continue softkey is pressed, the phone begins the registration process.

Confirm Device Registration to Unified CM [Review Only]

Ensure the phone registers fully with the configuration and directory number that were provisioned on
Unified CM for Adam Mckenzie’s 8865.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 146 of 185
Lab Guide
Cisco dCloud

Verify the Phone Status on Unified CM [Review Only]

Return to the Unified CM Administration interface (https://cucm1.dcloud.cisco.com/ccmadmin/) and

navigate to Device > Phone and click Find to locate the phone. Select the 8865 phone device that was just
onboarded for Adam Mckenzie and on the configuration page, confirm the device is registered. Notice that
once the activation code is leveraged for onboarding, it is no longer available in the Unified CM GUI.
Further, note the MAC address of the phone is changed from the dummy MAC/BAT to the actual device
MAC of the device.

In addition to retrieving individual activation codes from the Unified CM Administration interface and the Unified
CM User Self Care portal, activation codes may also be exported in bulk.
To locate a group of hardware endpoints with valid activation codes, navigate to the phone configuration
page (Device > Phone). In the Related Links drop-down list select, the Export Activation Codes option
(step 1). Click Go (step 2).

NOTE: You will not see any entries in the Export Activation Code report because you do not have any additional
phones provisioned with activation code. If you did, the activation codes would be shown in this report.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 147 of 185
Lab Guide
Cisco dCloud

C. Preview of Activation Code Onboarding for Expressway MRA Devices

[Review Only]

In this section you will review activation code onboarding for phones connecting over Expressway MRA. As
noted at the beginning of this scenario, Specific License Reservation (SLR) licensing is not compatible with
MRA activation code onboarding. Because SLR is in place for this demo pod, MRA activation code onboarding
will not be possible. This section provides an overview of the operation, including screen captures that will help
you understand how the configuration works. The same administrative efficiencies discussed in the prior
section will also apply to MRA phones, plus there will be a significant improvement in the MRA end user
experience with activation code onboarding.

Today all Cisco IP phones deployed over Expressway MRA require a service domain, username, and password
to be entered on the phone’s keypad. This alphanumeric entry is a less than ideal end user experience, and it’s
even worse when complex passwords need to be updated on a regular basis. The new experience will replace
the service domain, username, and password entry with a one-time 16-digit numeric activation code.

Typically, devices deployed over Expressway MRA do not have the luxury of relying on DHCP option 150 to
discover how to connect to Unified CM. Rather these devices rely on DNS SRV records to discover
Expressway-E and connect to Unified CM. One fundamental difference over the on-premises onboarding is the
Unified CM will need to communicate with the Cisco Cloud to allow MRA activation code onboarding. The Cisco
cloud will then provide activation codes to Unified CM upon request and redirect devices to the admin specified
Expressway-E by providing an MRA service domain to the device. This (outbound only) communication over
HTTPS from Unified CM to the Cisco Cloud can be direct or established through an HTTP(S) proxy.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 148 of 185
Lab Guide
Cisco dCloud

The figure above illustrates the activation code onboarding flow for Expressway MRA devices. The steps are
described below.
Unified CM administrator enables Activation Code Onboarding with Cisco Cloud with an MRA service
domain.

Administrator creates full device configuration without specifying MAC address (BAT, AXL, GUI).

Administrator requests activation code for a device. The Unified CM Activation service gets code from GDS
(Global Discovery Service - a Cisco Cloud micro-service).

Activation code sent to a user/administrator.

User enters activation code. Phone learns MRA service domain from GDS.

Phone resolves Expressway-E address and authenticates using MIC (manufacturing installed certificate) +
activation code in a TLS secure remote password (SRP) handshake.
Device activation service updates device configuration in the database with phone MAC and sends a 200
OK to the phone that includes OAuth refresh and access tokens. The phone can now use the access token
for the get_edge_config and device specific configuration from TFTP service like normal MRA, and register
with Unified CM.

Unified CM Activation service releases code from GDS.

Steps to Setup Expressway MRA Activation Code Onboarding

In this section the configuration aspects specific to MRA activation code onboarding will be detailed. Many of
the same configuration steps covered in the previous section including provisioning devices on Unified CM
without MAC addresses, requesting and accessing activation codes are pretty much identical for onboarding
MRA devices.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 149 of 185
Lab Guide
Cisco dCloud

Unified CM Configuration

The first configuration step involves enabling the Unified CM for MRA activation code onboarding and providing
an MRA activation domain. This domain will be the default MRA service domain that devices will learn in the
activation sequence from the Cisco Cloud and use to lookup the _collab-edge._tls DNS SRV record. The
following configuration may look similar if you have ever enabled Apple Push Notifications for Jabber iOS
devices. However, there are new options highlighted below on this existing Unified CM Cisco Cloud Onboarding
configuration page.

NOTE: Given the requirement for cloud onboarding, secure onboarding with activation code over MRA is not
supported with SLR deployments. As noted previously, SLR is specifically designed for systems that are not
able to access cloud services and as such cloud onboarding for MRA activation code is not compatible.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 150 of 185
Lab Guide
Cisco dCloud

There is a new Unified CM menu under Advanced Features > MRA Service Domain that allows administrators
to configure additional MRA Service Domains. This is an option that makes sense when the Unified CM cluster
is accessed via multiple Expressway-C/E clusters in different regions. One of the domains will be default, but
the other domains can be established as a default at the device pool level or used with individual devices.

Different MRA service domains can be established at the device pool level.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 151 of 185
Lab Guide
Cisco dCloud

There are a couple differences specific to onboarding phones for MRA highlighted below in the phone
configuration. First, an administrator will need to require activation code onboarding as usual, and additionally
the administrator will need to check the box to Allow Activation Code MRA Mode. The available MRA service
domains will also be an option that can be set individually on the phone configuration page rather than at the
system default or device pool default domain, if required.

At this point, administrator-requested device activation codes for MRA will be provided from the Cisco Cloud
and can be retrieved by an administrator or user using all the same methods mentioned in the on-premises
onboarding section. This step concludes the Unified CM configuration requirements, but there is an additional
step required on Expressway-C to allow MRA device onboarding to work.

Expressway Configuration

On Expressway-C, the Configuration > Unified Communications > Configuration menu includes an access
control section that dictates the supported authentication and authorization methods available to MRA devices
and clients. For MRA activation code onboarding, the authentication path setting is not relevant since these
devices will not be using SSO or basic username and password authentication.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 152 of 185
Lab Guide
Cisco dCloud

Instead the Allow activation code for onboarding setting will need to be enabled. Additionally, the Expressway
needs to be configured to allow Authorize by OAuth token with refresh. If the Expressway-C was not already
configured to allow OAuth with refresh, you would need to refresh the Unified CM cluster from Expressway-C.

Once this configuration is established on the Expressway-C, it will be propagated to the Expressway-E over the
UC Traversal zone. The Expressway-E will then update the reverse proxy service configuration and TCP port
8443 port will request client certificates in all TLS handshakes with all MRA clients or devices. This
configuration doesn’t require a client certificate to establish a TLS connection, but it does gate access to the
two new activation code onboarding APIs to only devices that present valid Cisco manufacturing installed
certificates.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 153 of 185
Lab Guide
Cisco dCloud

There is a new dedicated trusted CA list for activation code onboarding on the Expressway-E that is pre-
populated with Cisco manufacturing root and intermediate CAs. This allows the Expressway-E to authenticate
Cisco devices with manufacturing installed certificates.

*** END OF SCENARIO ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 154 of 185
Lab Guide
Cisco dCloud

Appendix A. ECC Certificates for 7800 and 8800 Series Endpoints

NOTE: This appendix section covers steps for deploying and utilizing ECC certificates for Cisco 7800 and 8800
Series endpoints and is for your reference. If you choose to connect a VPN router to your demo pod, you can
complete all the exercises in this section with supported endpoints.

Endpoint ECC Certificates for Encryption

Certificates are traditionally based on the RSA algorithm; however, with RSA, the key size may need to be much
longer than 4096 bits in order to meet very strong cryptographic requirements. Long key processing is very
CPU-intensive. With certificates based on Elliptic Curve Cryptography (ECC) instead of RSA, it is possible to
meet those strong cryptographic requirements with a relatively small key.

The support of ECC certificate for the CallManager service has been introduced since 11.0, but phones did not
support ECC certificate for their own certificate (Locally Significant Certificate or LSC) and they did not support
ECDSA-based cipher suites. This has been addressed with the 12.5 system release.

Steps

A1. Configure Microsoft CA for ECC

Connect to the ECC Microsoft CA Server (ca2.dcloud.cisco.com)

With ECC certificates configured on the Collaboration servers and the endpoints, the CA would typically also
use an ECC certificate for itself. In this step, you will configure ECC on ca2.dcloud.cisco.com (NOT
ca.dcloud.cisco.com, which is based on RSA).
RDP to ca2.dcloud.cisco.com (198.18.133.2) and login with username / password: DCLOUD\administrator
/ dCloud12345!

Once connected, confirm this is the correct CA server. The desktop should be labeled with
“ca2.dcloud.cisco.com…”. If the desktop label is different, it is the wrong server (or you have logged in
with the wrong account).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 155 of 185
Lab Guide
Cisco dCloud

Launch Certificate Authority Console

Launch the Certificate Authority. Click the Start menu (step 1) and type “certsrv.msc” (step 2). Click to
launch (step 3).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 156 of 185
Lab Guide
Cisco dCloud

Create a New ECC Certificate Template on the Enterprise Certificate Authority

Once the Certificate Authority console is loaded, expand dcloud-CA-EC (step 1). Then, right click the
Certificate Templates folder (step 2) and select Manage (step 3).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 157 of 185
Lab Guide
Cisco dCloud

Once the Certificate Templates console opens, select ClientServer in the template list, right click and
select Duplicate Template.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 158 of 185
Lab Guide
Cisco dCloud

In the Properties of New Template dialog, under the General tab, type “EC ClientServer” as the template
display name. Do NOT click Apply yet. Note that the actual Template name (not the template display
name) is ECClientServer, which will be used when running the CLI command later.

Go to the Compatibility tab and select the following values:

• Certificate Authority: Windows Server 2008

• Certificate recipient: Windows Vista / Server 2008

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 159 of 185
Lab Guide
Cisco dCloud

Click OK in the Information message window showing the resulting changes. Do NOT click Apply yet.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 160 of 185
Lab Guide
Cisco dCloud

On the Cryptography tab, select or type in the following value. Then click Apply.

• Provider Category: Key Storage Provider

• Algorithm name: ECDH_P384

• Minimum key size: 384

• Request Hash: SHA256

NOTE: If you clicked Apply before this previous step, then you wouldn’t be able to change the Provider
Category.

Click OK to save the template and close the template properties window. Finally, close the Certificate
Templates Console window.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 161 of 185
Lab Guide
Cisco dCloud

Make Available (Issue) the ECC Certificate Template on the Enterprise CA

Once this new certificate template is saved, in order for the template to be available on the Certificate Authority
for template, you need to add or issue the certificate template on the CA.
In the Certificate Authority Console window, again right-click Certificate Templates, click New, and then
select Certificate Template to Issue.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 162 of 185
Lab Guide
Cisco dCloud

Select the Certificate Template that was just created (EC ClientServer) and click OK.

NOTE: If there is an error, restart the Certificate Authority service by selecting dCloud-CA-EC, and then
clicking on the stop then the start icon

The EC ClientServer template is now visible in the Certificate Authority Certificate Templates list. Close the
Certificate Authority Console.

A2. Issue and Install a CA-Signed CallManager-ECDSA Certificate

A CallManager-ECDSA certificate is already available during a fresh Unified CM installation, but that certificate
is self-signed. In this section, you will issue a new CallManager-ECDSA certificate that will be issued by a CA
instead of being self-signed.

Generate a CSR for the CallManager-ECDSA Certificate

On the CA2.dcloud.cisco.com server (NOT on WKST1 or WKST2), open Firefox and go to the Unified CM
OS Administration interface (https://cucm1.dcloud.cisco.com/cmplatform/) from the Firefox web browser.
Login with username / password: administrator / dCloud123!

Navigate to Security > Certificate Management.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 163 of 185
Lab Guide
Cisco dCloud

Click Generate CSR and select CallManager-ECDSA for the Certificate Purpose. Use the default value for
the other settings. Click Generate and then Close.

Download the CallManager-ECDSA CSR

Click Download CSR. In the next window, ensure CallManager-ECDSA is selected for the Certificate
Purpose field, as shown in Figure A.11, and click Download CSR.

Save the file in the default location (Downloads folder) and close the Download Certificate Signing
Request dialog.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 164 of 185
Lab Guide
Cisco dCloud

Submit the Endpoint ECC CSR to the Enterprise CA for Signing

The next step is to issue a signed ECC certificate from the Enterprise CA based on the CallManager-ECDSA
CSR.
To open a command line prompt, click the Start menu (step 1) and type cmd (step 2). Click Command
Prompt at the top to launch (step 3).

Once the command prompt is available, go to openssl folder by entering the following command at the
prompt:
cd Downloads

In the command prompt, run the following command to generate a CA signed certificate:
certreq.exe -submit -attrib "certificateTemplate:ECClientServer" CallManager-ECDSA.csr

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 165 of 185
Lab Guide
Cisco dCloud

Click OK when prompted with the Certification Authority List. Save the new certificate in the Downloads
folder with the name CallManager-ECDSA.pem.

NOTE: The RequestId in your pod may be different than the one shown in the figure above.

Type exit and press Enter to close the command prompt window.

Download the CA2 Root Certificate

Before you can upload the new CallManager-ECDSA certificate to Unified CM, you will need to upload the CA2
root certificate to the CallManager-trust store.
From the Firefox browser, navigate to https://ca2.dcloud.cisco.com/certsrv. When prompted, login with
username / password: administrator / dCloud12345!

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 166 of 185
Lab Guide
Cisco dCloud

Click the Download a CA certificate, certificate chain, or CRL link (step 1), then click the Download CA
certificate link (step 2), and finally, click OK to save the certificate to the Downloads directory (step 3).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 167 of 185
Lab Guide
Cisco dCloud

Before proceeding to the next step, rename the CA2 EC root certificate so it will be easy to identify when
you upload the certificate to Unified CM. Click the Downloads icon (step 1), then the Folder icon (step 2).
Next, click the file named certnew (step 3) and rename to dCloud-CA-EC (step 4).

Install the CA2 Root Certificate and CallManager-ECDSA Certificate

Return to the Firefox browser and the Unified CM OS Administration interface page
(https://cucm1.dcloud.cisco.com/cmplatform/ - if prompted re-login with username / password:
administrator / dCloud123!

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 168 of 185
Lab Guide
Cisco dCloud

Navigate back to Security > Certificate Management and click Upload Certificate/Certificate chain (step
1). Select CallManager-trust for the Certificate Purpose field, type “dCloud-CA-EC” in the Description
field, and select the dCloud-CA-EC file you just renamed (by clicking on Browse, click Open to select) (step
2). Next, click Upload (step 3). Finally, ensure the certificate is successfully uploaded before clicking to
close the upload window (step 4).

NOTE: Do not restart the CallManager and TFTP services at this time. You will restart these services later.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 169 of 185
Lab Guide
Cisco dCloud

Now you will repeat these same steps to upload the CA2 signed CallManager-ECDSA certificate. Again,
click Upload Certificate/Certificate chain, but this time select CallManager-EDCSA for the Certificate
Purpose field. Click Browse, select the CallManager-ECDSA.pem file, click Upload, and close the
window.

NOTE: For the purposes of this lab, you can ignore the message about regenerating the CTL file.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 170 of 185
Lab Guide
Cisco dCloud

Restart the TFTP and CallManager Services

Browse to the Cisco Unified Serviceability interface (https://cucm1.dcloud.cisco.com/ccmservice/) and

login in with username / password: administrator / dCloud123!. Navigate to Tools > Control Center
(Feature Services). Tick the radio button next to Cisco Tftp and click Restart. Once the system responds
that the Cisco TFTP service is restarted, tick the radio button next to Cisco CallManager and click Restart
again.

A3. Configure CAPF in Offline CA Mode

Enable Endpoint Advanced Encryption Algorithms Support

On the CA2.dcloud.cisco.com server, open Firefox and go to the Unified CM Administration portal
(https://cucm1.dcloud.cisco.com/ccmadmin/) and login with username / password: administrator /
dCloud123! (if required).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 171 of 185
Lab Guide
Cisco dCloud

Navigate to System > Enterprise Parameters. Scroll down to the Security Parameters section and look for
the option Endpoint Advanced Encryption Algorithms Support setting. Change this option to Enabled.
Click OK to acknowledge the warning, and then click Save.

NOTE: Do not restart the TFTP services at this time. You will restart this service later.

Configure CAPF for Offline CA Mode

Navigate to System > Service Parameters to enable Offline CA mode.

Under Select Server and Service, select cucm1.dcloud.cisco.com--CUCM Voice/Video (Active) from the
Server drop down and select Cisco Certificate Authority Proxy Function (Active) from the Service drop
down.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 172 of 185
Lab Guide
Cisco dCloud

Select Offline CA from the Certificate Issuer to Endpoint drop down to enable Offline CA mode and then
click Save.

Before clicking OK to acknowledge that CAPF service restart is required, note that the Online CA Parameters
you previously configured in Scenario 4 (Online CA Mode for Automatic Enterprise CA Endpoint Certificate
Enrollment) will not take effect now that the Certificate Issuer to Endpoint field is set to Offline CA.

NOTE: Online CA mode is not tested or supported with ECC certificates.

Restart CAPF and TFTP Services

Browse to the Cisco Unified Serviceability interface (https://cucm1.dcloud.cisco.com/ccmservice/) and

navigate to Tools > Control Center (Feature Services). Tick the radio button next to Cisco Certificate
Authority Proxy Function and click Restart.
After the system responds that the CAPF service is restarted, tick the radio button next to Cisco TFTP and
click Restart again.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 173 of 185
Lab Guide
Cisco dCloud

Check the Current System CSR Count

Ensure there is no pending phone CSR. From the ca2.dcloud.cisco.com server, launch Putty and type
“cucm1.dcloud.cisco.com” in the Host Name (or IP Address) field. Click Open. Click Yes to cache the
ssh-rsa2 key.

Log in to Unified CM SSH session with username/password: administrator / dCloud123!. Next, run the
command utils capf csr count and observe that all counts including Valid CSR is 0 since you have not
started the CAPF enrollment.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 174 of 185
Lab Guide
Cisco dCloud

NOTE: If you choose to connect a router to this lab, you can connect a 7800 or 8800 series hardware phones
over the VPN connection and perform the remaining sections of this Appendix. Otherwise, simply review the
remaining sections so you understand the operation required.

A4. Issue and Install an ECC CA-signed Certificate on the Phone

Initiate CAPF Enrollment to Create Phone CSR

Browse to the Unified CM Administrative interface (https://cucm1.dcloud.cisco.com/ccmadmin/) and login

with username / password: administrator / dCloud123!

Navigate to Device > Phone, click Find to locate any hardware phone, for example a Cisco 8865.

NOTE: If you have connected a VPN router to this demo pod and connect a Cisco 7800 or 8800 series phone to
the router, it will auto-register to Unified CM automatically and you can perform this step on that device.
Alternatively, if you completed Schedule 7 (Secure Hardware Endpoint Onboarding), a phone will already be
configured/provisioned.

To install a locally significant certificate (LSC) on the phone, you must set the phone for CAPF enrollment
and specify the EC certificate type Under the Certification Authority Proxy Function (CAPF) Information
section on the phone configuration page. Configure the following settings as shown in the figure below:

• Certificate Operation: Install/Upgrade

This sets the device for CAPF enrollment to install an LSC
• Authentication Mode: By Null String

• Key Order: EC Only

EC (or ECC) Only results in an ECC LSC for the device

• EC Key Size (Bits): 384

• Operation Completes By: Enter date/time at least 1 day in the future

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 175 of 185
Lab Guide
Cisco dCloud

NOTE: You must enter a month, day, and hour (in 2-digit numeric format) in the Operations Complete By field to
complete the configuration.

After saving and applying the configuration change, the Certificate Operation Status should change from
None to Operation Pending and the phone should reboot.

Confirm the CAPF CSR Count

Return to the Putty SSH session with cucm1.dcloud.cisco.com. If required, re-establish the session and
login again with username / password: administration / dCloud123!
Re-run the command utils capf csr count. Note that the Valid CSR count has increased to ‘1’.

Export Phone CSR from Unified CM

Before exporting the phone CSR, enable the TFTP service on the CA2.dcloud.cisco.com server by starting
Ttftpd64 (double-click the desktop icon for Tftpd64).

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 176 of 185
Lab Guide
Cisco dCloud

To export this phone CSR for signing by an external CA, run the command utils capf csr dump (see the
figure below).
Three options to transfer the file are presented: 1) Remote filesystem via FTP, 2) Remote filesystem via TFTP,
and 3) Local Download Directory (which downloads locally to Unified CM and can be retrieved using the file get
command).

The exported file is a tar file located in the C:\Lab directory. Any archiving software could be used to
manage this file. In our case, 7-Zip was used for extracting the phone CSR from the archive file, as shown
in two figures below. Run 7-Zip on ec.csr.tar to extract ec.csr and then run 7-Zip on ec.csr to extract the
SEP<MAC>.csr file.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 177 of 185
Lab Guide
Cisco dCloud

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 178 of 185
Lab Guide
Cisco dCloud

Submit the Endpoint ECC CSR to the Enterprise CA for Signing

The next step is to issue a signed ECC certificate from the Enterprise CA based on our endpoint CSR.

Open a command line prompt. To do that, click the Start menu (step 1) and type cmd (step 2). Click
Command Prompt at the top to launch (step 3).

From the command prompt, go to the C:\Lab folder by typing cd C:\Lab.

Run the following command to generate a CA signed certificate:

certreq.exe -submit -attrib "certificateTemplate:ECClientServer" <PHONE_NAME>.csr ec.pem
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 179 of 185
Lab Guide
Cisco dCloud

Click OK in the Certification Authority List dialog.

The output file for this command as specified will be ec.pem and is in Base 64 format. This file must be
converted to DER format.

Convert the CA Signed Certificate File to .der Format and Then .tar and .gzip

At the command prompt (run as administrator), enter the following command:

openssl x509 -outform der -in ec.pem -out ec.der

NOTE: If openssl cannot be found, fix the path issue by opening windows explorer. Right click This PC, select
Properties, click Advanced system settings, click Environment Variables, then click OK on the last two
windows.

This command converts the file ec.der in b64 format into the file ec.der, which is in DER format.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 180 of 185
Lab Guide
Cisco dCloud

Once the file ec.der is available, leverage any archiving software (7-Zip in this example) to tar this file. Right
click the ec.der in Windows Explorer and select 7-Zip and then Add to Archive….

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 181 of 185
Lab Guide
Cisco dCloud

This brings up the 7-Zip Add to Archive dialog. Select tar in the Archive format drop down. Click OK to
save the archive file.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 182 of 185
Lab Guide
Cisco dCloud

Once ec.tar is created, repeat the above steps to create an archive file of the certificate in gzip (or gz)
format. Rght click the new ec.tar file and Add to Archive…, but this time select gzip in the Archive format
drop down before clicking OK to save this archive file.

The output file will be ec.tar.gz. This file is now ready to be imported into Unified CM.

Import the LSC(s) to Unified CM to Complete the Endpoint LSC Installation

You will import the ec.tar.gz file into Unified CM, which will install the certificate onto the phone.

Launch Putty and start an SSH session to cucm1.dcloud.cisco.com and login with username / password:
administrator / dCloud123!

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 183 of 185
Lab Guide
Cisco dCloud

Once logged in, run the command utils capf cert import .This command imports the file onto Unified
CM and installs the certificate onto the phones. After entering this command, the phone reboots.

To confirm the imported certificate file to Unified CM has been properly processed, return to the phone
device configuration page to review the CAPF status for the hardware device. Based on the CAPF status of
Upgrade Success, you know the phone has successfully completed CAPF enrollment and, in this case,
now has an ECC LSC signed by the Enterprise CA.

Alternatively, you can also go back to the main phone page (Device > Phone) to add a second filter. Click
add icon [ ] and select LSC Issued By with Begins with field blank. Click Find. You should see that the
LSC installation was successful and the LSC was issued by dcloud-CA-EC (CA2).
*** END OF APPENDIX A ***

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 184 of 185
Lab Guide
Cisco dCloud

What’s Next?
For more information about on-premises collaboration security and how to deploy, refer to the Security chapter
of the Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises Deployments CVD available
at: https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/12x/120/collbcvd.html.

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 185 of 185