Lab Guide Cert Security

Cisco dCloud
Collaboration Security for the Enterprise Preferred

Architecture Lab v1 dCloud: The Cisco Demo Cloud
Last Updated: 15-AUGUST-2017
Created by Collaboration Technology Group TME, Collaboration Sales, and dCloud Collaboration Teams
About This Lab

This preconfigured lab includes:
 Requirements
 About This Solution
 Topology
 Session Users
 Get Started
 Scenario 1: Cisco Unified Communications Manager and Endpoint Security
 Scenario 2: Collaboration Application Security
Requirements
The table below outlines the hardware requirements for this Lab
Table 1. Requirements
Required Optional
● Router, registered and configured for Cisco dCloud ● Cisco AnyConnect

● Laptop
● Cisco 8845 or 8865 Phone
● Cisco DX70 or DX80 running CE code
About This Solution

In the past, the deployment of end-to-end authentication and encryption in Cisco Collaboration has not been widespread. A
majority of customers chose to consider their internal networks as secure and the privacy of their communications as assured.
Over recent years, this mind set has begun to shift, and more customers have started to investigate 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. For
this reason, the Enterprise Preferred Architecture now includes end-to-end encryption and authentication.
© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 161
Cisco dCloud
With the above in mind, this lab describes the practical steps required to enable end-to-end certificate based authentication and
media encryption for both SIP signaling and RTP media across Cisco Unified Communications Manager, Cisco Unity Connection,
Cisco Meeting Server, Cisco Expressway, and Cisco video endpoints.
dCloud: The Cisco Demo Cloud
This lab is based on the Cisco Preferred Architecture for Enterprise Collaboration 11.6 as documented in the Cisco Validated
Design (CVD), available at http://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/116/collbcvd.html
This lab contains two scenarios. These are:
 Scenario 1: Cisco Unified Communications Manager and Endpoint Security
This scenario explores Unified Communication Manager (Unified CM) security and endpoint encryption. Participants will work
with Unified CM certificates including generating CSR, signing with Enterprise CA, and uploading certificates to the system.
Next, they will enable Certificate Authority Proxy Function (CAPF) and perform endpoint enrollment to install locally significant
certificates (LSCs) on hardware endpoints. Users will then move Unified CM from non-secure to mixed-mode using the
Tokenless method (CLI). Next, a Jabber for Windows client will be CAPF enrolled. Finally, the user will configure secure
phone profiles, apply to endpoints (hardware and software client), and then make encrypted calls to verify secure calling.
NOTE: This scenario is intended for users who have limited familiarity with Unified CM and endpoint security.
 Scenario 2: Cisco Collaboration Application Security
This scenario has Unified CM security pre-configured with encryption enabled. After the participant registers endpoints to the
Unified CM in secure mode, secure integration to Unity Connection with next generation encryption (NGE) is configured and
explored enabling encrypted media to endpoints. Next, users will issue certificates and set up security on Cisco Meeting
Server for encrypted video conferencing. Finally, the user will manage certificates, configure Expressway Mobile and Remote
Access (MRA), and verify end-to-end encryption for remote connected Jabber clients.
NOTE: This scenario is intended for users who have a good understanding of Unified CM and endpoint security and want
additional hands-on training for security with other Cisco Collaboration applications.
As each scenario takes approximately 2 hours to complete.
In summary, the two scenarios available in this lab are:
 Scenario 1: Deploy Unified CM enterprise-level encryption for internal collaboration hardware and software endpoints.
 Scenario 2: Enable and configure secure encrypted integrations to voicemail and video conferencing services for internal
collaboration endpoints as well as end-to-end MRA encryption for clients outside the enterprise perimeter.
Limitations
This lab does not have access to the public internet, so the Expressway MRA environment is simulated:
For Scenario 2, an enterprise CA signs the Expressway-E certificate. In production environments, best practice is to have the
Expressway-E certificate signed by a Public CA. In this lab, an Enterprise CA is used to simplify the lab rollout and maximize
session capacity. From a technical perspective, Jabber clients can utilize an Enterprise CA signed Expressway certificate, but
Cisco phones and video devices used in MRA mode require a supported public certificate.
Cisco dCloud
Topology
This content includes preconfigured users and components to illustrate the features of the solution. Most components are fully
configurable with predefined administrative accounts. You can see the IP address and credentials used to access a component by
clicking the component icon in the Topology menu of your active session and in the scenario steps that require their use.
Figure 1. dCloud Topology
Table 2. Server and Application Credentials and Details
Server Description Host Name (FQDN) IP Address Username Password

Active Directory,
Certificate Authority, Microsoft Windows Server 2008 R2 Standard ad1.dcloud.cisco.com 198.18.133.1 administrator C1sco12345
DNS
Unified CM (Scenario Cisco Unified Communications Manager

cucm1.dcloud.cisco.com 198.18.133.219 administrator dCloud123!
1) 11.5(1)SU2 – unsecure
Unified CM (Scenario Cisco Unified Communications Manager

ucm1.dcloud.cisco.com 198.18.133.3 administrator dCloud123!
2) 11.5(1)SU2 – secure
Unified CM IM & P IM & Presence 11.5(1)SU2 imp1.dcloud.cisco.com 198.18.133.4 administrator dCloud123!
Unity Connection Unity Connection 11.5(1)SU2 cuc1.dcloud.cisco.com 198.18.133.5 administrator dCloud123!
Expressway-C Expressway 8.9.1 exp-c-1.dcloud.cisco.com 198.18.133.152 admin dCloud123!
Cisco Meeting Server Cisco Meeting Server 2.1(3) cms1.dcloud.cisco.com 198.18.134.175 admin dCloud123!
Windows 7 Professional SP1 with Jabber

Workstation 3 wkst3.dcloud.cisco.com 198.18.133.38 mcheng C1sco12345
11.8
198.18.1.152 (Internal NIC)

Expressway-E Expressway 8.9.1 exp-e-1.dcloud.cisco.com admin dCloud123!
198.18.2.152 (External NIC)
DNS (external) Microsoft Windows Server 2008 R2 Standard ext-dns.dcloud.cisco.com 198.18.2.11 administrator C1sco12345
Windows 7 Professional SP1 with Jabber 198.18.133.39 (Internal NIC)

Workstation 1 wkst1.dcloud.cisco.com koneal C1sco12345
11.8 198.18.2.39 (External NIC)
Cisco dCloud
Session Users
The table below contains details on preconfigured users available for your session.
Table 3. User Details
User 4-digit Extension /

User Name User ID Endpoint Devices Phone DN User PIN
Password Self-Provisioning ID
ON-PREMISE / INSIDE
Charles Holland cholland C1sco12345 DX70 (or DX80) +1 408 555 6018 6018 1234
Anita Perez aperez C1sco12345 8845 (or 8865) +1 212 555 6017 6017 1234
Monic Cheng mcheng C1sco12345 CSFMCHENG (WKST3 – Jabber) +1 408 555 6030 6030 1234
EXTERNAL / OUTSIDE (may be moved ON-PREMISE / INSIDE)

Katelyn O’Neal koneal C1sco12345 CSFKONEAL (WKST1 – Jabber) +1 408 555 1074 1074 1234
Get Started
To connect to and work through this lab follow these steps
1. For best performance, from your laptop connect to the lab pod with Cisco AnyConnect VPN [Show Me How] and then use
the Remote Desktop Protocol (RDP) client on your laptop [Show Me How] to connect to appropriate lab workstations
 If you are running both Scenario 1 and Scenario 2, RDP to Workstation 3 (198.18.133.38, Username: DCLOUD\mcheng,
Password: C1sco12345) and perform all operations and configuration from there.
 If you are running Scenario 2 only, RDP to both Workstation 3 (198.18.133.38, Username: DCLOUD\mcheng, Password:
C1sco12345) and Workstation 1 (198.18.2.39 / 198.18.133.39, Username: DCLOUD\koneal, Password: C1sco12345).
NOTE: Remember when using RDP to connect to Windows Servers/Workstations in this lab, you must specify the domain
(DCLOUD\) when providing login credentials. For example, when connecting to Workstation 3 you should specify the
username as DCLOUD\mcheng.
2. Alternatively, connect your laptop to your dCloud router using an Ethernet cable and then use the Remote Desktop Protocol
(RDP) client on your laptop to connect to appropriate lab workstations as detailed in Step 1 above. Cisco AnyConnect is not
needed when connecting to your session through a dCloud router.
Cisco dCloud
Scenario 1: Cisco Unified Communications Manager and Endpoint

Security
Summary
In this scenario, we will configure and enable Unified CM Enterprise level encryption for on premise collaboration devices and
clients. The scenario is divided into the following 7 sections:
A. Collaboration Application Certificate Investigation and Tasks
B. Provisioning and Registering On-Premise Hardware Endpoints and Clients
C. Unified CM Certificate Authority Proxy Function (CAPF) Enrollment for Hardware Endpoints
D. Move Unified CM Cluster to Mixed-Mode via CLI (soft e-Token) Method
E. Unified CM CAPF Enrollment for Jabber Client
F. Create Secure SIP Phone Security Profile and Apply to On-Premise Endpoints
G. Confirm Secure Calling (Phone to Phone, Jabber to Phone)
The figure below shows the topology and relevant components for this scenario.
Figure 2. Scenario 1: Collaboration Security for the Enterprise Preferred Architecture Lab Topology
Cisco dCloud
Steps
NOTE: Scenario 1 uses the non-secure Unified CM, cucm1.dcloud.cisco.com (198.18.133.219). DO NOT USE
ucm1.dcloud.cisco.com (198.18.133.3) for this scenario.
A. Collaboration Application Certificate Investigation and Tasks
In this section, we examine collaboration application certificate best practices. This begins with a look at existing certificates on
Unified CM. Next, a Certificate Signing Request (CSR) is generated for Tomcat and CallManager certificates, signed by the
Enterprise CA, and the signed certificates are uploaded to Unified CM along with the CA root certificate to tomcat-trust and
CallManager-trust trust stores. Once our server certificates are signed by the Enterprise CA and the server trusts the CA root
certificate, we will configure security for connections to the Enterprise LDAP directory.
Examine the existing certificates on Unified CM (cucm1.dcoud.cisco.com)
Certificates play a critical role in collaboration security. Let us look at the various certificates on Unified CM.
1. RDP to Workstation 3 (198.18.133.38) with username DCLOUD\mcheng and password: C1sco12345.
2. Open Firefox and navigate to the Unified CM Operating System administrative interface:
https://cucm1.dcloud.cisco.com/cmplatform. Log in as administrator with Password: dCloud123!.
NOTE: The links on the default web page displayed in Firefox (https://ad1.dcloud.cisco.com/dcloud/default.html), do not apply for
this scenario and should not be used during this scenario. Instead, enter web URLs manually or copy and paste.
Cisco dCloud
3. Click Security > Certificate Management and then click Find. See the Unified CM OS Certificate Management interface and
a list of the system certificates.
Figure 3. Unified CM Certificate List dCloud: The Cisco Demo Cloud
The Enterprise PA best practice recommendation for relevant Cisco Unified CM certificates is to install certificate authority
(CA) signed certificates on the system rather than relying on the default self-signed certificates. A public CA or private
enterprise CA should sign the following certificates:
 tomcat
 CallManager
Cisco dCloud
Generate a certificate signing request (CSR) for tomcat
4. At the same Security > Certificate Management page, search for certificates that begin with ‘tomcat’, as shown in the
following Figure. The tomcat certificate is self-signed, but per best practice recommendations it needs dCloud:
to be signed byDemo
The Cisco our Cloud
enterprise CA (dCloud-AD1-CA).
Figure 4. Unified CM Tomcat / Tomcat-trust self-signed certificates
5. Click Generate CSR. In the subsequent window, ensure tomcat is selected in the “Certificate Purpose” drop down menu.
Leave all other values as the defaults, including length and hash algorithms set to 2048 and SHA256 as shown below.
Figure 5. Generate Tomcat CSR
Cisco dCloud
6. Click Generate. Once the CSR is created, click Close. You should now see the tomcat CSR you just generated when the
certificate list reloads.
Figure 6. Tomcat CSR dCloud: The Cisco Demo Cloud
NOTE: You may need to click Find to reload the certificate list.
NOTE: Unified CM supports multi-server SAN certificates, which are recommended for multi-node clusters of Unified CM and
Unified CM IM & P. Multi-server SAN certificates allow us to streamline the certificate signing process. With mutli-server
certificates, both Unified CM and Unified CM IM & P cluster nodes use the same CA signed certificate for tomcat connections.
Likewise, all Unified CM nodes running the CallManager service can use the same CA signed certificate for CallManager
connections. Mutli-server SAN certificates are also recommended for the xmpp and xmpp-s2s certificates for multi-node
Unified CM IM&P clusters as well as tomcat certificates for multi-node Unity Connection deployments.
This scenario relies on a single node Unified CM cluster with no Unified CM IM&P or Unity Connection nodes, for this reason,
multi-server SAN certificates are not an option.
If you would like to see a multi-server SAN certificate or examine a multi-server SAN CSR, you can look at the secure Unified
CM cluster (used for Scenario 2) in your session. This secure Unified CM cluster includes a Unified CM IM & P node. To
explore the multi-server SAN certificate move to Scenario 2, (Collaboration Application Security) and navigate to Step 4 in
Section B (Unified CM and Unified CM IM & P Certificate Investigation). When complete, return to this point to continue.
Choosing to view the certificate in Scenario 2 early will not change the outcome for Scenario 1.
Cisco dCloud
Generate a CallManager CSR
7. On the Certificate List page at Security > Certificate Management, search for certificates that begin with ‘CallManager’, as
shown below. dCloud: The Cisco Demo Cloud
Figure 7. Unified CM CallManager / CallManager-trust self-signed certificates
8. Notice the CallManager certificate is self-signed. Signing the CallManager certificate with a public or private CA is a best
practice, so we want to get this certificate signed by our enterprise CA.
Cisco dCloud
9. Click Generate CSR. This time, choose CallManager in the “Certificate Purpose” drop down. Leave all other values as
defaults ensuring that the key length and hash algorithms are set to 2048 and SHA256 respectively as shown below.

NOTE: Multi-server SAN is not available in the Distribution field because there is only one node in our Unified CM cluster. With
a multiple node Unified CM cluster, you would have the option of generating a Multi-server SAN CSR.
Figure 8. Generate CallManager CSR
10. Click Generate. Once the CSR is created, click Close. The list reloads and you see the CallManager CSR you just generated.
Figure 9. CallManager CSR
Cisco dCloud
Downloading the tomcat CSR
11. Click Download CSR and in the Download Certificate Signing Request window, ensure tomcat is selected in the “Certificate
Purpose” drop down. dCloud: The Cisco Demo Cloud
Figure 10. Download CSR
12. Click Download CSR in the Download Certificate Signing Request window. In the Open with / Save File dialog, choose Open
with, click Browse, and then choose Microsoft Wordpad Application (or Notepad) and click OK.
Figure 11. Downloading and Opening the tomcat CSR
Cisco dCloud
13. Click OK to open the CSR with Wordpad (or Notepad). Once the file opens, select the contents of the file and copy to the
clipboard (Ctrl-C).
Figure 12. Copying the CSR Text dCloud: The Cisco Demo Cloud
NOTE: The certificate request string shown above may be different in your CSR.
14. Close the Download CSR window before proceeding.
Issue and sign tomcat certificate using Enterprise Microsoft Certificate Authority (CA) (ad1.dcloud.cisco.com)
15. Use the Firefox web browser on Workstation 3 (198.18.133.38) to navigate to http://ad1.dcloud.cisco.com/certsrv. Log in as
administrator with Password: C1sco12345 when prompted to authenticate.
Cisco dCloud
16. Click on Request a certificate.
Figure 13. Request a Signed Certificate from the Enterprise CA

17. On the next screen, click “Or, submit an advanced certificate request.”
Figure 14. Enterprise CA Advanced Certificate Request
Cisco dCloud
18. Paste (Ctrl-V) the contents of the clipboard (copied from the CSR in the previous step) to the Base-64-encoded certificate
request field. Choose the ClientServer Certificate Template and click on Submit > as shown below.
Figure 15. Submit Certificate Request dCloud: The Cisco Demo Cloud
Cisco dCloud
19. On the next screen, click the radio button for DER encoded (default) or Base 64 encoded and then Download Certificate.
Figure 16. Save the Signed tomcat Certificate

20. Click the radio button for Save File and click OK to save to the local workstation. Name the file tomcat.cer.
Downloading the CallManager CSR
21. Click Download CSR and in the Download Certificate Signing Request window, ensure CallManger is selected in the
“Certificate Purpose” drop down.
Figure 17. Download CSR
Cisco dCloud
22. Click Download CSR in the Download Certificate Signing Request window. In the Open with / Save File dialog, choose Open
with, click Browse, and then choose Microsoft Wordpad Application (or Notepad) and click OK.
Figure 18. Downloading and Opening the tomcat CSR dCloud: The Cisco Demo Cloud
23. Click OK to open the CSR with Wordpad (or Notepad). Once the file opens, select the contents of the file and copy to the
clipboard (Ctrl-C).
Figure 19. Copying the CSR Text
Cisco dCloud
24. Close the Download CSR window before proceeding.

Issue and sign CallManager certificate using Enterprise Microsoft Certificate Authority (CA) (ad1.dcloud.cisco.com)
25. Use the Firefox web browser on Workstation 3 (198.18.133.38) to navigate to http://ad1.dcloud.cisco.com/certsrv. Log in as
administrator with Password: C1sco12345 when prompted to authenticate.
26. Click on Request a certificate.
27. On the next screen, click “Or, submit an advanced certificate request.”
Figure 21. Enterprise CA Advanced Certificate Request
Cisco dCloud
28. Paste (Ctrl-V) the contents of the clipboard (copied from the CSR in the previous step) to the Base-64-encoded certificate
request field. Choose the ClientServer Certificate Template and click on Submit > as shown below.
Figure 22. Submit Certificate Request dCloud: The Cisco Demo Cloud
29. On the next screen, click the radio button for DER encoded (default) or Base 64 encoded and then Download Certificate.
Figure 23. Save the Signed tomcat Certificate
Cisco dCloud
30. Click the radio button for Save File and click OK to save to the local workstation. Name the file CallManager.cer.
31. Close all Wordpad application windows on Workstation 3 before proceeding.

Download the Enterprise Root Certificate
32. Before leaving the Enterprise Certificate Authority, return to https://ad1.dcloud.cisco.com/certsrv/. You can navigate there
quickly by clicking the Home link in the upper right-hand corner. Click the link Download a CA certificate, certificate chain,
or CRL.
Figure 24. Download the Enterprise CA Root Certificate (1 of 2)
33. On the next screen, Current [dcloud-AD1-CA] is selected by default. Click Download CA Certificate.
34. Click Save File and click OK to save to the local workstation. Name the file dCloud_root.cer.
Cisco dCloud
Upload Enterprise CA root and signed tomcat and CallManager certificates to Unified CM
Now that the tomcat and CallManager certificates are issued and signed, these certificates and the CA root certificate must be
uploaded to Unified CM. dCloud: The Cisco Demo Cloud
35. Return to the Unified CM administrative interface at https://cucm1.dcloud.cisco.com/cmplatform/.
36. Log in (if required) as administrator with password: dCloud123!.
37. Click Security > Certificate Management and then click Upload Certificate/Certificate chain.
Figure 26. Upload CA-signed tomcat and CallManager Certificates and CA Root Certificate
38. We will start by uploading the Enterprise CA root certificate to the trust stores: tomcat-trust and CallManager-trust. Choose
tomcat-trust from the Certificate Purpose dropdown and enter dCloud-AD1-CA for the Description field.
39. Click browse and choose the certificate you saved previously: dCloud_root.cer. It is located at C:\Users\mcheng\Downloads.
40. Click Open and then click Upload.
Figure 27. Upload the CA Root Certificate to tomcat-trust
NOTE: You can wait to restart the Cisco Tomcat, CallManager, and TFTP services until the end of this section.
Cisco dCloud
41. Once the CA root certificate is uploaded to the tomcat-trust store, repeat the above steps and upload the CA root certificate to
the CallManager-trust store. This this by choosing CallManager-trust from the “Certificate Purpose” drop down.
42. Next, upload the CA-signed tomcat and CallManager certificates. This time choose tomcat from the “Certificate Purpose”
dCloud: The Cisco Demo drop
Cloud
down.
43. Click Browse and choose the certificate saved previously – tomcat.cer, located at C:\Users\mcheng\Downloads. Click Open
and then Upload.
Figure 28. Upload the CA-Signed tomcat Certificate
NOTE: You can wait to restart the Cisco Tomcat, Cisco CallManager, and Cisco TFTP services until the end of this section.
44. Repeat the above process to upload the CallManager certificate, but this time choose CallManager from the Certificate
Purpose drop down and choose CallManager.cer as the upload file.
Cisco dCloud
45. Click Close and then on the Certificate List page at Security > Certificate Management, search for certificates where ‘begins
with’ is blank, then click Find. Note that the CA-signed tomcat and CallManager certificates we just signed are listed along
with the enterprise CA root certificate in the tomcat-trust and CallManager-trust stores.
Figure 29. CallManager and tomcat CA-Signed Certificates and CA Root Certificate Uploaded to CallManager-trust and tomcat-trust
Before moving to the next section, we need to restart Cisco TFTP, Cisco CallManager, and Cisco Tomcat services since we have
uploaded new CA-signed certificates and a new root certificate.
46. Browse to the Unified CM Serviceability portal at https://cucm1.dcloud.cisco.com/ccmservice/) and log in as administrator
with password: dCloud123!.
47. Go to Tools > Control Center – Feature Services, click the Cisco TFTP radio button and click Restart. Click OK to confirm.
48. After the TFTP service restarts and you see the message “Cisco Tftp Service Restart Operation was Successful”, click the
Cisco CallManager radio button and click Restart again You will click OK to confirm restart.
NOTE: For the purposes of this lab, we do not need to restart the CTIManager service; however, normally you would also
have to restart it.
NOTE: Your phones will reset during the CallManager service restart.
Cisco dCloud
To restart the Cisco Tomcat service, you need to SSH to Unified CM (cucm1.dcloud.cisco.com) command line interface by using
Putty on Workstation 3 (198.18.133.38).
49. Double-click the PuTTY icon to launch. Enter cucm1.dcloud.cisco.com in the “Host Name (or IP Address)” field.
Click Open.
50. Click Yes to cache the ssh-rsa2 key.
Figure 30. Key Cache Confirmation for SSH to Unified CM
51. After logging in with username/password: administrator / dCloud123!, enter the command utils service restart Cisco
Tomcat at the command line. The Cisco Tomcat service will restart. Once the service has started again, type exit to close the
SSH session to Unified CM.
Figure 31. Restarting the Cisco Tomcat Service on Unified CM
NOTE: It taked a few minutes for the Cisco Tomcat service to restart and the web administration interfaces to return to service.
Cisco dCloud
The next time you navigate to one of the Unified CM web administration interfaces you will see a certificate warning since the
tomcat certificate has been regenerated and signed. Although our enterprise CA root certificate has already been imported to the
local certificate trust stores of all our Windows Workstations, the browser does not have the enterprise CA root certificate in its trust
store. You need to add the certificate to the Firefox browser’s trust store.
52. Bypass the certificate warning by clicking ‘I Understand the Risks’. Click the Add Exception… button and then click Confirm
Security Exception as shown below.
Figure 32. Unified CM: Bypass Firefox Browser Certificate Warning by Confirming a Security Exception
53. Log in as administrator with password: dCloud123!.
Configure Secure Connection between Unified CM and the Enterprise LDAP Directory
The certificates are signed and uploaded to the appropriate trust stores. Now, let us secure the connection between Unified CM
and the enterprise LDAP directory so that traffic between Unified CM and the Active Directory (ad1.dcloud.cisco.com) is encrypted
using TLS.
54. Browse to the Unified CM Administration portal (https://cucm1.dcloud.cisco.com/ccmadmin/) and login as administrator with
password: dCloud123!.
Cisco dCloud
55. Navigate to System > LDAP > LDAP Directory and click the Find button to access the LDAP directory list.
56. Click on ad1 (LDAP Configuration Name) to bring up the configuration page.
57. Scroll to the bottom of the page and check the ‘Use TLS’ checkbox and change the ‘LDAP Port’ field from the default 389 to
636 as shown below.
Figure 33. Securing the LDAP Directory Connection with TLS
58. Click Save and then Perform Full Sync Now. Click OK to acknowledge the LDAP sync warning and initiate the sync.
Unified CM is now communicating securely with the LDAP directory (ad1.dcloud.cisco.com / 198.18.133.1) and is able to validate
the certificate from Active Directory because it has been signed by the Enterprise CA (dcloud-AD1-CA) and is loaded to the
tomcat-trust trust store.
59. Next, configure the secure LDAP authentication with TLS by navigating to System > LDAP > LDAP Authentication.
Cisco dCloud
60. Check the ‘Use TLS’ checkbox and change the ‘LDAP Port’ field from the default 389 to 636 as shown below then click Save.
Figure 34. Securing Authentication Connections between Unified CM LDAP Directory with TLS
Now, when end users authenticate against the LDAP server, the authentication traffic is encrypted between Unified CM and the
LDAP directory.
B. Provisioning and Registering On-Premise Desk Phones and Clients
In this section, you will provision IP phones using the Self-Provisioning Interactive Voice Response (IVR). Once provisioned, these
phones should re-register to Unified CM as user-specific devices. After this, you will launch and log in into the Jabber client on
Workstation 3 (198.18.133.38).
Use the Self-Provisioning (IVR) to provision the phones for users Anita Perez and Charles Holland.
1. Before proceeding, verify both desk phones have re-connected with Unified CM (cucm1.dcloud.cisco.com) after the service
restart in the previous section.
Cisco dCloud
2. The 88x5 and DX devices (see Figures below) should be auto-registered with a 4-digit line number (130x) and the Self-
Provisioning IVR speed dial (1111).
Figure 35. Auto-Registered 88x5 Desk Phone dCloud: The Cisco Demo Cloud
Figure 36. Auto-registered DX Video Endpoint
NOTE: The phone screens above are examples; your phone screens may look slightly different.
3. Self-provision the 88x5 and DX as indicated in Table 3 below.
Table 3. Self-Provisioning User ID, PIN and Device
4-digit Extension /
User Name User ID Endpoint Device Phone User PIN
Self-Provisioning ID
Anita Perez aperez 88x5 +1 212 555 6017 6017 1234
Charles Holland cholland DX70/80 +1 408 555 6018 6018 1234
NOTE: When self-provisioning the endpoints in the follow steps, ensure you provision the appropriate endpoint device for
each user as shown in Table 3 above.
Cisco dCloud
4. To self-provision the 88x5, press the speed dial to call the Self-Provisioning IVR number (1111). Once the IVR answers, follow
the audio prompts (as shown below) to provision the endpoint:
a) Enter the user’s Self Provisioning ID followed by the ‘#’ key dCloud: The Cisco Demo Cloud
b) Confirm the user’s Self Provisioning ID by pressing the ‘#’ key
c) Enter the user’s PIN number followed by the ‘#’ key.
After the PIN is entered, the 88x5 phone reboots. When the phone returns to service it will be provisioned for the user.
5. Repeat the steps above to self-provision the DX, noting you must manually dial the Self-Provisioning IVR number 1111, as
there is no speed dial assigned. To enter digits for the IVR on the DX, you must touch the Keypad icon to bring up the Keypad.
6. The following figures show the 88x5 phone after self-provisioning for Anita Perez and the DX device for Charles Holland.
Figure 37. 88x5 Desk Phone Self-Provisioned for Anita Perez
Figure 38. DX Video Endpoint Self-Provisioned for Charles Holland
NOTE: The phone screens above are examples; your phone screen may look slightly different
Cisco dCloud
Launch Jabber on Workstation 3 (198.18.133.38) and log in as user Monica Cheng.
7. If you are not connected to Workstation 3 (198.18.133.38), RDP to the system as DCLOUD\mcheng with password:
C1sco12345. dCloud: The Cisco Demo Cloud
8. Once connected launch the Cisco Jabber for Windows client by double-clicking the desktop icon. The Unified CM cluster is
already configured for Jabber service discovery with the appropriate UC services defined and service profile in place.
Likewise, a Unified Client Service Framework (CSF) or Jabber for Windows device is pre-configured on Unified CM for user
Monica Cheng (CSFMCHENG).
NOTE: Please be patient. It may take as long as a minute for the Jabber client to launch the first time.
When Jabber launches it will automatically discover the available services and prompt for user information connect and register.
9. Log in to the Jabber client by entering the password: C1sco12345 and clicking Sign In. Note that the username field is
already pre-populated with our Workstation 3 user’s login username: mcheng.
Figure 39. WKST3 Jabber for Windows Login
As shown above, the Jabber client will automatically log in and connect to Unified CM and Active Directory (LDAP) servers for
voice/video over IP calling and directory services.
NOTE: The Jabber client is able to validate the Unified CM tomcat certificate without warning or prompting the user to accept the
certificate because the root certificate of the Enterprise CA (dcloud-AD1-CA) has already been uploaded to the Windows
Workstation’s local certificate trust store. The Enterprise CA signed the Unified CM CallManager certificate, so Jabber is able to
automatically validate the certificate because the root certificate is in the local trust store.
Cisco dCloud
10. Confirm the connection by clicking Settings ( ) > Help > Show connection status.
Figure 40. Workstation 3 Jabber for Windows for Monica Cheng (mcheng) with Connection Status
11. Before preceding further, please shutdown the Jabber for Windows client (select Settings ( ) > Exit) in preparation for
tasks later in this lab.
Cisco dCloud
C. Unified CM Certificate Authority Proxy Function (CAPF) Enrollment for Hardware Endpoints
In preparation for enabling secure calling with encrypted media and signaling we will first use the Certificate Authority Proxy
Function (CAPF) to enroll the desk phones. This process generates and installs LSC certificates on the phones. We will begin by
activating and starting the CAPF service and then setting the phones for CAPF enrollment. Finally, we will confirm CAPF
enrollment is successful for the hardware endpoints.
Activate and Start CAPF
1. To activate and start CAPF, browse to the Unified CM Serviceability portal (https://cucm1.dcloud.cisco.com/ccmservice/) from
the Firefox web browser on Workstation 3 and log in (if required) as administrator with password: dCloud123!.
2. Navigate to Tools > Service Activation and scroll down to the Security Services section and check the box next to Cisco
Certificate Authority Proxy Function as shown below and then click Save to activate and start the CAPF service.
3. Click OK when prompted to proceed.
Figure 41. Activating Cisco Certificate Authority Proxy Function (CAPF)
4. When you see the message “Update Operation Successful”, confirm the service has started by navigating to Tools > Control
Center – Feature Services and ensure the Cisco Certificate Authority Proxy Function service has a status of Started and
the Activation Status is Activated.
Figure 42. Certificate Authority Proxy Function (CAPF) Service Activated and Started
5. After confirming that Cisco Certificate Authority Proxy Function service has started, you will need to restart the TFTP.
Restart the TFTP service by clicking the Cisco TFTP radio button on the same page as above (Tools > Control Center –
Feature Services) and click Restart. Click OK to confirm restart.
NOTE: After restarting the TFTP service, the CAPF certificate is added to the ITL file. The endpoints do not automatically
download the new ITL file. In the next step, when we configure the devices for CAPF enrollment and apply the new configuration,
the phones will restart and download the new ITL file.
Proceed to the next step while the TFTP service is restarting.
Cisco dCloud
Configure Hardware Endpoints (88x5 and DX) for CAPF Enrollment via MIC Authentication (88x5) and Authentication String (DX)
and Confirm LSC Install Indicating Successful CAPF Enrollment
Hardware endpoints and clients must have a certificate to enable secure encrypted calling. You can use the factory
dCloud: Theinstalled
Cisco Demo Cloud
manufacturing certificate (MIC) (if available) for authentication and encryption, but this is not recommended.
MICs pose a security risk given that a common Certificate Authority (CA) is used across all manufactured Cisco phones. Further,
MICs are only valid for 10 years from manufacturing date and cannot be renewed, customized, updated, revoked, or deleted.
Finally, Cisco software clients and some Cisco hardware endpoints do not have/expose a MIC, such as a DX running CE.
For these reasons, Cisco’s best practice is to rely on a locally significant certificate (LSC). To install LSCs on the endpoints, you
need to perform CAPF enrollment for the devices. Since the CAPF service was started in the previous step, you can proceed to
CAPF enrollment.
First, verify that the desk phones do not already have LSCs by looking at the security settings information on the phone:
6. On the 88x5, press (Settings) > Admin settings > Security setup. Note that LSC is “Not installed” as shown below.
Figure 43. 88x5 Security Setup Information
On the DX, validate it is non-secure and does not have an LSC by navigating to the web interface of the DX endpoint. Before we
do this, we need to enable the web interface on the device configuration page.
7. From the Firefox web browser on Workstation 3 (198.18.133.38), log in to the Unified CM Administration interface
(https://cucm1.dcloud.cisco.com/ccmadmin/) (if required) as administrator with password: dCloud123!.
8. Navigate to Device > Phone and click Find to load the device list. Note the IP address of this device as you will need it to
access the device web interface.
Cisco dCloud
9. Click the DX endpoint and on the subsequent configuration page under the Product Specific Configuration Layout section,
choose HTTP+HTTPS from the “Web Access” dropdown.
Figure 44. Enabling Web Access for the DX Video Endpoint dCloud: The Cisco Demo Cloud
10. Click . Click OK on the next dialog and then click . Click OK again to apply the configuration changes.
11. Next, open Firefox on Workstation 3 and navigate to the DX endpoint web interface using the endpoint IP address
http://<Endpoint_IP_Address>/. When prompted, log in with the default username admin and password <blank>.
12. Tap Setup > Status > Provisioning and note that there is no LSC installed as shown below.
Figure 45. DX Security Setup Information
NOTE: The IP address of the endpoint (as well as the endpoint model) may be different than shown above.
Cisco dCloud
Now that you have confirmed that the hardware endpoints do not have LSCs installed, begin the enrollment process.
13. From the Firefox web browser on Workstation 3 (198.18.133.38), log in to the Unified CM Administration interface
(https://cucm1.dcloud.cisco.com/ccmadmin/) as administrator with password: dCloud123!. dCloud: The Cisco Demo Cloud
14. Navigate to Device > Phone. Locate the two desk phones by searching for devices that “begin with” SEP – see Figure below.
Figure 46. Finding Desk Phones for CAPF Enrollment
NOTE: The device Name/MAC addresses of the endpoint (as well as the endpoint model) may be different than shown above.
15. Click the 88x5 device and on the configuration page, under the Certification Authority Proxy Function (CAPF) Information
section, choose Install/Upgrade from the “Certificate Operation” dropdown. Specify some date in the future for the “Operation
Completes By” sub-fields. See the Figure below for the final settings for CAPF enrollment for the 88x5.
Figure 47. CAPF Enrollment Settings for the 88x5 Endpoint
NOTE: Depending on the date of the session, the default Operation Completes By and configured values may be different from
those shown above.
Because the SelfProv Universal Device Template – MIC Device Security Profile was applied to the device during self-
provisioning, the Authentication Mode, Key Order, and RSA Key Size settings are set to appropriate values automatically. In this
case, “Authentication Mode” is set to By Existing Certificate (precedence to LSC), “Key Order” is set to RSA Only, and “RSA
Key Size” is set to 2048.
Cisco dCloud
16. Click . Click OK and then click . Click OK on the resulting dialog to apply the configuration
changes. The 88x5 desk phone will restart and re-register after the CAPF enrollment is complete.
NOTE: Using By Existing Certificate (precedence to LSC) as the CAPF “Authentication Mode” for endpoint CAPF enrollment is
preferred because it generally applies to the largest number of devices. With this setting, if an endpoint has only a MIC certificate,
this certificate will be used for authentication to CAPF. If the endpoint has an LSC certificate (whether or not the endpoint also has
a MIC), then the LSC certificate is used instead for authentication to CAPF. This is a good general setting for most hardware
endpoints for both the initial enrollment and subsequent CAPF operations, such as upgrade or delete.
For those endpoints that do not support having a MIC (such as, the DX running CE firmware and Cisco Jabber desktop and mobile
clients), we must authenticate the CAPF server during our initial CAPF enrollment using either the By Authentication String or By
Null String (no authentication) modes. After initial enrollment, By Existing Certificate (precedence to LSC) authentication mode
may be used for all subsequent CAPF operations.
Next, you will CAPF enroll the DX with similar settings. However, since DX endpoints running CE code do not expose the MIC, you
will use CAPF Authentication Mode for DX enrollment using an authentication string.
17. Navigate to Device > Phone and click your DX device. On the configuration page, under the Certification Authority Proxy
Function (CAPF) Information section, choose Install/Upgrade from the “Certificate Operation” dropdown. Enter 12345 in the
“Authentication String” field, and specify some date in the future for the “Operation Completes By” sub-fields.
Figure 48. CAPF Enrollment Settings for the DX Endpoint
NOTE: Depending on the date of this session, the default Operation Completes By and configured values may be different from
those shown above.
NOTE: As shown above, the SelfProv Universal Device Template – AuthString Device Security Profile was applied to the
device during self-provisioning, so the Authentication Mode, Key Order and RSA Key Size settings are set to appropriate values
automatically. In this case, “Authentication Mode” is set to By Authentication String, “Key Order” is set to RSA Only, and “RSA
Key Size” is set to 2048.
Cisco dCloud
18. Click . Click OK and then click . Click OK on the next dialog to apply the configuration changes.
19. The DX endpoint will display a Cisco UCM Authentication dialog on screen. Enter the Authentication String
dCloud:12345 in the
The Cisco DemoPIN
Cloud
code field as shown below. Touch OK and the DX will complete CAPF enrollment and re-register to Unified CM.
Figure 49. DX Endpoint Authentication String PIN Code Entry
NOTE: You may ignore the reference to the “10 digit PIN code required by Cisco UCM” as this is a cosmetic issue. The 5-digit PIN
(12345) will work fine.
Once both phones have completed CAPF enrollment and re-registered to Unified CM, you should verify that CAPF enrollment was
successful and that the hardware endpoints now have LSCs installed.
Cisco dCloud
Verify that the endpoints have successfully enrolled with CAPF and received an LSC by looking at the security settings information
on the endpoints:
20. On the 88x5, press (Settings) > Admin settings > Security setup. Note that LSC is now “Installed” as shown below.
Figure 50. 88x5 LSC Installed
21. On the DX, navigate to the DX endpoint web interface using the endpoint IP address http://<Endpoint_IP_Address>/. When
prompted, log in as the default username admin with password <blank>. Once logged in, navigate to Setup > Status >
Provisioning and note that an LSC has been installed on the endpoint.
Figure 51. DX LSC Installed
Cisco dCloud
22. You can also view the 88x5 phone status log to confirm that the LSC was updated/installed by pressing: (Settings) >
Admin settings > Status > Status messages.
Figure 52. 88x5 Phone Status Messages
NOTE: The MAC address and status message sequence on your phone may be different than shown above.
An easy way to monitor the status of CAPF enrollments for multiple endpoints is to search for endpoints based on the status or
issuer of the LSC (if present).
23. On Unified CM (https://cucm1.dcloud.cisco.com/ccmadmin/), navigate to Devices > Phone, do a search where ‘Device Name’
‘begins with’ SEP and ‘LSC Issued By’ ‘begins with’ is blank. Click Find to search for the LSC issuer of hardware endpoints on
the system. The resulting hardware endpoints show an LSC Status of Upgrade Success.
Figure 53. Unified CM Device Search Based Device Name and LSC Issuer
NOTE: The device names/MAC addresses may be different from the ones shown above.
You can also confirm the CAPF operation was successful by returning to the phone configuration page on the Unified CM
Administration interface (Devices > Phone). After choosing one of the phones, scroll down to the Certification Authority Proxy
Function (CAPF) Information section and confirm that the CAPF Operation Status is “Upgrade Success”:
Cisco dCloud
NOTE: Because the 88x5 and DX endpoints support the Initial Trust List (ITL), CAPF enrollment can be done while the Unified CM
cluster is in non-secure mode. On the other hand, Jabber clients DO NOT support the ITL and during CAPF enrollment cannot
verify the identity of the CAPF server. In order to CAPF enroll the on-premise Jabber client, the client requires a Certificate
dCloud: Trust
The Cisco Demo Cloud
List (CTL) which will not be available until you move the Unified CM cluster in mixed-mode in the next section.
D. Move Unified CM Cluster to Mixed-Mode via CLI (soft e-Token) Method
In this section, you move the Unified CM cluster from non-secure to mixed-mode, a prerequisite for enabling encrypted calling. You
will use the Unified CM CLI soft e-Token method (also referred to as Tokenless) to move the cluster to mixed-mode. After moving
to mixed-mode, you will confirm the operation and ensure that the desk phones download the new Certificate Trust List (CTL) file.
Move the Unified CM cluster to mixed-mode using the system CLI
1. SSH to the Unified CM (cucm1.dcloud.cisco.com) command line interface by using Putty on Workstation 3 (198.18.133.38).
2. Double-click the PuTTY icon to launch.
3. Enter cucm1.dcloud.cisco.com in the “Host Name (or IP Address)” field. Click Open.
5. At the command line prompt, verify there is no CTL file with the command show ctl. This confirms that the Unified CM cluster
is in non-secure mode. A CTL file would be present if the cluster was in mixed-mode.
Figure 54. Unified CM CLI – Show CTL on Non-Secure Cluster
6. Enter the utils ctl set-cluster mixed-mode command on the CLI and press enter to move the cluster to mixed-mode. Confirm
that you want to continue by typing ‘y’ and pressing enter.
NOTE: If the console becomes unresponsive, you may need to press Ctrl-C to cancel the command and re-enter the
command again.
Figure 55. Unified CM CLI – Utils CTL Set-Cluster Mixed-Mode
Cisco dCloud
7. Re-run the show ctl command to confirm the CTL file is now present.
Figure 56. Unified CM CLI – Show CTL on Mixed-Mode Cluster

NOTE: The checksum, serial numbers, and other values of the CTL file on your system may be different from the ones shown
above.
8. Enter exit command on the CLI to clear the SSH session and close the Putty client.
Verify cluster has moved to mixed-mode and that the desk phones have downloaded the new CTL.
9. Return to the Firefox web browser on Workstation 3 (198.18.133.38) and browse to the Unified CM Administration interface at
https://cucm1.dcloud.cisco.com/ccmadmin.
11. Navigate to System > Enterprise Parameters, scroll down to the Security Parameters area and verify whether the cluster
was set to mixed-mode. A value of 1 indicates mixed-mode.
Figure 57. Unified CM Cluster Security Mode
12. Next, restart TFTP and CallManager services. Browse to the Unified CM Serviceability portal at
https://cucm1.dcloud.cisco.com/ccmservice/ and log in as administrator with password: dCloud123!.
Cisco dCloud
13. Go to Tools > Control Center – Feature Services, click the Cisco TFTP radio button and click Restart. Click OK to confirm.
14. After the TFTP service restarts and you see the message “Cisco Tftp Service Restart Operation was Successful”, click the
Cisco CallManager radio button and click Restart. Click OK to confirm restart. dCloud: The Cisco Demo Cloud
NOTE: In the Enterprise PA, the TFTP and CallManager services are not activated on the publisher. Best practice
recommendation is to have dedicated redundant TFTP service nodes and to run CallManager services on dedicated Subscriber
nodes. In this lab, we have a single node Unified CM cluster so all required services are running on the Publisher node including
TFTP and CallManager. CTIManager is not enabled on the Publisher in the PA, but in this case, it is enabled on the Publisher
because we are using Self-Provisioning IVR, which requires CTIManager service to run on a node of the cluster.
When the CallManager restarts, the desk phones will reset and re-register after they download the new CTL.
Next, confirm that both phones now have a CTL file by viewing the phone status logs.
15. On the 88x5, press (Settings) > Admin settings > Status > Status messages. You should see the output below:
Figure 58. 88x5 Status Message – CTL Installed
NOTE: The MAC address and status message sequence on your phone may be different than shown above. Also, you may need
to scroll down in the status messages window to see the “CTL and ITL installed” message.
16. You can also view the CTL file on the 88x5 endpoint by navigating to (Settings) > Admin settings > Security > Trust
List > CTL and examining the CTL file as shown in the figure below:
Figure 59. 88x5 CTL Trust List
NOTE: The CTL signature and CAPF server name shown above may be different on your phone.
Cisco dCloud
17. On the DX, navigate to the endpoint web interface using the endpoint IP address http://<Endpoint_IP_Address>/. If prompted,
log in as the default username admin with password: <blank>.
18. Navigate to Setup > Security > CUCM Certificates and note that as shown below the CTL is installeddCloud:
on the endpoint.
Figure 60. DX: CUCM Certificates – CTL Installed
NOTE: The fingerprint, serial numbers, and other values of the CTL file on your DX may be different from the ones shown above.
Cisco dCloud
19. As shown in the figure below, you can also review CTL information and file contents on the page at Setup > Security >
CUCM Certificates.
Figure 61. DX – CTL File Content dCloud: The Cisco Demo Cloud
NOTE: The fingerprint, serial numbers, and other values of the CTL file on your DX may be different from the ones shown above.
Cisco dCloud
E. Unified CM CAPF Enrollment for Jabber Client
With Unified CM now in mixed-mode, a Certificate Trust List (CTL) is available which allows CAPF to enroll the on-premise Jabber
client (Workstation 3 – CSFMCHENG). After CAPF enrollment is complete, confirm that the operation was successful.
Configure On-premise Jabber Client (CSFMCHENG) for CAPF Enrollment and Confirm Enrollment via Authentication String.
NOTE: Before proceeding, ensure that Jabber for Windows (CSFMCHENG) on Workstation 3 (198.18.133.38) is not running.
1. From the Unified CM Administration interface at https://cucm1.dcloud.cisco.com/ccmadmin/, navigate to Device > Phone and
click Monica Cheng’s CSF device: CSFMCHENG.
NOTE: You may need to clear previous search filters in order to get the Jabber (CSF) devices to display.
2. On the configuration page, choose SelfProv Universal Device Template – AuthString from the “Device Security Profile”
dropdown under the Protocol Specific Information section to automatically configure the Authentication Mode, Key Order and
RSA Key Size settings under the Certification Authority Proxy Function (CAPF) Information section. “Authentication Mode” is
set to By Authentication String, “Key Order” is set to RSA Only, and “RSA Key Size” is set to 2048.
3. Next, choose Install/Upgrade from the “Certificate Operation” dropdown, enter 12345 in the “Authentication String” field, and
specify a date in the future for the “Operation Completes By” sub-fields. The Figure below shows the final settings for CAPF
enrollment for the Jabber client (CSF).
Figure 62. Configuring CAPF Enrollment with Authorization String for On-Premise Jabber for Windows Client (Workstation 3)
NOTE: The default Operation Completes By and configured values may be different from those shown above.
Cisco dCloud
4. Click . Click OK on the next dialog and then click to enable the CAPF enrollment for the on-premise
Jabber client. Click OK to apply the configuration changes.
5. On Workstation 3 (198.18.133.38), start Jabber and log in as mcheng with password: C1sco12345. You should see a pop-up
window that prompts for the authorization string. Enter the authorization string specified previously: 12345. Click OK.
6. The Jabber IP phone service will not connect until after the user has entered the authentication string and the CAPF
enrollment operation has completed.
Figure 63. CAPF Enrollment with Authentication String – Jabber for Windows
7. Verify that the Jabber client registers correctly. You should see the icon . Alternatively, under the Connection status
at Settings ( ) Help > Show Connection Status, the Softphone status should show connected.
As before, you can also confirm that the CAPF enrollment for the on-premise Jabber client was successful by searching for
endpoints based on the LSC issuer.
8. Navigate to Unified CM Administration interface at https://cucm1.dcloud.cisco.com/ccmadmin/ and go to Devices > Phone,

then choose LSC Issued By from the “Find phone where” dropdown menu.
Cisco dCloud
9. Click Find to search for the LSC issuer of all endpoints certificates on the system. As shown below, the on-premise Jabber
client (CSFMCHENG) has successfully completed CAPF enrollment and now has an LSC, just like the desk phones.
Figure 64. Unified CM Device Search Based on LSC Issued By dCloud: The Cisco Demo Cloud
NOTE: The device names/MAC addresses for your client may be different from the ones shown above.
NOTE: The CSFKONEAL device is not used in this scenario, so we will not CAPF enroll this device.
At this point, all on-premise devices are provisioned, have completed the CAPF enrollment, and have an LSC installed. Further,
the cluster is now in mixed-mode. You are now ready to enable and test secure encrypted calling.
10. Before proceeding, shutdown Jabber for Windows by clicking Settings ( ) > Exit in preparation for tasks later in this lab.
F. Create Secure Phone Security Profile and Apply to On-Premise Endpoints
The final step for enabling and configuring secure encrypted calling is to enable the endpoints for secure calling. You will create a
set of Phone Security Profiles based on the Universal Device Template - Model-independent Security Profile with encrypted
configuration and calling enabled. Then you will apply the appropriate profiles to the endpoints and Jabber client (CSFMCHENG).
Create Encrypted Phone Security Profiles
As documented in the Security chapter of the Cisco Preferred Architecture for Enterprise Collaboration CVD
(http://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/116/collbcvd/security.html), there are four
recommended device security profiles. These should be configured on the system. Table 4 below lists the recommended profiles
Table 4. Enterprise Collaboration PA Recommended Secure Phone Security Profiles
TFTP Encrypted Authentication Mode for

Phone Security Profile Name1 Device Security Mode
Config CAPF Enrollment
UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com2 Encrypted Enabled By Existing Certificate (precedence to LSC)
UDT-Encrypted-LSC.dcloud.cisco.com3 Encrypted Disabled By Existing Certificate (precedence to LSC)

3
UDT-Encrypted-NullString.dcloud.cisco.com Encrypted Disabled By Null String
UDT-Encrypted-AuthString.dcloud.cisco.com Encrypted Disabled By Authentication String

1 All profiles are based on the ‘Universal Device Template - Model-independent Security Profile’
2 The domain portion of these security profiles (dcloud.cisco.com) matches the domain of our system.
3 These profiles have already been pre-configured for you.
Cisco dCloud
1. Browse to the Unified CM Administration interface at https://cucm1.dcloud.cisco.com/ccmadmin/ from the Firefox web browser
on Workstation 3 (198.18.133.38).
2. Navigate to System > Security > Phone Security Profile and search for ”Name” “begins with”, enter dCloud:
“UDT”.The
Click Find.
Cisco Demo Cloud
Figure 65. Phone Security Profiles: UDT
Notice that two of the PA recommended Phone Security Profiles listed in Table 4 have already been configured: UDT-Encrypted-
NullString.dcloud.cisco.com and UDT-Encrypted-LSC.dcloud.cisco.com.
3. Click (Copy) next to the UDT-Encrypted-LSC.dcloud.cisco.com profile to create a copy. Rename the profile UDT-
Encrypted-LSC-TFTPenc.dcloud.cisco.com, change the Description field to UDT Encrypted Profile with LSC auth mode
and TFTP encryption, leave Encrypted selected for the Device Security Mode and check the TFTP Encrypted Config
option. Leave By Existing Certificate (precedence to LSC) selected in the Authentication Mode drop down. Leave the rest
of the settings at default values. Note that since you have already CAPF enrolled the endpoints, the CAPF settings of the
profile will have no impact unless a new CAPF operation is performed.
Figure 66. UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com Phone Security Profile
Cisco dCloud
4. Click .

5. Return to the Phone Security Profile list and click (Copy) next to the UDT-Encrypted-NullString.dcloud.cisco.com
profile to create a copy. Rename the profile UDT-Encrypted-AuthString.dcloud.cisco.com, change the Description field to
UDT Encrypted Profile with AuthString auth mode, leave Encrypted selected for the Device Security Mode, choose By
Authentication String from the Authentication Mode drop down. Leave the rest of the settings at default values.
Figure 67. UDT-Encrypted-AuthString Phone Security Profile
6. Click .
Cisco dCloud
7. Return to the Phone Security Profile list and confirm that all of the recommended Phone Security Profiles listed in Table 4
have been configured as shown below.
Figure 68. Phone Security Profiles: All Preferred Architecture Recommended UDTs dCloud: The Cisco Demo Cloud
Apply the Encrypted Phone Security Profile to the Endpoints (88x5 and DX) and Workstation 3 Jabber client (CSFMCHENG).
Next, apply the encrypted phone security profiles to the endpoints. Because you have configured security profiles based on the
universal device profile, you can apply the appropriate encrypted security profile to all on-premise devices.
8. Navigate to Device > Phone and click the 88x5 endpoint. Under Protocol Specific Information, in the Device Security Profile
field, click the encrypted security profile UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com that you just created.
Figure 69. Applying the UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com Device Security Profile to Hardware Endpoints
Cisco dCloud
9. Click . Click OK on the next dialog and then click . Click OK to apply the configuration changes. The
88x5 endpoint will re-register in encrypted phone mode.
Next, repeat this procedure for the DX endpoint. Besides changing the Device Security Profile, you will also begin managing the
web interface administrative credentials from the Unified CM device configuration page. Since you are enabling encrypted TFTP
configuration files, you no longer have to worry about the web interface credentials being readable in the TFTP configuration file.
10. On the DX configuration page, after setting the Device Security Profile to UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com,
scroll down to the Product Specific Configuration Layout section and under the Admin username and password area, enter
admin in the ‘Admin Username’ field and enter dCloud123! in the ‘Admin Password’ field.
Figure 70. Setting DX Web Interface Admin Username and Password
11. Click . Click OK and then click . Click OK to apply the configuration changes.
Once both desk phones are enabled for encryption and re-registered to Unified CM, confirm that the phones are running in
“Encrypted” mode:
12. On the 88x5, navigate to (Settings) > Admin settings > Security setup.
Figure 71. 88x5 Encrypted Security Mode
Cisco dCloud
13. On the DX, navigate to the endpoint web interface using the endpoint IP address http://<Endpoint_IP_Address>/. If prompted,
log in with the configured Admin username / password. Then, navigate to Setup > Status > Provisioning and note that the
Provision Security field shows Encrypted, indicating the endpoint is in secure mode.
Figure 72. DX70 Encrypted Security Mode
NOTE: The IP address of your DX may be different than shown above.
Cisco dCloud
Confirm that the phones have downloaded encrypted configuration files by reviewing status messages:
14. On the 88x5, navigate to (Settings) > Admin settings > Status > Status messages.
Figure 73. 88x5 Encrypted Configuration File (xml.enc.sgn)
NOTE: The MAC address and status message sequence on your phone may be different than shown above. Also, you may need
to scroll down in the status messages window to see the encrypted configuration” message
The .enc.sgn portion of the configuration file name shows Unified CM signed the file (.sgn) and that the file is encrypted (.enc).
NOTE: Before proceeding, ensure that the Jabber for Windows client (CSFMCHENG) on Workstation 3 is not running.
15. Finally, assign the appropriate encrypted universal device security profile to the on-premise Jabber client. Return to the device
list (under Device > Phone) and click CSFMCHENG.
16. Next, choose UDT-encrypted-LSC.dcloud.cisco.com as the Device Security Profile.
Figure 74. Applying the UDT-Encrypted-LSC Device Security Profile to On-Premise Jabber Client (CSFMCHENG)
This is an encrypted device security profile without TFTP configuration file encryption and ensures the Jabber client can be
registered both when on-premise and if connected over Expressway Mobile and Remote Access.
Cisco dCloud
NOTE: You will not configure or use Expressway Mobile and Remote Access in Scenario 1.
Encrypted TFTP configuration is not supported over Expressway Mobile and Remote Access. If the Jabber client will always be
registered on-premise (or via VPN), then you would select the same security profile used for the hardware dCloud: The Cisco Demo Cloud
endpoints earlier UDT-
Encrypted-LSC-TFTPenc.dcloud.cisco.com.
17. Click . Click OK and then click . Click OK again to apply the configuration changes to the Jabber client
(CSFMCHENG). You will confirm that Jabber is in secure mode when we make secure calls in the next section.
G. Confirm Secure Calling (Phone to Phone, Jabber to Phone)
You will confirm that you have properly configured secure encrypted calling by making a set of calls and verifying the encrypted
“lock” icon is shown at each endpoint.
1. Place a call from Anita Perez’s 88x5 to Charles Holland’s DX by dialing 6018.
2. Answer the call at the DX and confirm that the encrypted “lock” icon is visible on both phones as shown in the Figure below.
Figure 75. Secure Encrypted Call Verification – 88x5 and DX
Cisco dCloud
3. Hang up the call before proceeding to the next step.
Place a Call from Jabber Client to Hardware Endpoint and Confirm the Encrypted “Lock” Icon is Present
4. Launch Monica Cheng’s Jabber client, login again, and place a call to Charles Hollands DX by typing: 6018 or
[email protected] in the call field and clicking the button.
5. Answer the call at the DX and confirm that the encrypted “lock” icon is visible at both endpoints as shown in the Figure below.
Figure 76. Secure Encrypted Call Verification – Jabber for Windows and DX
6. Hang up the call.
Cisco dCloud
Scenario 2: Collaboration Application Security

Summary
In this scenario, we will configure and enable security for collaboration applications and integrations between applications including
Unity Connection, Cisco Meeting Server, and Expressway. This scenario is divided into the following 9 sections:
A. Provision and Register Hardware Endpoints and Jabber Client on the Mixed-Mode Unified CM Cluster
B. Unified CM and Unified CM IM & P Certificate Investigation
C. Secure Unified CM Integration with Unity Connection Next Generation Encryption
D. Cisco Meeting Server Secure Integration
E. Expressway Certificate Investigation and Tasks
F. Expressway-C Mobile and Remote Access (MRA) Configuration
G. Expressway-E MRA Configuration
H. Assign Unified CM Device Security Profiles to MRA Device and Confirm Non-Secure & Secure Calling
I. Move “Outside” Jabber Client “Inside” and Confirm Secure Calling After CAPF Enrollment
The Figure below depicts the topology and relevant components for this scenario.
Figure 77. Scenario 2: Collaboration Security for the Enterprise Preferred Architecture Lab Topology
Cisco dCloud
Steps

A. Provision and Register Hardware Endpoints and Jabber Client on the Mixed-Mode Unified CM Cluster
By default, the endpoints are auto-registered to the non-secure Unified CM cluster. For this scenario, you will move endpoint
registration (including Jabber) to the mixed-mode Unified CM cluster and then provision the endpoints for the end users.
Move endpoints to secure mixed-mode Unified CM cluster (ucm1.dcloud.cisco.com)
1. To move endpoints to the secure cluster, begin by configuring an alternate TFTP server on the 88x5 endpoint. Go to
(Settings) > Admin settings > Ethernet Setup > IPv4 Setup. Scroll down to Alternate TFTP and press the On softkey.
Figure 78. 88x5: Step 1- Enable Alternate TFTP Server
2. Move down to the TFTP Server 1 field using the keypad and change the address to 198.18.133.3. Press the Apply softkey.
Figure 79. 88x5: Step 2- Enter and Apply Alternate TFTP Server
Cisco dCloud
3. When prompted, press the Erase softkey to delete the Trust List and restart the endpoint.
Figure 80. 88x5: Step 3- Erase Endpoint Trust List

The endpoint will reboot a few times and eventually auto-register to the secure mixed-mode cluster.
4. While you wait for the 88x5 endpoint to auto-register, move the DX endpoint to the secure cluster. Begin by touching
(Settings) > System Information.
Figure 81. DX: Step 1 – Touch Settings > System Information
Cisco dCloud
5. On the next screen, touch the Settings button.
Figure 82. DX: Step 2 – Touch Settings

6. Next, touch Change Service.
Figure 83. DX: Step 3 – Touch Change Service
Cisco dCloud
7. On the next screen, touch Other Services and then touch Cisco UCM.
Figure 84. DX: Step 4 – Select Other Services and Cisco U CM

8. On the next screen, touch Continue to confirm the move from Cisco UCM to Cisco UCM and remove all settings.
Figure 85. DX: Step 5 – Confirm Unified CM to Unified CM Move and Settings Removal
Cisco dCloud
9. Toggle off the ‘Automatic configuration’ setting, type 198.18.133.3 in the ‘Enter server address’ field, and touch Ok.
Figure 86. DX: Step 6 – Manually Configure the Unified CM Services Address
10. Finally, touch Apply and wait for the Activation Successful screen followed by the Setup Done screen and touch Done.
Figure 87. DX: Step 7 – Touch Done After Service Successfully Activated and Setup is Done
Cisco dCloud
11. Press Back twice to return to the main screen. The endpoint will reset and auto-register to the secure mixed-mode cluster.
Figure 88. DX Auto-Registration to Secure Unified CM Cluster (ucm1.dcloud.cisco.com) Complete

NOTE: The DX may fail to reach the Unified CM cluster the first time. If this happens, you will receive an “Unable to connect”
message. Touch Change Server Address then touch Apply to re-connect to the secure cluster (ucm1.dcloud.cisco.com).
When the system successfully connects to the Unified CM cluster, you will see the screens shown previously in Figure 80.
Cisco dCloud
Because the Unified CM cluster is already mixed-mode and the point of this scenario is to focus on secure collaboration
applications, the system has been configured to CAPF enroll endpoints during auto-registration so that they already have locally
significant certificates (LSC). Further, the endpoints are configured to auto-register to the system in secure mode.
12. We can confirm the 88x5 phone completed the CAPF enrollment and registered in secure mode by going to (Settings)
> Admin settings > Security. The device is in secure mode and has a CAPF signed certificate installed.
Figure 89. 88x5: Endpoint Registration in Secure Mode with CAPF Enrollment Complete
We can confirm the DX endpoint is registered in secure mode using the web interface.
13. RDP to Workstation 3 at 198.18.133.38. Log in as DCLOUD\mcheng with password: C1sco12345. Using Firefox, go to the
DX web interface at the endpoint IP address http://<Endpoint_IP_Address>/. Login as admin with password: <blank>.
Figure 90. DX: Web Interface – Login
NOTE: The IP address on your endpoint may be different than shown above.
Cisco dCloud
14. Click Setup > Configuration > SIP and note that the ‘DefaultTransport’ field is set to Tls. This indicates the endpoint is using
TLS to encrypt SIP call signaling traffic showing that the endpoint is operating in secure mode.
Figure 91. DX: Web Interface: TLS Encrypted SIP Connection dCloud: The Cisco Demo Cloud
NOTE: The IP address on your endpoint may be different than shown above.
Use the Self-Provisioning interactive voice response (IVR) to provision hardware endpoints (88x5 and DX (running CE).
15. Now we will self-provision the auto-registered 88x5 and DX endpoints as indicated in Table 5 below.
Table 5. Self-Provisioning User ID, PIN and Device
4-digit Extension /
User Name User ID Endpoint Device Phone User PIN
Self-Provisioning ID
Anita Perez aperez 88x5 +1 212 555 6017 6017 1234
Charles Holland cholland DX70 +1 408 555 6018 6018 1234
NOTE: When self-provisioning the endpoints, ensure you provision the appropriate endpoint device for each user as shown above.
Cisco dCloud
16. To self-provision the 88x5, press the speed dial call the Self-Provisioning IVR number (1111). Once the IVR answers, follow
the audio prompts (as shown below and using the values in Table 5) to provision the endpoint:
 Enter the user’s Self Provisioning ID followed by the ‘#’ key dCloud: The Cisco Demo Cloud
 Confirm the user’s Self Provisioning ID by pressing the ‘#’ key
 Enter the user’s PIN number followed by the ‘#’ key.
17. After the PIN is entered, the 88x5 phone reboots. When the phone returns to service it will be provisioned for the user.
18. Follow the steps above to self-provision the DX, noting that you must manually dial the Self-Provisioning IVR number 1111, as
there is no speed dial on the DX. See the figures below for the final results.
Figure 92. 88x5 Desk Phone Self-Provisioned for Anita Perez
Figure 93. DX Video Endpoint Self-Provisioned for Charles Holland
NOTE: The phone screens above are examples; your phone screen may look slightly different.
Cisco dCloud
Review the Device Security Profiles on the system as in the Security chapter of the Cisco Preferred Architecture for Enterprise
Collab CVD (http://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/116/collbcvd/security.html) The four
recommended secure device security profiles are shown below in Table 6 below
Table 6. Enterprise Collaboration PA Recommended Secure Phone Security Profiles
TFTP Encrypted Authentication Mode for

Phone Security Profile Name1 Device Security Mode
Config CAPF Enrollment
UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com2 Encrypted Enabled By Existing Certificate (precedence to LSC)
UDT-Encrypted-LSC.dcloud.cisco.com3 Encrypted Disabled By Existing Certificate (precedence to LSC)

3
UDT-Encrypted-NullString.dcloud.cisco.com Encrypted Disabled By Null String
UDT-Encrypted-AuthString.dcloud.cisco.com Encrypted Disabled By Authentication String

1 All profiles are based on the ‘Universal Device Template - Model-independent Security Profile’
2 The domain portion of these security profiles (dcloud.cisco.com) matches the domain of our system.
3 These profiles have already been pre-configured for you.
19. Using Firefox on Workstation 3, browse to the Unified CM Administration interface (https://ucm1.dcloud.cisco.com/ccmadmin/).
Although the enterprise CA root certificate has already been imported to the local certificate trust stores of all the Windows
Workstations, in this case the browser does not have the CA root certificate in its trust store. For this reason, you need to add
the certificate to Firefox’s trust store. Bypass the certificate warning (click ‘I Understand the Risks’, click the Add Exception…
button and then click Confirm Security Exception) and then log in as administrator with password: dCloud123!.
Figure 94. Unified CM: Bypass Firefox Browser Certificate Warning by Confirming a Security Exception
Cisco dCloud
20. Navigate to System > Security > Phone Security Profile and perform search:” Name” “begins with”, enter “UDT”. Click Find.
Note that the recommended PA phone security profiles shown in Table 6 have already been configured on the system.
Figure 95. Phone Security Profiles: UDT dCloud: The Cisco Demo Cloud
21. Update the DX device security profile to enable encrypted TFTP configuration and perform another CAPF enrollment. Go to
Device > Phone and click Find to return a list of configured endpoints on the system. Click the DX endpoint MAC address
(under the Device Name column). Set the ‘Device Security Profile’ field to UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com,
which enables TFTP configuration file encryption. Note this automatically assigns appropriate values for the following fields in
the Certification Authority Proxy Function (CAPF) Information area:
 Authentication Mode = By Existing Certificate (precedence to LSC)
NOTE: the DX device already has an LSC from CAPF enrollment during initial auto-registration
 Key Order = RSA Only and RSA Key Size = 2048
22. Complete the CAPF enrollment configuration by setting the “Certificate Operation” field to Install/Upgrade, and specify some
date in the future for the “Operation Completes By” sub-fields. The following Figure shows the final settings for enabling
encrypted TFTP configuration file (via Device Security Profile) and generating a new CAPF enrollment for the DX endpoint.
Figure 96. DX: Encrypted TFTP Configuration Device Security Profile and CAPF Enrollment
Cisco dCloud
23. Before saving this configuration, scroll down to the Product Specific Configuration Layout section and choose HTTP+HTTPS
from the ‘Web Access’ drop down.
Figure 97. Enabling Web Access for the DX Video Endpoint dCloud: The Cisco Demo Cloud
24. Since you are enabling the TFTP configuration file encryption for this endpoint, configure a non-default admin password for the
DX endpoint web interface under the Admin username and password section of the page. Enter admin in the ‘Admin
Username’ field and in the ‘Admin Password’ fields enter dCloud123!.
Figure 98. Setting DX Web Interface Admin Username and Password
25. Click . Click OK and then click . Click OK to apply the configuration changes. The DX will reboot
and after CAPF enrollment, re-register to Unified CM.
Cisco dCloud
26. Navigate to the DX endpoint web interface at the endpoint IP address http://<Endpoint_IP_Address>/. If prompted, log in as
admin with password: dCloud123!. Click Setup > Status > Provisioning and note that the ProvisionSecurity field shows
Encrypted. This indicates the endpoint is requesting and receiving encrypted configuration files from the TFTP server.
Figure 99. DX: Web Interface – Encrypted TFTP Configuration File
27. Navigate to Security > Service Certificates and you can see the LSC (endpoint certificate) that is installed on the endpoint.
Figure 100. DX: Web Interface – Locally Significant Certificate (LSC)
28. Update DNS Server UDS SRV record to resolve to Mixed-Mode Unified CM cluster (ucm1.dcloud.cisco.com) for Jabber
service discovery.
Cisco dCloud
29. RDP to AD1 (198.18.133.1 or ad1.dcloud.cisco.com) and log in as DCLOUD\administrator with password: C1sco12345.
30. Click on the DNS Manager icon in the Desktop task bar.
Figure 101. Launching DNS Manager on ad1.dcloud.cisco.com
31. Update the DNS SRV record for cisco-uds by navigating to AD1 > Forward Lookup Zone > tcp and clicking the _cisco-uds
record, right click, and chooset Properties. Change the Host offering this service field from ‘cucm1.dcloud.cisco.com’ to
‘ucm1.dcloud.cisco.com’. Click Ok to save changes to the record.
Figure 102. Updating the DNS SRV Record for Jabber Service Discovery
32. Right click AD1 in the left-hand pane and click Update Server Data Files. Then right click again and click Clear Cache.
Cisco dCloud
33. Next, verify that the DNS SRV record change is correct by making a DNS SRV query from the Jabber workstation. RDP to
Workstation 3. Click Start and type cmd to bring up a command window. At the prompt, type nslookup and press <Enter>.
Type set type=SRV and <Enter>. Finally, type _cisco-uds._tcp.dcloud.cisco.com. If the DNS SRV record has changed,
you should see the output shown below where the SRV resolves to ucm1.dcloud.cisco.com / 198.18.133.3.
Figure 103. Validating UDS (ucm1.dcloud.cisco.com) DNS SRV Record for Jabber Service Discovery
34. Type exit and <Enter> to end the nslookup session. Then exit the cmd.exe window by typing exit and <Enter>.
35. Before moving on, return to the RDP session to AD1 (ad1.dcloud.cisco.com / 198.181.133.1) and close DNS Manager and
logoff/clear the RDP session. Keep the RDP connection to Workstation 3 (198.18.133.38) open as you will continue to use that
workstation for the following steps.
Configure on-premise Jabber (CSF) device and logon to Jabber for Windows Client for the first time.
36. Browse to the Unified CM Administration interface (https://ucm1.dcloud.cisco.com/ccmadmin/) from Firefox Workstation 3
(198.18.133.38). Log in (if required) as administrator with password: dCloud123!. Navigate to Device > Phone and click
Find. Click the CSFMCHENG device.
37. On the CSF device configuration page, UDT-Encrypted-AuthString.dcloud.cisco.com is already selected in the “Device
Security Profile” drop down. Note that this profile automatically assigns appropriate values for the following fields in the
Certification Authority Proxy Function (CAPF) Information area:
 Authentication Mode = By Authentication String
 Key Order = RSA Only
 RSA Key Size = 2048
Cisco dCloud
38. Complete the CAPF enrollment configuration by setting the “Certificate Operation” field to Install/Upgrade, entering 12345 in
the “Authentication String” field, and specify some date in the future for the “Operation Completes By” sub-fields. See the
following Figure for the final settings for CAPF enrolling the Jabber for Windows client device (CSF).
Figure 104. Configure Jabber Client CSFMCHENG for Secure Mode and CAPF Enrollment using Authentication String
40. Double-click the Jabber icon on the desktop, log in as mcheng with password: C1sco12345. You should see a pop-up
window that prompts for the authorization string.
41. Enter the authorization string specified previously: 12345. Click OK.
Cisco dCloud
42. As shown below, the Jabber IP phone service will not connect until after the user has entered the authentication string and the
CAPF enrollment operation has completed.
Figure 105. CAPF Enrollment with Authentication String – Cisco Jabber for Windows dCloud: The Cisco Demo Cloud
Cisco dCloud
43. While completing the CAPF enrollment, you will also see a warning that the Unity Connection voice mail service certificate is
not valid as shown in Figure 99. You receive this warning because the certificate from the Unity Connection voicemail service
node is the default self-signed certificate and this certificate is not in the workstation’s local trust store. In this case, click
Decline to refuse the connection to the voicemail system for visual voicemail. If you were to click Accept, the certificate would
be saved to the local workstation trust store and the client would connect to the voicemail system. However, to be sure you are
connecting to a valid voicemail system and receiving a valid server certificate, you would need to validate this certificate
manually before proceeding. Otherwise, you may be compromising the system. When you click decline, you receive a
message on the Jabber client that visual voicemail service will not be connected. The message states that the connection to
the Unity Connection server (cuc1.dcloud.cisoc.com) has been rejected due to invalid certificate.
Figure 106. Jabber Voicemail Service Certificate Warning and Error Message After Certificate Decline
NOTE: Voicemail service will connect with automatic certificate validation once you sign the Unity Connection tomcat
certificate with the enterprise CA in section C of this lab. After that, you will no longer receive the certificate not valid warning
and the certificate verification window will be eliminated.
Cisco dCloud
44. The Jabber client automatically logs in and connects to the Unified CM, IM & P, and Active Directory (LDAP) servers for video
calling, IM & Presence, and directory services. Confirm these connections by clicking Settings ( ) > Help > Show
connection status. dCloud: The Cisco Demo Cloud
Figure 107. Jabber Connection Status Information
Cisco dCloud
Notice you received no warning about the validity of servers or certificates when connecting to the presence and call control
services. This is because the certificates for the Unified CM IM & P and Unified CM systems have already been signed by
enterprise CA. You will review these certificates in Section B. Further, the root certificate of the enterprise CA has previously been
added to the local workstation’s certificate trust list. When these certificates were offered to the client attempting presence and call
control service connections, the client was able to automatically validate the offered server certificates against the local trust store.
45. Return to Jabber device configuration page on Unified CM at https://ucm1.dcloud.cisco.com/ccmadmin/ and click Device >
Phone. Change the Device Security Profile to UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com to enable TFTP encrypted
configuration file in addition to secure mode.
Figure 108. Update Jabber Device Security Profile to UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com
46. Click . Click OK and then click . Click OK to apply the configuration changes. Verify that the
Jabber client on Workstation 3 reconnects to Unified CM IP phone service before proceeding.
Place a call from the On-premise Jabber Client to Hardware Endpoint and Confirm the Encrypted “Lock” Icon is Present.
47. Ensure Monica Cheng’s Jabber client on Workstation 3 has reconnected after the previous device configuration change was
made. Then, place a call to Charles Holland’s DX by typing: 6018 or [email protected] in the call field and clicking
the button.
Cisco dCloud
48. Answer the call at the DX and confirm that the encrypted “lock” icon is visible at both endpoints as shown below.
Figure 109. Secure Encrypted Call Verification – Jabber for Windows and DX
50. Finally, exit/close the Jabber client on Workstation 3.
Cisco dCloud
B. Unified CM and Unified CM IM & P Certificate Investigation
** OPTIONAL **: The steps in this section involve reviewing existing certificates on the Unified CM and Unified CM IM & P cluster
nodes. This step is not required to complete the lab. In the interest of time, you may choose to proceed to the next sub-section (C).
Certificates play a critical role in collaboration security. We will examine the Unified CM and Unified CM IM & P certificate best
practices from the Enterprise Collaboration Preferred Architecture. This begins with a look at existing certificates on the Unified CM
cluster, followed by investigation of multi-server (Unified CM / IM & P) certificate CSR generation to illustrate multi-server SAN
(Subject Alternative Name) certificates. Finally, you will look at the existing certificates on the Unified CM IM & P cluster.
Examine the existing certificates on Unified CM (ucm1.dcoud.cisco.com).
1. RDP to Workstation 3 (198.18.133.38) and log in as DCLOUD\mcheng with password: C1sco12345. Using Firefox, go to the
Unified CM Operating System administrative interface at https://ucm1.dcloud.cisco.com/cmplatform.
2. Click Security > Certificate Management and then click Find.
3. The Figure below shows the Unified CM OS Certificate Management interface and a list of the system certificates.
Figure 110. Unified CM Certificate List
Cisco dCloud
Unified CM security best practice in the Enterprise Collaboration PA is to install certificate authority (CA) signed certificates on the
system rather than relying on self-signed certificates. A public CA or private enterprise CA should sign the following certificates:
 tomcat dCloud: The Cisco Demo Cloud
 CallManager
As shown, both certificates are signed and the enterprise CA root certificate (dCloud-AD1-CA) is uploaded to the CallManager and
tomcat trust stores. The signed tomcat certificate is a multi-server SAN certificate. Multi-server SAN certificates simplify certificate
management, particularly in deployments with large numbers of cluster nodes. With mutli-server certificates, Unified CM, Unified
CM IM & P, and Unity Connection cluster nodes use the same CA signed certificate for specific connection types.
Generate a multi-server certificate signing request (CSR)
4. Return to the Unified CM Operating System administrative interface: https://ucm1.dcloud.cisco.com/cmplatform and log in as
administrator with password: dCloud123!.
5. Click Security > Certificate Management for the Certificates List. Click the Generate CSR button. To generate a multi-server
SAN CSR for tomcat, choose tomcat (default) as the Certificate Purpose and Multi-server(SAN) from the Distribution drop
down. When you choose multi-server, the common name changes to ucm1-ms.dcloud.cisco.com and both the Unified CM
(ucm1.dcloud.cisco.com) and Unified CM IM & P node (imp1.dcloud.cisco.com) FQDNs are added as SANs to the CSR.
Figure 111. Unified CM: Generate a tomcat Multi Server Certificate Signing Request
Cisco dCloud
Because a multi-server certificate is already issued and signed, there is no need to repeat the process again. Click Close.
Although you do not need to sign this certificate, multi-server SAN certificates streamline the certificate signing process. With multi-
server certificates, both Unified CM and Unified CM IM & P cluster nodes uses the same CA signed certificate. In this lab, a single
multi-SAN CA-signed tomcat certificate (ucm1-ms.dcloud.cisco.com) is used across the two Unified CM / IM&P cluster nodes:
Unified CM Publisher/Subscriber/TFTP (ucm1.dcloud.cisco.com) and Unified CM IM&P Publisher/Subscriber
(imp1.dcloud.cisco.com). These two nodes share the multi-server tomcat certificate for both tomcat connections.
Normally, after generating the CSR, you download it and then use it to request a signed certificate from the CA. The root certificate
of the CA (dCloud-AD1-CA) is uploaded to the appropriate Unified CM trust store (tomcat-trust). Once issued the signed certificate
is uploaded to the appropriate Unified CM connection (tomcat). The multi-server tomcat certificate is automatically pushed from the
cluster publisher node to all other applicable cluster nodes. In this case, once the signed tomcat multi-server certificate is uploaded
to the publisher node (ucm1.dcloud.cisco.com) it is automatically uploaded to the Unified CM IM & P node (imp1.dcloud.cisco.com)
which was added as a SAN when we generated the multi-server SAN CSR. If there were additional Unified CM or Unified CM IM &
P nodes in our cluster running the tomcat service, these nodes would also automatically upload the tomcat multi-server certificate.
These other cluster nodes would have been auto-populated in the SAN window when we were generating the CSR.
Table 7 below shows the Enterprise Collaboration PA recommendation for CA-signed multi-server SAN certificates for
collaboration application nodes.
Table 7. Recommended CA-Signed Multi-Server SAN Certificates
Product Certificate Notes
Shared certificate across all Unified CM and Unified CM IM & P

Unified CM and Unified CM IM & Presence tomcat
nodes in the cluster
Shared certificate across all Unified CM cluster nodes running

Unified CM CallManager
CallManager service
Unified CM IM and Presence cup-xmpp Shared certificate across all Unified CM IM & P cluster nodes
Unified CM IM and Presence cup-xmpp-s2s Shared certificate across all Unified CM IM & P cluster nodes
Unity Connection tomcat Shared certificate across both Unity Connection cluster nodes
NOTE: Once the multi-server SAN certificate CSR is generated and the signed certificate uploaded to the relevant publisher node,
if additional nodes are added to the cluster, the multi-server SAN certificate must be regenerated. A new multi-server SAN CSR
requires a new signed multi-server SAN certificate.
Examine the existing certificates on Unified CM IM & P cluster node (imp1.dcoud.cisco.com)
6. Using Firefox on Workstation 3 (198.18.133.38), open a new tab and navigate to the Unified IM and Presence Operating
System administrative interface: https://imp1.dcloud.cisco.com/cmplatform.
Cisco dCloud
7. The Unified CM IM & P certificate is signed by enterprise CA, but the CA root certificate is not in the Firefox browser’s trust
store, so you must manually add a security exception. Bypass the warning (click ‘I Understand the Risks’, click the Add
Exception… button and then click Confirm Security Exception) then log in as administrator with password: dCloud123!.
Figure 112. Unified CM IM&P: Bypass Firefox Browser Certificate Warning by Confirming a Security Exception
8. Click Security > Certificate Management and then click Find.
Figure 113. Unified CM IM & P Certificate List
Cisco dCloud
The Cisco Unified CM IM and Presence security best practice shown in the Enterprise Collaboration PA is to install certificate
authority (CA) signed certificates on the system rather than relying on the default self-signed certificates. A public CA or private
enterprise CA should sign the following certificates:
 tomcat
 cup-xmpp
 cup-xmpp-s2s
All of these certificates are signed and the enterprise CA root certificate (dCloud-AD1-CA) is uploaded to the cup-xmpp and tomcat
trust stores. The signed tomcat certificate is the multi-server SAN certificate you saw earlier in the certificate list. This certificate
automatically uploaded to the Unified CM IM & P cluster node. Multi-server SAN certificates simplify certificate management. In this
case, both Unified CM and Unified CM IM & P nodes are using the same CA signed certificate for tomcat connections.
C. Secure Unified CM Integration with Unity Connection Next Generation Encryption
In this section, you enable secure integration between Unified CM and the Unity Connection voicemail system. You begin by
investigating Unity Connection certificates and then CA-signing the Unity Connection tomcat certificate. Next, you enable
encryption on the Unified CM SIP trunk to Unity Connection and make the necessary configuration changes on Unity Connection to
enable end-to-end encryption between Unified CM and Unity Connection as well as between the endpoints and Unity Connection.
Make Preliminary Voicemail Calls to Confirm Functionality and Unencrypted Calling
1. Call from Anita Perez’s 88x5 to Charles Holland’s DX by dialing: 6018 and going of hook. The call will ring at the DX. Allow the
call to forward to Charles Holland’s voicemail on the Unity Connection voicemail system. Touch Decline on the incoming call
dialog to push the call to voicemail immediately. The redirected call to the Unity Connection voicemail system is not encrypted
as shown by the absence of a lock icon for the call on the 88x5. Leave a brief voice message and end the call.
2. Once the message waiting indication is displayed on the DX, press Messages to retrieve the message from the Unity
Connection voicemail box using the voicemail pilot (2010).
Figure 114. DX: Voicemail Message Waiting Indicator
Cisco dCloud
3. Once the call connects to the voicemail system, notice that the DX indicates the call is unencrypted.
Figure 115. DX: Unencrypted Call to the Unity Connection Voicemail System.
4. On the DX, hang up the call to Unity Connection.
Unity Connection Certificate Investigation and Management
By default, the Unity Connection tomcat certificate is self-signed. Like with other application servers (Unified CM and Unified CM
IM&P), the recommendation is to install certificate authority (CA) signed certificates on the system instead of relying on the default
self-signed certificates. A public CA or private enterprise CA should sign the following Unity Connection certificates:
 tomcat
By using a CA-signed certificate, it is much easier to install and manage one CA certificate on the end-user workstations instead of
several certificates used by several services. Otherwise, the Jabber workstations would need separate tomcat certificates for
Unified CM, IM & Presence, Unity Connection (HTTPS connection for visual voicemail). The Unity Connection tomcat certificate is
not only used for the server web interface, but also when end-users are connecting to Cisco Personal Communications Assistant
and for SIP traffic over the SIP trunk between Unified CM and Unity Connection when using Next Generation encryption.
Cisco dCloud
5. Begin by signing the Unity Connection tomcat certificate with the enterprise CA. On Workstation 3, open Firefox and navigate
to the Unity Connection Operating System administrative interface: https://cuc1.dcloud.cisco.com/cmplatform. Bypass the
certificate warning (click ‘I Understand the Risks’, click the Add Exception… button, and then click Confirm Security
Exception). Log in as administrator with password: dCloud123!.
Figure 116. Unity Connection: Bypass Firefox Browser Certificate Warning by Confirming a Security Exception
6. Once logged in to the Unity Connection Operating System administrative interface, click Security > Certificate Management
and then click Find.
Figure 117. Unity Connection Certificate List
Cisco dCloud
7. Begin the CA signing process by clicking the Generate CSR button. If necessary, choose tomcat from the “Certificate
Purpose” drop down. Leave all other values as the defaults, ensuring that the key length and hash algorithms are set to 2048
and SHA256 respectively. Click Generate.
NOTE: Multi-server SAN is not available in the Distribution field because there is only one node in the Unity Connection cluster.
With a multiple node Unity Connection cluster, you have the option of generating a Multi-server SAN CSR that would automate and
simplify server certificate management.
Figure 118. Generate Unity Connection tomcat CSR
8. Once the CSR is created, click Close. When the Certificate List reloads, view the tomcat CSR you just generated.
Figure 119. Unity Connection tomcat CSR
Cisco dCloud
9. Download the CSR by clicking on the CSR and then clicking Download CSR.
Figure 120. Downloading the Unity Connection tomcat CSR

NOTE: The certificate file date shown above may be different on your system.
Cisco dCloud
10. In the Open with / Save File dialog, choose ‘Open with’, click Browse, and then choose Microsoft Wordpad (or Notepad).
Figure 121. Opening and Copying the tomcat CSR

Cisco dCloud
11. Click OK to choose Wordpad. Click OK again to open the file. Once the file opens, select the contents of the file and copy to
the clipboard (Ctrl-C).
Figure 122. Copying the CSR Text dCloud: The Cisco Demo Cloud
12. Close the CSR Details window and proceed to issuing and signing the Unity Connection tomcat certificate using our enterprise
CA (ad1.dcloud.cisco.com).
13. Using Firefox on Workstation 3, navigate to http://ad1.dcloud.cisco.com/certsrv. Log in as administrator with password:
C1sco12345 when prompted to authenticate.
Cisco dCloud
14. Click on Request a certificate. Next, click on ‘Or, submit an advanced certificate request’.

15. Paste (Ctrl-V) the contents of the clipboard (copied from the CSR) to the Base-64-encoded certificate request field. Choose
the ClientServer Certificate Template and click on Submit >.
Figure 124. Submit the Unity Connection tomcat Certificate Request
Cisco dCloud
16. On the next screen, choose DER encoded (default) or Base 64 encoded and then Download Certificate.
Figure 125. Save the Signed Unity Connection tomcat Certificate

17. Click Save File and click OK to save to the local workstation. Name the file tomcat.cer.
18. Before leaving enterprise CA, download the CA root certificate. Return to https://ad1.dcloud.cisco.com/certsrv/ by clicking the
Home link in the upper right-hand corner and click Download a CA certificate, certificate chain, or CRL.
Cisco dCloud
19. On the next screen, ‘Current [dcloud-AD1-CA]’ is selected by default. Click Download CA Certificate.

20. Finally, click Save File and click OK to save to the local workstation. Name the file dCloud_root.cer.
Now that the tomcat certificate is issued and signed, upload the enterprise CA root and signed tomcat certificate to Unity
Connection.
21. Return to the Unity Connection Operating System administrative interface (https://cuc1.dcloud.cisco.com/cmplatform/). Log in
(if required) as administrator with password: dCloud123!.
Cisco dCloud
22. Click Security > Certificate Management and then click Upload Certificate/Certificate chain.
Figure 128. Upload CA-signed tomcat and CA Root Certificates to Unity Connection
23. First, upload the enterprise CA root certificate to the tomcat-trust store. Choose tomcat-trust from the “Certificate Purpose”
dropdown and enter “dCloud-AD1-CA” for the “Description” field. Then click, browse, and chooose the certificate you saved
previously: dCloud_root.cer (located at C:\Users\mcheng\Downloads). Click Open. Finally, click Upload.
Figure 129. Upload the CA Root Certificate to Unity Connection tomcat-trust
NOTE: You can wait to restart the tomcat service until the end of this section.
Cisco dCloud
24. Next, upload the CA-signed tomcat certificate by choosing tomcat from the “Certificate Purpose” dropdown. Click Browse and
find the certificate saved previously: tomcat.cer (located at C:\Users\mcheng\Downloads). Click Open. Next, click Upload.
Figure 130. Upload the CA-Signed tomcat Certificate dCloud: The Cisco Demo Cloud
25. Click Close and then on the Certificate List page (Security > Certificate Management) click Find to display the newly
uploaded CA root and CA-signed tomcat certificates. The CA-signed tomcat certificate is listed along with the enterprise CA
root certificate in the tomcat-trust store.
Figure 131. Uploaded CA-Signed tomcat Certificate and CA Root Certificate on Unity Connection
Cisco dCloud
You need to restart the Cisco Tomcat service since you uploaded a new CA-signed certificate and updated the tomcat-trust store.
26. SSH to the Unity Connection (cuc1.dcloud.cisco.com) command line interface using Putty on Workstation 3 (198.18.133.38).
27. Double-click the Putty icon . Enter cuc1.dcloud.cisco.com in the “Host Name (or IP Address)” field. Click Open.
28. Click Yes to cache the ssh-rsa2 key.
Figure 132. Key Cache Confirmation for SSH to Unity Connection
29. Log in as administrator with password: dCloud123!. Enter the command utils service restart Cisco Tomcat at the
command line. The Cisco Tomcat service will restart. Once the service has restarted, type exit to close the SSH session.
Figure 133. Restarting the Cisco Tomcat Service on Unity Connection
NOTE: It may take a few minutes for Cisco Tomcat service to restart and the web administration interfaces to return to service.
Cisco dCloud
The next time you navigate to one of the Unity Connection web administration interfaces you will see a certificate warning since the
tomcat certificate has been regenerated and signed. Although the enterprise CA root certificate has already been imported to the
local certificate trust stores of all the Workstations, the browser does not have the enterprise CA root certificate in its trust store, so
you need to add the certificate to Firefox browser’s trust store.
30. As before, bypass the certificate warning (click ‘I Understand the Risks’, click the Add Exception… button and then click
Confirm Security Exception). Log in as administrator with password: dCloud123!.
Figure 134. Unity Connection: Bypass Firefox Browser Certificate Warning by Confirming a Security Exception
Cisco dCloud
Secure SIP Trunk between Unified CM and Unity Connection
In this task, first configure Unified CM with a secure SIP trunk security profile and choose that profile for the existing SIP trunk to
Unity Connection. Then, configure Unity Connection to use encryption between Unity Connection and Unified CM.The Cisco Demo Cloud
dCloud:
31. Using Firefox on Workstation 3, navigate to the Unified CM Administrative interface: https://ucm1.dcloud.cisco.com/ccmadmin
and log in as administrator with password: dCloud123!. Click System > Security > SIP Trunk Security Profile. Click Find,
locate the CUC SIP Trunk Security Profile, and click (copy icon) to copy this profile to a new profile.
32. Enter CUC Encrypted_SIP_Trunk Security Profile in the “Name” field, Unity Connection Encrypted SIP Trunk Security
Profile in the “Description” field, and choose Encrypted from the “Device Security Mode” dropdown. The fields Incoming
Transport Type, Outgoing Transport Type, and Incoming Port are automatically updated to TLS, TLS, and 5061 respectively.
For the X.509 Subject Name, enter the common name (CN) used in the Unity Connection tomcat certificate:
cuc1.dcloud.cisco.com. Click Save to create the new profile.
Figure 135. Unified CM Encrypted SIP Trunk Security Profile for the Unity Connection SIP Trunk
NOTE: The certificate signature verification is used for authentication and allows the SIP trunk to be in full service. The SIP
Trunk security profile X.509 Subject Name field is used for Authorization. If the X.509 Subject Name field is incorrect, the SIP
trunk may still come up, but SIP requests to Unity Connection will fail.
Cisco dCloud
33. Next, secure the existing SIP trunk to Unity Connection by applying this new encrypted SIP trunk security profile. On Unified
CM (ucm1.dcloud.cisco.com) navigate to Device > Trunk and click Find. Locate the SIP trunk for Unity Connection:
cuc1_SIP_Trunk. Click the trunk name to open the configuration page. Update the trunk configuration by first clicking the
SRTP Allowed check box. Next, choose CUC Encrypted_SIP_Trunk Security Profile from the “SIP Trunk Security Profile”
drop down and change the SIP Trunk Destination Port to 5061.
Figure 136. Unified CM: Securing the SIP Trunk to Unity Connection
34. Click . Click OK and then click . Click Reset to reset the trunk. Once the message “Reset request was sent
successfully.” is returned, click Close.
At this point, the SIP Trunk will not return to service until you complete security configuration on the Unity Connection server.
35. Browse to the Unity Connection administrative interface (https://cuc1.dcloud.cisco.com/cuadmin/) and log in as administrator
with password: dCloud123!. Navigate to Cisco Unity Administration > Telephony Integrations > Security > SIP Security
Profile. Verify that the 5061/TLS profile exists as shown below.
Figure 137. Unity Connection: 5061/TLS SIP Security Profile
Cisco dCloud
36. Click the profile name and on the next page, confirm the “Port” field shows 5061 and the “Do TLS” checkbox is ticked as
shown below.
Figure 138. Unity Connection: Verifying the 5061/TLS SIP Security Profile dCloud: The Cisco Demo Cloud
Configure Encryption for the Telephony Integration on Unity Connection
To configure encryption, begin by configuring the Unified CM cluster TFTP server. This ensures Unity Connection will automatically
download the Unified CM CallManager certificate when you enable encryption.
37. Navigate to Telephony Integrations > Port Group. Click UCM1_PhoneSystem-1 to edit the port group. Then, open the Edit
menu and click Servers.
Figure 139. Unity Connection: Port Group Security Configuration - Servers
Cisco dCloud
38. On the Edit Servers page, under the TFTP Servers section, enter the FQDN for the Unified CM TFTP server:
ucm1.dcloud.cisco.com and then click Save.
Figure 140. Unity Connection: Adding the Unified CM TFTP Server to the Port Group dCloud: The Cisco Demo Cloud
NOTE: In this lab, the SIP Server and TFTP Server are the same for ease of replication and capacity, however, for the Enterprise
PA recommended design, your TFTP server node(s) would be standalone and separate from the Unified CM call processing
subscriber node(s).
Cisco dCloud
39. Prior to resetting the port group, enable security for the port group. Return to the main port group configuration page by
clicking the Edit menu and then choosing Port Group Basics.
Figure 141. Unity Connection: Securing the Phone System Port Group dCloud: The Cisco Demo Cloud
40. Enable security on the port group by choosing 5061/TLS from the “SIP Security Profile” drop down. This reveals the check
boxes: “Enable Next Generation Encryption” and “Secure RTP”. Check both of these boxes to enable encryption and secure
calling. Click Save to save the configuration.
Cisco dCloud
41. Finally, click the Reset button to reset the port group.
Figure 142. Unity Connection: Reset the Phone System Port Group
42. Since encryption is enabled between Unity Connection and Unified CM phone system (ucm1.dcloud.cisco.com), when the port
group resets, Unity Connection automatically retrieves the Unified CM CallManager certificate from the Unified CM TFTP
server and uploads to the local CallManager-trust store. Confirm this occurred by returning to the Unity Connection Operating
System administration portal at https://cuc1.dcloud.cisco.com/cmplatform/ and log in as administrator with password:
dCloud123!. Go to Security > Certificate Management. Click Find to bring up the full certificate list and note that the Unified
CM CallManager certificate (ucm1.dcloud.cisco.com) has been uploaded to CallManager-trust.
Figure 143. Unity Connection: Unified CM CallManager Certificate Automatically Uploaded to Local CallManager-trust Store
Cisco dCloud
43. Verify the trunk is in full service by returning to the Unified CM administration portal (https://ucm1.dcloud.cisco.com/ccmadmin)
and logging in, if required, as administrator with password: dCloud123!. Go to Device > Trunk. Click Find to load/reload the
SIP Trunk list and ensure the Unity Connection SIP Trunk has returned to Full Service.
Figure 144. Unified CM: Full Service Secure SIP Trunk to Unity Connection
Verify Encrypted Calling Between Endpoints and Voicemail System (Leaving and Retrieving Voicemails)
Finish this section on Secure Unified CM Integration with Unity Connection by making a few calls to verify secure encrypted calling
between the endpoints and the voicemail system.
44. Place a call from Anita Perez’s 88x5 to Charles Holland’s DX by dialing: 6018 and going of hook. The call will ring at the DX.
Allow the call to forward to Charles Holland’s voicemail box on the Unity Connection voicemail system. Press Decline on the
incoming call dialog to push the call to voicemail immediately.
45. Notice the lock icon on the 88x5 endpoint indicating the redirected call to the Unity Connection voicemail system is encrypted.
Leave another brief voice message for Charles Holland and end the call.
Figure 145. 88x5: Encrypted Secure Redirect Call to Unity Connection
Cisco dCloud
46. Once the message waiting indication is displayed on the DX, press Messages to retrieve the message from the Unity
Connection voicemail box using the voicemail pilot (2010).
Figure 146. DX: Voicemail Message Waiting Indicator dCloud: The Cisco Demo Cloud
NOTE: If you previously saved or deleted the voice message left at the beginning of this section, then your message count will
be different from what is shown above.
47. Once the call connects to the voicemail system, notice the DX displays the encrypted call icon indicating the call to the
voicemail system is encrypted.
Figure 147. DX: Encrypted Secure Call to Unity Connection
Cisco dCloud
48. On the DX, hang up the call to Unity Connection.

D. Cisco Meeting Server Secure Integration
In this section, you will manage certificates on the Cisco Meeting Server and then configure secure integration and call encryption
between Unified CM and Unified CM-registered endpoints and the Cisco Meeting Server.
Generate Enterprise CA Signed Certificates and Upload them to Cisco Meeting Server
Generate CSR for Server Certificate via CMS command line
1. RDP to Workstation 3 (198.18.133.38) and log in as DCLOUD\mcheng with password: C1sco12345. Using the PuTTY client,
SSH to cms1.dcloud.cisco.com (198.18.134.175). Click Yes to cache the host key.
Figure 148. SSH Key Cache Warning
2. Log in as admin with password: dCloud123!. Once logged in, at the command prompt, enter pki csr webadmin
CN:cms1.dcloud.cisco.com to generate a server CSR.
Figure 149. Cisco Meeting Server: Generating a Certificate Signing Request (CSR)
3. Next, click the WinSCP client in the taskbar of Workstation 3.
Figure 150. Launching WinSCP for Cisco Meeting Server File Access
Cisco dCloud
4. Open an SFTP session to cms1.dcloud.cisco.com with username: admin and password: dCloud123!.
Figure 151. WinSCP: Start SFTP Session to Cisco Meeting Server

5. Click Yes to cache the Cisco Meeting Server host key and complete the log in.
Figure 152. WinSCP: Caching the Cisco Meeting Server Hostkey
Cisco dCloud
6. Once connected, you should see the newly generated CSR file (webadmin.csr) on the right-hand window. Right click the
webadmin.csr file and choose Edit > Edit to view the CSR.
Figure 153. Viewing Certificate Signing Request (CSR) webadmin.csr dCloud: The Cisco Demo Cloud
7. When the CSR opens in Wordpad, copy the CSR text and use it to request the signed certificate from the enterprise CA.
Figure 154. Copying Cisco Meeting Server webadmin CSR
Cisco dCloud
8. Navigate to the enterprise CA at https://ad1.dcloud.cisco.com/certsrv. Log in as administrator with password: C1sco12345.

Once logged in, click the Request a certificate link. On the next screen, click the ‘Or, submit an advanced certificate
request‘ link.
9. Paste the CSR text from webadmin.csr to the Saved Request window. Choose Web Server from the ‘Certificate Template’
dropdown menu and then click Submit >.
Figure 156. Enterprise CA Certificate Signing: webadmin.cer
Cisco dCloud
10. On the next screen, leave encoding set to DER encoded and click Download certificate. Click Ok to save the certificate to
the local drive as webadmin.cer.
Figure 157. Saving the Newly Signed webadmin.cer dCloud: The Cisco Demo Cloud
Cisco dCloud
11. Download the CA root cert (dCloud_root.cer) by clicking the Home link in the upper right-hand corner of the web page. Click
the Download a CA certificate, certificate chain, or CRL link. On the next screen, click the Download CA certificate link.
Click Ok to save the root CA certificate to the local drive as dCloud_root.cer.
Figure 158. Saving the Enterprise Root CA Certificate: dCloud_root.cer
Cisco dCloud
Upload CA-Signed Certificates for Web Admin and Call Bridge and the Enterprise CA Root Certificate
12. Return to the WinSCP client on Workstation 3. If required, log in to cms1.dcloud.cisco.com as admin with password:
dCloud123!. Copy the recently downloaded CA-signed certificate and the CA root certificate to the Cisco Meeting
dCloud: Server
The Cisco Demo file
Cloud
system by dragging and dropping webadmin.cer (CA-signed certificate) and dCloud_root.cer (CA root certificate) to the
right-hand side of the window. Click Copy Here to copy the files.
Figure 159. Copying CA-Signed Certificate and CA Root Certificate to Cisco Meeting Server File System
Cisco dCloud
13. Now, enable the Cisco Meeting Server web administration interface with the new enterprise CA-signed certificate. Use the
PuTTY client on Workstation 3 to SSH to Cisco Meeting Server at cms1.dcloud.cisco.com. Log in as admin with password:
dCloud123!. Once authenticated, associate the new CA-signed certificate and the CA root certificate to the Web
Administration service with the following commands:
webadmin disable
webadmin certs webadmin.key webadmin.cer dCloud_root.cer
webadmin enable
The Figure below shows the CLI with log in, webadmin service review, and then entry of the commands above along with the
console response.
Figure 160. Cisco Meeting Server CLI: Associating CA-Signed Certificate and CA Root Certificate to Web Administration Service
Cisco dCloud
14. Verify that the certificate has been successfully associated to the Web Administration interface by browsing to the Cisco
Meeting Server administrative web interface https://198.18.134.175:445/. When prompted, bypass the certificate warning by
clicking ‘I Understand the Risks’, click the Add Exception… button, and then click Confirm Security Exception (ensuring
the Permanently store this exception box is checked).
Figure 161. Cisco Meeting Server: Bypass Firefox Browser Certificate Warning by Confirming a Security Exception
15. Proceed to log in. Click Ok to log in, enter username: admin and password: dCloud123! and then click Submit. Finally, click
Ok to acknowledge log in is successful.
Figure 162. Logging into Cisco Meeting Sever Web Administration Portal
Cisco dCloud
16. Once log in is complete, the System status page is displayed confirming that the Cisco Meeting Server now has a web server
certificate.
Figure 163. Cisco Meeting Server Web Administration Interface After Log In dCloud: The Cisco Demo Cloud
17. Next, return to the SSH client and the Cisco Meeting Server CLI interface to associate the CA-signed certificate to the Call
Bridge service interface. Use the same Web Administration CA-signed certificate to secure the Call Bridge service. Associate
the Web Administration CA-signed certificate to the Call Bridge service with the commands:
callbridge certs webadmin.key webadmin.cer dCloud_root.cer
callbridge restart
The Figure below shows the CLI with log in, callbridge service review, and then entry of the commands above along with the
console response.
Figure 164. Cisco Meeting Server CLI: Associating CA-Signed Certificate and CA Root Certificate to Call Bridge service
Cisco dCloud
18. Now that the enterprise CA-signed certificates are applied to pertinent Cisco Meeting Service interfaces, return to the web
interface (https://198.18.134.175:445/) and log in again if required as admin with password: dCloud123!. A Permanent
Meeting Space is already configured on the system, so navigate to Configuration > Spaces to review this configuration.
19. Notice the Permanent Meeting Space CMS Permanent Space 01 with URI of 6100 (corresponding to the directory number
(DN) of the space) is already configured for you. 6100 is the number you dial from your endpoints to connect to this space.
Figure 165. Cisco Meeting Server: Permanent Space Configuration Review (CMS Permanent Space 01)
20. Before proceeding, enable TLS/encryption for our conferences. Navigate to Configuration > Call settings. Choose required
from the ‘SIP media encryption’ dropdown field.
Figure 166. Cisco Meeting Server: Encrypted Calling for Secure Conferences
21. Click to save this configuration change.
22. Close the connection to the Cisco Meeting Server administrative web interface, as you do not have any more configuration
changes to make there.
Cisco dCloud
Configure Secure (TLS Encrypted) SIP Trunk Profile and Apply to SIP Trunk toward Cisco Meeting Server
23. From Firefox on Workstation 3, go to the Unified CM Admin Portal at https://ucm1.dcloud.cisco.com/ccmadmin/ and log in as
administrator with password: dCloud123!. Navigate to System > Security > SIP Trunk Security Profile.
24. Click Add New to configure a new secure SIP trunk security profile. Enter the following:
 Name: Secure_CMS_Trunk_Profile
 Description: Secure SIP trunk security profile for CMS
 Device Security Mode: Encrypted
 Incoming / Outgoing Transport Type: TLS / TLS
 X.509 Subject Name: cms1.dcloud.cisco.com
 Incoming Port: 5061
Figure 167. Cisco Meeting Server: Secure SIP Trunk Security Profile
Cisco dCloud
25. Click .
26. Next, configure the existing SIP trunk to Cisco Meeting Server for secure integration, enabling encrypted signaling
dCloud: between
Unified CM and Cisco Meeting Server and encrypted media between endpoints and the Cisco Meeting Server. Navigate to
Device > Trunk. Click Find. Click the trunk named cms1_Trunk from the list of SIP trunks on the system. Make the following
changes to the configuration page for this trunk:
 SRTP Allowed: Checked
 Destination Port: 5061
 SIP Trunk Security Profile: Secure_CMS_Trunk_Profile
Figure 168. Cisco Meeting Server: SIP Trunk
27. Click . Click Reset and then click OK to reset the trunk and apply the configuration changes. Proceed to the next
step, but periodically check back to ensure the SIP trunk returns to full service. It must return to service before ad-hoc and
permanent video conferences will be possible.
Cisco dCloud
Permanent Space Configuration for Ad-Hoc Video Conferences
28. While still logged in to the Unified CM Administration web portal (https://ucm1.dcloud.cisco.com/ccmadmin), navigate to Call
Routing > Route/Hunt > Route Patterns. Click Add New and configure the following: dCloud: The Cisco Demo Cloud
 Route Pattern: 6xxx
 Route Partition: Prime-DN-PT
 Description: Cisco Meeting Server Route Pattern
 Gateway/Route List: cms1_Trunk
29. All the remaining configuration fields and parameters may remain at their existing/default values.
Figure 169. Unified CM: Cisco Meeting Server Permanent Space Route Pattern
30. Click Save.
Verify that calls to the Cisco Meeting Server permanent space with URI/DN of 6100 are encrypted.
31. From the DX, press the Call button and then dial 6100 from the touchpad. Once your call is connected to the space, from the
88x5, touch the New Call softkey and dial 6100 using the keypad.
Cisco dCloud
32. Once the 88x5 is connected to permanent space, move to the Jabber for Windows client on Workstation 3. On the Jabber
client, type 6100 in the Call window and click the Call icon. As shown in the following figures, lock icons at each endpoint
indicate the Cisco Meeting Server permanent space conference call is encrypted between all three endpoints.
Figure 170. DX: Joined Cisco Meeting Server Permanent Space with Encryption
Figure 171. 88x5: Joined Cisco Meeting Server Permanent Space with Encryption
Figure 172. Jabber: Join Cisco Meeting Server Permanent Space with Encryption
33. Hang up the call at each endpoint before proceeding to the next section.
Cisco dCloud
E. Expressway Certificate Investigation and Tasks
This section, examines Expressway certificate best practices. This begins with a look at existing default certificates on
Expressway-C. Next, a CSR is generated for an Expressway-C server certificate and a certificate request is submitted to the
Enterprise CA. The resulting certificate chain is uploaded to the Trusted CA. This sequence is repeated for the Expressway-E
server. Finally, verify that signed server certificates and CA root certificate are in place on both servers.
Examine the existing server and trusted CA certificates on Expressway-C (exp-c-1.dcoud.cisco.com)
Certificates play a critical role in collaboration security. First, look at the various certificates on Expressway-C.
1. Using Firefox on Workstation 3, navigate to the Expressway-C administrative interface: https://exp-c-1.dcloud.cisco.com/.

Bypass the certificate warning (click ‘I Understand the Risks’, click the Add Exception… button and then click Confirm
Security Exception).
Figure 173. Expressway-C: Bypass Firefox Browser Certificate Warning by Confirming a Security Exception
2. Next, log in as admin with password: dCloud123!.
Cisco dCloud
3. From the menu, click Maintenance > Security Certificates > Trusted CA certificate. You will see the default temporary CA
certificate.
Figure 174. Expressway-C Default CA Certificate dCloud: The Cisco Demo Cloud
NOTE: The issuer information for the default temporary trusted CA certificate above may be different on your system.
4. Next, examine the default Expressway-C self-signed server certificate by navigating to Maintenance > Security Certificates
> Server certificate. Note the message recommending replacing this certificate with a certificate generated by a trusted CA.
Figure 175. Expressway-C Default Self-Signed Certificate
5. Click Show (decoded) to view the temporary server certificate details.
6. Repeat this step on the Expressway-E. Start by navigating to the Expressway-E administrative interface: https://exp-e-
1.dcloud.cisco.com/. Bypass the certificate warning (click ‘I Understand the Risks’, click the Add Exception… button, and
then click Confirm Security Exception) and log in as admin with password: dCloud123!.
Cisco dCloud
7. As you did previously, review the default temporary certificates on Expressway-E:
 Click Maintenance > Security Certificates > Trusted CA certificate to review the default certificate trust store.
 Click Maintenance > Security Certificates > Server certificate to review the default temporary server certificate.
Request a signed Expressway-C/E server certificate from enterprise CA
As recommended, replace the temporary server certificate with a certificate signed by a trusted-CA. First, generate a certificate
signing request (CSR).
8. Navigate to Expressway-C (https://exp-c-1.dcloud.cisco.com/). If necessary, bypass the certificate warning (click ‘I

Understand the Risks’, click the Add Exception… button, and then click Confirm Security Exception) and log in as admin
with password: dCloud123!.
9. Click Maintenance > Security Certificates > Server certificate. Click Generate CSR on the Server Certificate screen. On
the next screen, in the “Additional alternative names field” enter the following comma-delimited list: UDT-Encrypted-
NullString.dcloud.cisco.com, UDT- Encrypted-AuthString.dcloud.cisco.com , UDT-Encrypted-LSC.dcloud.cisco.com,
UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com. These alternative names are important and must match the name of the
encrypted device security profiles on Unified CM that have been previously configured.
10. Fill in the required fields in the Additional information section as shown below, leaving the Key length and Digest algorithm
fields at the defaults (4096 and SHA-256 respectively). Click the Generate CSR button.
Figure 176. Generate Expressway-C Certificate Signing Request (CSR)
Cisco dCloud
11. On the next screen, click the Show (PEM file) button under the “Certificate signing request (CSR)” section. This is NOT the
top one under the “Server certificate data” section. This opens the CSR you just created. Select the contents of the CSR and
copy (Ctrl-C) to the clipboard. You will use this to request a signed certificate from the Enterprise CA.
Figure 177. Displaying the Expressway-CSR
NOTE: The certificate request string shown above may be different in your CSR
12. Open Firefox and navigate to http://ad1.dcloud.cisco.com/certsrv. Log in as administrator with password: C1sco12345 when
prompted to authenticate.
13. Click on Request a certificate, then click ‘Or submit a advanced certificate request’.
Cisco dCloud
14. Paste the contents of the clipboard (just copied from the CSR) to the Base-64-encoded certificate request field. Choose the
ClientServer Certificate Template and click on Submit >.
Figure 178. Requesting a Certificate for Expressway-C from Enterprise CA dCloud: The Cisco Demo Cloud
Cisco dCloud
15. On the next screen, choose ‘Base 64 encoded’, click Download Certificate, click Save File, and click OK to save to the local
workstation. Name the file exp-c-1-cert.

NOTE: Unlike Unified CM, which handles both DER and Base 64 encoded certificates, Expressway requires Base 64 encoded
certificates.
Figure 179. Save the Signed Expressway-C Certificate
16. Return to the main CA page by clicking the Home link in the upper right-hand corner (https://ad1.dcloud.cisco.com/certsrv/)
and click Download a CA certificate, certificate chain, or CRL.
Cisco dCloud
17. On the next screen, ‘Current [dcloud-AD1-CA]’ is selected by default. Choose Base 64 as the Encoding method. Click
Download CA Certificate.
Figure 181. Download the Enterprise CA Root Certificate (2 of 2) dCloud: The Cisco Demo Cloud
18. Finally, click Save File and click OK to save to the local workstation. Name the file dCloud_root_b64.cer and click Save.
Figure 182. Saving the Enterprise CA Root Certificate as Base 64
Cisco dCloud
Next, repeat the same process on the Expressway-E certificate and trust store. However, in the case of Expressway-E, Cisco’s
best practice recommendation is to sign the Expressway-E certificate using a commonly trusted third party public CA.
For ease of use in this lab, you will forego the best practice recommendation of signing Expressway-E server certificates
dCloud: The Ciscousing a
Demo Cloud
public CA and instead will sign the certificate with the Enterprise CA as you have already done for the Expressway-C server.
NOTE: Getting the Expressway-E server certificate signed by a public CA is the same as the process when signing the certificate
by an Enterprise CA. The only difference is you must submit your CSR to the public CA that provides both the signed server
certificate and the root (and any required intermediate certificates). Just as with the Enterprise CA, you would upload the server
certificate and append the public CA root certificate.
19. Navigate to the Expressway-E administrative interface: https://exp-e-1.dcloud.cisco.com/. Log in as admin with password:
dCloud123!. If necessary, bypass the certificate warning (click ‘I Understand the Risks’, click the Add Exception… button,
and then click Confirm Security Exception).
20. Go to Maintenance > Security certificates > Server certificate, open (.PEM file), and copy to clipboard. Note that you need
to configure both exp-e-1.dcloud.cisco.com and dcloud.cisco.com (comma-delimited form) as an additional alternate
name. This is similar to when you configured various encrypted device security profiles as alternate names on Expressway-C.
Figure 183. Generate Expressway-E Certificate Signing Request (CSR)
Cisco dCloud
21. Request a certificate from the Enterprise CA (http://ad1.dcloud.cisco.com/certsrv/) and download as Base 64, this time saving
as exp-e-1-cert.cer.

NOTE: You do not need to download the Enterprise CA root certificate again. You can use the one you previously downloaded for
both Expressway-C and Expressway-E.
Upload the CA-signed server certificate and root CA certificate to Expressway-C/E
Now that you have downloaded and saved the signed Expressway server certificate, you need to upload it to the Expressway-C
server. You will also need to append the Enterprise CA root certificate to the Trusted CA on our Expressway-C
22. Navigate back to Expressway-C (https://exp-c-1.dcloud.cisco.com/) and return to the Server certificate page at Maintenance >
Security Certificates > Server certificate. Click Browse, choose the CA-signed Expressway-C certificate you downloaded
previously (exp-c-1-cert.cer) located at C:\Users\mcheng\Downloads, and click Open. Click Upload server certificate data.
Figure 184. Upload Server Certificate Data (CA-Signed Certificate) to Expressway-C
23. You will receive a certificate warning. Bypass the certificate warning (click ‘I Understand the Risks’, click the Add
Exception… button and then click Confirm Security Exception).
Cisco dCloud
24. You should then see “Files uploaded” and certificate expiration status messages as shown below.
Figure 185. CA-Signed Server Certificate Uploaded Successfully

NOTE: The expiration date for the server certificate in your lab will be different from the date shown above.
25. Next, append the CA root certificate to the Trusted CA trust store by navigating to Maintenance > Security Certificates >
Trusted CA certificate. Because you have uploaded a new server certificate, when attempting to navigate here you receive a
certificate warning. Bypass the certificate warning by accepting the new certificate (click ‘I Understand the Risks’, click the
Add Exception… button, and then click confirm Security Exception) to re-connect.
Cisco dCloud
26. Go to Maintenance > Security Certificates > Trusted CA certificate, click Browse, choose the Base 64 encoded Enterprise
CA root certificate (dCloud_root_b64.cer) located at C:\Users\mcheng\Downloads, and click Open.
Figure 186. Selecting the Base 64 Encoded Enterprise CA Root Certificate dCloud: The Cisco Demo Cloud
27. Once the Base 64 encoded root certificate is selected, click Append CA Certificate.
Figure 187. Appending the Enterprise CA Root Certificate to Expressway-C Trusted CA Trust Store
NOTE: The issuer information for the default temporary trusted CA certificate above may be different on your system.
Cisco dCloud
28. You should see “File uploaded”, indicating the Enterprise CA root certificate is uploaded and you will see the root CA
certificate (dcloud-AD1-CA) in the trusted CA certificate list.
Figure 188. Enterprise CA Root Certificate Uploaded to Expressway-C dCloud: The Cisco Demo Cloud
29. You need to repeat this step for the Expressway-E server. Navigate to the Expressway-E administrative interface: https://exp-
e-1.dcloud.cisco.com/ and log in as admin with password: dCloud123!.
30. On the Expressway E server, go to the Server certificate page at Maintenance > Security Certificates > Server certificate.
Browse to the CA-signed Expressway-E certificate you downloaded previously (exp-e-1-cert.cer) located at
C:\Users\mcheng\Downloads and upload by clicking the Upload server certificate data button. Bypass the certificate warning
by accepting the new certificate (click ‘I Understand the Risks’, click the Add Exception… button, and then click confirm
Security Exception) to re-connect
31. Return to the Trusted CA certificate page at Maintenance > Security Certificates > Trusted CA certificate. Browse to the
Base 64 encoded Enterprise CA root certificate (dCloud_root_b64.cer) located at C:\Users\mcheng\Downloads and
append/upload by clicking Append CA Certificate.
Confirm that signed server certificates are in place on Expressway servers and review the contents. Before proceeding, confirm
that the signed Expressway server certificates are in place and briefly review the certificate content.
32. Navigate to the Expressway-C administrative interface: https://exp-c-1.dcloud.cisco.com/ and log in as admin with password:
dCloud123!.
33. Return to the Server certificate page at Maintenance > Security Certificates > Server certificate. Under Server certificate
data, you should see that the “currently loaded” certificate expiration date, which should be today’s date since you signed this
server certificate earlier in the lab.
Cisco dCloud
34. Click on the Show (decoded) button to display the certificate details.
Figure 189. Trusted Enterprise CA Signed Expressway-C Server Certificate

NOTE: The serial number, validity dates, and keys above may not match the ones in your certificate.
Cisco dCloud
35. View the issuer information (dcloud-AD1-CA, the Enterprise CA) and certificate attributes subject name (CN) of exp-c-
1.dcloud.cisco.com, organization, unit, country, and state. Confirm you see the certificate Subject Alternative Names (SANs):
exp-c-1.dcloud.cisco.com, and UDT-Encrypted-NullString.dcloud.cisco.com, UDT-Encrypted-LSC.dcloud.cisco.com,
UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com, and UDT-Encrypted-AuthString.dcloud.cisco.com.
36. Browse to the Expressway-E (https://exp-e-1.dcloud.cisco.com/ and log in as admin and password: dCloud123!. Go to the
Server certificate page at Maintenance > Security Certificates > Server certificate. Under Server certificate data, click
Show (decoded) to review the Enterprise CA-signed Expressway-E server certificate.
Figure 190. Trusted Enterprise CA Signed Expressway-E Server Certificate
NOTE: The serial number, validity dates, and keys above may not match the ones in your certificate.
Cisco dCloud
37. See the issuer information (dcloud-AD1-CA, the Enterprise CA) and certificate attributes subject name (CN) of exp-e-
1.dcloud.cisco.com, organization, unit, country, and state. Confirm you see the certificate SANs: exp-e-1.dcloud.cisco.com
and dcloud.cisco.com.
Now that the Expressway certificates are in good shape and aligned with best practice recommendations, it is time to configure
Mobile and Remote Access (MRA).
F. Expressway-C Mobile and Remote Access Configuration
In this section, Mobile and Remote Access (MRA) configuration on the Expressway-C starts with enabling mobile and remote
access and configuring a collaboration applications domain. Next, discover the collaboration application servers (Unified CM, IM &
P, and Unity Connection) and then configure a traversal zone to the Expressway-E. Finally, review the automatically configured
traversal zones, search rules, and the HTTP allow/white list.
Enable mobile and remote access on Expressway-C
1. Return to the Expressway-C administrative interface at https://exp-c-1.dcloud.cisco.com/ and log in as admin with password:
dCloud123!.
2. Go to Configuration > Unified Communications > Configuration. Choose Mobile and remote access from the Unified
Communications mode drop down menu.
Figure 191. Enabling Mobile and Remote Access on Expressway-C
Cisco dCloud
3. Disable Single Sign-On support by choosing Off from the drop down menu. Leave all other settings at the defaults and click
Save.
Figure 192. Configuring Mobile and Remote Access on Expressway-C dCloud: The Cisco Demo Cloud
Configure the collaboration applications/services domain
4. Go to the Expressway-C administrative interface at https://exp-c-1.dcloud.cisco.com/ and log in as admin with password:
dCloud123!.
5. Configure a domain to associate to the collaboration applications and services. Navigate to Configuration > Domains and
click New to add a domain.
Cisco dCloud
6. As shown below, on the new Domains page, enter dcloud.cisco.com as the ‘Domain name’, and under supported services
set ‘SIP registration and provisioning on Expressway’ to Off, and ‘SIP registrations and provisioning on Unified CM’ and ‘IM
and Presence Service’ to On. Leave ‘XMPP federation’ set to Off. Click Create domain.
Figure 193. Configuring a Domain for Collaboration Applications on Expressway-C
7. Verify the domain is created on the resulting screen.
Figure 194. Expressway-C dcloud.cisco.com Collaboration Applications Domain
Cisco dCloud
Discover the collaboration application server nodes
Now with a domain to associate to the collaboration services, you are ready to discover the collaboration application server nodes.
8. On the Expressway-C administration interface, return to the Unified Communications configuration page at Configuration >
Unified Communications > Configuration and click Configure IM and Presence Service nodes.
Figure 195. Expressway-C Unified Communications Configuration: IM and Presence Service Nodes
9. Click New. On the next screen, configure the following and then click Add address:
 IM and Presence Service database publisher node: imp1.dcloud.cisco.com
 Username: administrator
 Password: dCloud123!
 TLS verify mode: On
Figure 196. IM and Presence Service Node Discovery on Expressway-C
Cisco dCloud
10. Ensure that the IM and Presence node is successfully discovered as shown below.
Figure 197. IM and Presence Service Node Discovered on Expressway-C

NOTE: The ‘XMPP router: Inactive’ status message will go away once MRA configuration is complete and the traversal zone
between Expressway-C and Expressway-E is configured.
11. Go to Configuration > Unified Communications > Configuration and click Configure Unified CM servers.
Figure 198. Expressway-C Unified Communications Configuration: Unified CM Servers
Cisco dCloud
12. Click New. On the next screen, configure the following and click Add address:
 Unified CM publisher address: ucm1.dcloud.cisco.com

Figure 199. Unified CM Server Discovery on Expressway-C
13. Ensure that the Unified CM server is successfully discovered as shown below.
Figure 200. Unified CM Server Discovered on Expressway-C
Cisco dCloud
14. Finally, discover the Unity Connection voicemail server. Return to the Unified Communications configuration page at
Configuration > Unified Communications > Configuration and click Configure Unity Connection servers.
Figure 201. Expressway-C Unified Communications Configuration: Unity Connection Server dCloud: The Cisco Demo Cloud
15. Click New. On the next screen, configure the following as shown below and click Add address:
 Unity Connection address: cuc1.dcloud.cisco.com
Figure 202. Unified Connection Server Discovery on Expressway-C
Cisco dCloud
16. Ensure that the Unity Connection server is successfully discovered as shown below.
Figure 203. Unity Server Discovered on Expressway-C

17. Return to the Unified Communications configuration page at Configuration > Unified Communications > Configuration.
Confirm the discovery of the IM and Presence, Unified CM, and Unity Connection service nodes for the MRA deployment.
Figure 204. Unified Communications Configuration with All Service Nodes Discovered
Cisco dCloud
Review default traversal zones and configure a Unified Communications traversal zone to Expressway-E
Now that MRA is configured on Expressway-C, the collaboration application domain is up, and collaboration application nodes are
discovered, you must configure a Unified Communications traversal zone for secure communications with Expressway-E.
18. From the Expressway-C administration interface at https://exp-c-1.dcloud.cisco.com/ go to Configuration > Zones > Zones.
Notice there are several domains that are already configured on the system. The first is a default zone (DefaultZone) which is
created automatically by the system. Additionally, two neighbor zones (CEtcp-ucm1.dcloud.cisco.com, CEtls-
ucm1.dcloud.cisco.com) are automatically created when the Unified CM server is discovered.
Figure 205. Expressway-C Default Zones
19. Next, configure a new traversal zone for communication with the Expressway-E server. Click New to add a new zone.
20. Enter mra-traversal in the ‘Name’ field and choose Unified Communications traversal from the ‘Type’ drop down menu.
Figure 206. Adding a Unified Communications Traversal Zone on Expressway-C
Cisco dCloud
21. Configure the rest of the zone fields as follows (leaving all other fields as default):
 Under Connection credentials:

o Username: admin123
o Password: dCloud123!
 Under SIP:
o Port: 7001
 Under Location:
o Peer 1 address: exp-e-1.dcloud.cisco.com
Figure 207. Configuring the Unified Communications Traversal Zone on Expressway-C
Cisco dCloud
22. Click , to save and create the new Unified Communications traversal zone. After you return to the Zone page,
see that the Unified Communications traversal zone you just created indicates a ‘Failed’ SIP status. This is normal.
dCloud: Once
The Cisco DemoaCloud
Unified Communications traversal zone is configured on Expressway-E, the SIP status will change to ‘Active’.
Review automatic MRA configuration (search rules, and the HTTP white list)
Before moving to Expressway-E MRA configuration, review the Expressway-C default / automatic search rules and HTTP allow list.
23. From the Expressway-C administration interface (https://exp-c-1.dcloud.cisco.com/, go to Configuration > Dial plan > Search
rules. Notice there are several search rules already configured on the system. The first is a default search rule
(LocalZoneMatch) created automatically by the system. In addition, two search rules (CEtcp-ucm1.dcloud.cisco.com and
CEtls-ucm1.dcloud.cisco.com) are automatically created when the Unified CM server is discovered.
Figure 208. Expressway-C Default and Automatic Unified CM Search Rules
In an enterprise production deployment you may need to configure additional search rules to accommodate your environment, but
for the purposes of this lab, use the rules that were automatically created by the system.
NOTE: MRA does not require the use of Search Rules associated with the MRA Traversal Zone. MRA clients include the SIP route
headers in the SIP Register, Invite, message that dictate the SIP path thru Expressway-E and Expressway-C, to Cisco Unified CM.
Expressway-C injects the same route headers in the reverse call flow for calls to MRA endpoints
24. Go to Configuration > Unified Communications > HTTP Allow List > Automatically added rules to review the HTTP
allow rules automatically configured by the system. These control access to the discovered collaboration application nodes.
Figure 209. Expressway-C Default Unified Communications HTTP Allow Rules
Cisco dCloud
These default HTTP allow rules ensure that collaboration flows for MRA connected endpoints are permitted.
Scroll through the list of rules to see if you can identify some familiar collaboration flows. For example:
 You will notice several rules that allow various Unified CM-based UDS (user data services) HTTPS POST and GET
calls on the standard HTTPS ports (443, 8443).
 See if you can locate one or more allow rules related to endpoint configuration download. What port numbers do
these flows use? (Hint: The Unified CM server stores endpoint configuration on the TFTP server)
 Locate the HTTP allow rules for voicemail communications at the bottom of the list. What port number is used for
HTTP allow rules for voice messaging notifications? (Hint: Unity Connection relies on a Comet framework for server
push notifications).
Depending on the deployment and the type of collaboration services being enabled over MRA, additional HTTP allow rules may
need to be manually added. In this lab, the default HTTP allow rules are sufficient.
NOTE: For additional information about Expressway search rules, HTTP white lists, and zones, refer to the Expressway Basic
Configuration Deployment Guide and the Expressway Mobile and Remote Access via Expressway Deployment Guide available at
http://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-
list.html
G. Expressway-E Mobile and Remote Access Configuration
In this section, you complete Mobile and Remote Access (MRA) configuration on the Expressway-E server. You will enable mobile
and remote access, configure a traversal zone to Expressway-C, and review the auto configured traversal zones and search rules.
Enable mobile and remote access on Expressway-E
1. Go to the Expressway-E admin interface https://exp-e-1.dcloud.cisco.com/ and log in as admin with password: dCloud123!.
2. Go to Configuration > Unified Communications > Configuration. Choose Mobile and remote access from the Unified
Communications mode drop down menu.
Figure 210. Expressway-E Configuration for Mobile and Remote Access
Cisco dCloud
3. Leave the Single Sign-On and XMPP federation parameters set to Off and click the button.
Review default traversal zones and configure traversal zone to Expressway-E dCloud: The Cisco Demo Cloud
4. Navigate to Configuration > Zones > Zones. Notice that only the DefaultZone is created by default on Expressway-E.
Figure 211. Expressway-E Default zone
5. Use the button to create the Expressway-E’s MRA traversal zone. Call it mra-traversal and choose Type Unified
Communications traversal. Leave the Hop Count at the default value (15).
Figure 212. Creating the Expressway-E MRA traversal zone
Cisco dCloud
6. Once the Unified Communications traversal is selected, the full Zone configuration screen appears as shown below.
Figure 213. Expressway-E Detailed MRA Traversal Configuration

7. The parameters can remain at the defaults except the Connection Credentials and TLS verify subject name. The TLS verify
entry should be set to the CN of the Expressway-C certificate, which is exp-c-1.dcloud.cisco.com. The Connection
Credentials Username and Password should match the credentials on Expressway-C, which are admin123 and dCloud123!
Cisco dCloud
8. In the Connection credentials Username field, type admin123 and then click the link. Create
a entry and populate the username and password fields with admin123 and dCloud123!. Click the The Cisco Demo Cloud
dCloud:
button.
NOTE: If the local authentication database window does not appear when you click “Add/Edit local authentication database”, it is
probably behind the current browser window. Minimize the current window to find the local authentication database configuration
page.
Figure 214. Expressway-E Local Authentication Database Configuration
9. Once the Local authentication database is updated, close the window and click the Create zone button to complete the mra-
traversal Zone configuration.
Cisco dCloud
10. If Expressway-C and Expressway-E are configured correctly, the traversal zone should now be active. Verify this going to
Configuration > Zones > Zones on either Expressway-C or E and clicking the mra-traversal Zone link. If the configuration is
correct, the status will be Active and the remote peer SIP reachable. See below for an Expressway-C example.
Figure 215. Active MRA Traversal Zone on Expressway-C
NOTE: MRA configuration does not require a Search Rule for the mra-traversal zone. The only default Search Rule on the
Expressway-E is the DefaultZone, which is automatically created by the system. HTTP White Lists are not required or available on
Expressway-E.
Cisco dCloud
H. Assign Unified CM Device Security Profiles for MRA Devices and Confirm Non-Secure & Secure Calling
Now that MRA configuration is in place, you need to configure a device security profile for MRA (outside) devices. After configuring
the secure MRA profile, assign a non-secure device security profile to the previously secured 88x5 desk phone to compare a
standard MRA call with an end-to-end secure MRA call.
Assign a secure encrypted device security profile for MRA connected (“outside”) devices
1. On Workstation 3, use Firefox to go to the Unified CM Administration interface (https://ucm1.dcloud.cisco.com/ccmadmin/).

Log in as administrator with password: dCloud123!.
2. Navigate to System > Security > Phone Security Profile and locate the previously configured encrypted phone security
profiles. To do this; perform a search where” Name” “begins with”, “UDT”, then click Find.
3. Click the phone security profile you will use for the MRA connected Jabber client: UDT-Encrypted-LSC.dcloud.cisco.com
and note that the name of this profile matches one of the SAN entries used on the Expressway-C’s certificate. The profile
enables encryption (Device Security Mode = Encrypted) but the TFTP Encrypted Config checkbox is unchecked since
encrypted TFTP configuration is not supported with MRA-only endpoints. The CAPF settings are irrelevant in this case since
you will not use the CAPF service for an external Jabber endpoint.
Figure 216. UDT-Encrypted-LSC.dcloud.cisco.com Phone Security Profile used for Jabber MRA
Cisco dCloud
4. Next, assign the phone security profile UDT-Encrypted-LSC.dcloud.cisco.com to user koneal’s Jabber client. Navigate to
Device > Phone and click Find to retrieve a list of endpoints on the system. Click the device CSFKONEAL.
5. Scroll down to Protocol Specific Information and under Device Security Profile click UDT-Encrypted-LSC.dcloud.cisco.com.
Figure 217. Assign the UDT-Encrypted-LSC.dcloud.cisco.com Phone Security Profile to CSFKONEAL
6. Click , click Ok, and then click . Click OK to apply the configuration changes.
Assign a non-secure device security profile to the DX endpoint.
7. Navigate to Device > Phone and click the DX desk phone. Under Protocol Specific Information in the Device Security Profile
field, click the non-secure security profile Universal Device Template – Model-independent Security Profile.
Figure 218. Assign a Non Secure Phone Security Profile to the DX
Cisco dCloud
8. Click . Click OK and then click . Click OK to apply the configuration changes. The desk phone will
re-register in non-encrypted phone mode.
NOTE: You are moving one of the previously secure encrypted on-premise endpoints to non-encrypted mode in order to show that
Jabber can still connect securely to the enterprise without end-to-end encryption even though the client may be configured in
encrypted mode.
Next, confirm that the MRA (outside) Jabber client (CSFKONEAL on Workstation 1) can make secure calls. First, verify MRA
connectivity for the “outside” Jabber client. Next, verify a call between the MRA connected Jabber client and a non-secure on-
premise phone to ensure the call is encrypted from the Jabber client to the Expressway-C. Then, verify a call between the MRA
connected Jabber client and a secure on-premise phone to confirm the call is encrypted from end-to-end between the Jabber client
and the on-premise desk phone. Finally, confirm a secure end-to-end encrypted call between the on-premise Jabber client
(CSFMCHENG on Workstation 3) and the “outside” Jabber client.
Verify MRA Connectivity for “outside” Jabber client (CSFKONEAL on Workstation 1)
9. RDP to Workstation 1 (198.18.2.39) as DCLOUD\koneal with password C1sco12345.
10. Start Jabber and log in as koneal with password: C1sco12345.
NOTE: Be patient. It may take as long as a minute for the Jabber client to launch the first time.
Appropriate DNS records are in place in the public (“outside”) DNS to ensure that the Jabber client is able to discover the
Expressway MRA service and connect to enterprise on-premise collaboration services through Expressway-E. The pertinent public
DNS records for this are as follows:
 SRV record: _collab-edge._tls.dcloud.cisco.com > exp-e-1.dcloud.cisco.com
 A record: exp-e-1.dcloud.cisco.com > 198.18.2.152 (“outside” interface)
As the client logs on and just after the phone service connects, an error message is displayed. You can ignore this message. Click
OK to bypass this warning and continue using the Jabber client.
Figure 219. Jabber for Windows Error Message
Cisco dCloud
11. Verify that the Jabber client is using the Expressway MRA solution by inspecting the Connection Status. Navigate to
(Settings) > Help > Show connection status. The Figure below shows the expected status.
Figure 220. MRA Jabber Client’s Connection Status
NOTE: Be patient. It may take some time for the client to connect to Unified CM for voice and video services the first time.
Cisco dCloud
There are several clues on the connection status screen that confirm MRA connectivity. Notice the “Expressway” indication for the
Unified CM connection under Softphone status and the Expressway-E server (exp-e-1.dcloud.cisco.com) connection for Presence.
Finally, you should also see under Directory status that the client is now connected to Unified CM using User Data Services (UDS)
on Unified CM. This indicates an MRA connection because while you have configured corporate LDAP directory as the Jabber
contact source, when Jabber clients connect over MRA, it is forced to use UDS for directory services. Contrast this with the
Directory connection status for the on-premise Jabber client (CSFMCHENG) where the directory source address is the corporate
LDAP server (ad1.dcloud.cisco.com) and the protocol in use is LDAP.
Make a call from MRA connected Jabber (CSFKONEAL on Workstation 1) to the non-secure on-premise DX endpoint and confirm
encryption from the Jabber client to Expressway-C.
12. Search for Charles Holland on the MRA Jabber Client (CSFKONEAL on Workstation 1), open a chat window and click
to place the call and answer on the DX. As the DX no longer has a secure phone security profile, you will not see a lock icon
on either the desk phone or the “outside” Jabber client as end-to-end encryption is not enabled.
NOTE: The MRA leg of the call to between Jabber and Expressway-C is encrypted but the internal leg of the call is not.
Figure 221. Non Secure MRA Call between the MRA Jabber client and the DX
Cisco dCloud
Make a call from the MRA connected Jabber (CSFKONEAL on Workstation 1) to the secure on-premise 88x5 desk phone and
confirm end-to-end encryption
14. Search for Anita Perez on the MRA Jabber Client (CSFKONEAL on Workstation 1). dCloud: The Cisco Demo Cloud
15. Open a chat window and click the button to place the call and answer on the 88x5. Because both the 88x5 and the
“outside” Jabber client have secure phone security profiles, you should see a lock icon on both the desk phone and the
“outside” Jabber client indicating end-to-end encryption is enabled.
Figure 222. Secure MRA Call between the MRA Jabber client and the 88x5
NOTE: Full end-to-end encryption is enabled for this call scenario as evidenced by the lock icons
Cisco dCloud
Make a call from the MRA connected Jabber (CSFKONEAL on Workstation 1) to secure on-premise Jabber Client (CSFMCHENG
on Workstation 3) and confirm end-to-end encryption.
17. Search for Monica Cheng on the MRA Jabber Client (CSFKONEAL on Workstation 1). dCloud: The Cisco Demo Cloud
18. Open a chat window and click to place the call and answer on Monica Cheng’s Jabber Client (CSFMCHENG on
Workstation 3). Both these devices have a phone security profile so full end-to-end encryption is negotiated. If the system
configuration is correct, both Jabber clients will display the lock icon.
Figure 223. Full Encryption between the MRA Jabber client and the Internal Jabber Client
NOTE: Full end-to-end encryption is enabled for this call scenario as evidenced by the lock icons
19. Hang up the call and logoff /close the Jabber application on Workstation 1.
I. Move “Outside” Jabber Client “Inside” and Confirm Secure Calling after CAPF Enrollment
In this final section, you will examine behavior when the remote (“outside”) Jabber client moves into the enterprise and connects
directly to collaboration application services rather than through Expressway mobile and remote access. You will also move the
client back “outside” to confirm end-to-end encrypted calling over MRA still works.
Move the “Outside” Jabber Client on Workstation 1 into the Enterprise
1. If you are not already connected, RDP to Workstation 1 (198.18.2.39) as DCLOUD\koneal with password C1sco12345.
Cisco dCloud
2. On the Desktop, you will see a batch file called Internal Network On (bat).
Figure 224. BAT File on Workstation 1 to Move the Windows Workstation ”Inside” the Enterprise
When run, this batch file enables the “inside” network adapter on Workstation 1 and disables and disconnects the “outside”
network adapter. This means Workstation 1 moves from host address 198.18.2.39 to host address 198.18.133.39.
3. Double-click to run this batch file.
NOTE: When you run this batch file, your current RDP session to Workstation 1 198.18.2.39 will disconnect because the “outside”
network connection has just been disabled. To continue with this exercise, you must reconnect to Workstation 1 by opening a new
RDP session to the “inside” network interface at 198.18.133.39 using the same credentials. A successful RDP connection to the
“inside” interface (198.18.133.39) confirms that Workstation 1 has moved from outside to inside the Enterprise.
CAPF Enroll Jabber Client on Workstation 1
The Jabber client (CSFKONEAL) is already configured for secure mode. Device Security Profile is set to UDT-Encrypted-
LSC.dcloud.cisco.com. However, it does not have an endpoint certificate, so it is unable to connect to Unified CM in secure mode.
Until now, the Jabber client on Workstation 1 was connected over MRA and leveraged the Expressway-C server certificate in order
to achieve end-to-end encryption. Now that the client moved inside the enterprise and is directly connecting to collaboration
applications and services, it can no longer rely on the Expressway-C certificate. In order to connect to Unified CM in secure mode
while inside the enterprise, the Jabber client will need to perform a CAPF enrollment.
Cisco dCloud
4. Start Jabber and log in as koneal with password: C1sco12345. Notice the phone service does not connect as shown below.
Figure 225. Jabber Phone Service Unable to Connect

NOTE: As before, you will need to click OK to bypass the warning message window.
In order for the Jabber client to connect and register to Unified CM in secure mode, it must have a certificate, so you must to set
the client for CAPF enrollment.
5. On Workstation 3, using Firefox, go to the Unified CM Administration interface (https://ucm1.dcloud.cisco.com/ccmadmin/)

and log in as administrator with password: dCloud123!.
6. Navigate to Device > Phone and click the Find button to pull up the list of endpoints. Click Jabber client device CSFKONEAL.
Cisco dCloud
7. On the configuration page, under the Certification Authority Proxy Function (CAPF) Information section; choose
Install/Upgrade from the “Certificate Operation” drop down menu. Next, choose By Authentication String in the
“Authentication Mode” drop down menu and enter 12345 in the “Authentication String” field, as shown in the Figure below.
Figure 226. Configuring Jabber Client for CAPF Enrollment
9. Return to the Jabber client on Workstation 1 (198.18.133.39) and notice that it is now prompting for the CAPF authentication
string. Enter the authentication string 12345, and click OK. The Jabber client completes the CAPF enrollment and the phone
service will successfully connect.
Figure 227. Jabber Client CAPF Enrollment with Authentication String
Cisco dCloud
10. When you performed the CAPF enrollment configuration with authentication string, the Device Security Profile was
automatically changed to a system-generated profile called Cisco Unified Client Services Framework SIP By
Authentication String RSA-20. While this profile does have encryption enabled, you cannot use this profile for MRA
registered endpoints since the profile name is not a SAN in the Expressway-C certificate. For this reason, you need to return
to the Jabber client (CSFKONEAL) configuration page and set the device security profile back to UDT-Encrypted-
LSC.dcloud.cisco.com as shown below.
Figure 228. Jabber (CSFKONEAL): Setting Device Security Profile back to UDT-Encrypted-LSC.dcloud.cisco.com
12. Return to the Jabber client on Workstation 1 (198.18.133.39) and confirm the client has re-registered.
13. Make a test call from the 88x5 to the Jabber client (dial 1074) to confirm encrypted calling is still working now that the client
has an LSC. You should see the lock icon on both the 88x5 and the Jabber client.
14. Hang up the call before proceeding.
Move the “Outside” Jabber Client on Workstation 1 back outside the Enterprise and confirm encrypted calling still works over MRA
15. Now move the Jabber client (CSFKONEAL) back outside and reconnect over MRA to confirm everything is still operating with
CAPF enrolled on the Jabber client.
Cisco dCloud
16. Return to Workstation 1 (198.18.133.39) and find the batch file called External Network On (bat) on the desktop.
Figure 229. BAT File on WKST1 to Move the Windows Workstation ”Outside” the Enterprise
When run, this batch file enables the “outside” network adapter on Workstation 1, and disables and disconnects the “inside”
network adapter. This means the Workstation 1 moves from host address 198.18.133.39 back to host address 198.18.2.39.
17. Double-click to run this batch file.
NOTE: As before, your current RDP session to Workstation 1 (198.18.133.39) will disconnect because the “inside” network
connection is disabled. To continue, you must reconnect to Workstation 1 by opening a new RDP session to the “outside” network
interface at 198.18.2.39 and connecting as DCLOUD\koneal with password: C1sco12345. A successful RDP connection to the
“outside” interface (198.18.2.39) confirms that Workstation 1 has moved back outside the Enterprise.
18. Confirm that the Jabber client (CSFKONEAL) has re-registered and make another test call from 88x5 to the Jabber client (dial
1074) to confirm encrypted calling is still working now that the client has an LSC and is connected over MRA. Once the call
connects, you should see the lock icon on both the 88x5 and the Jabber client.
Cisco dCloud
This concludes the lab.

Lab Guide Cert Security

Uploaded by

Copyright:

Available Formats

Lab Guide Cert Security

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lab Guide Cert Security

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Collaboration Security for the Enterprise Preferred

Last Updated: 15-AUGUST-2017

About This Lab

 About This Solution

 Scenario 1: Cisco Unified Communications Manager and Endpoint Security

 Scenario 2: Collaboration Application Security

● Router, registered and configured for Cisco dCloud ● Cisco AnyConnect

● Cisco 8845 or 8865 Phone

● Cisco DX70 or DX80 running CE code

About This Solution

This lab contains two scenarios. These are:

 Scenario 1: Cisco Unified Communications Manager and Endpoint Security

 Scenario 2: Cisco Collaboration Application Security

As each scenario takes approximately 2 hours to complete.

In summary, the two scenarios available in this lab are:

Figure 1. dCloud Topology

Table 2. Server and Application Credentials and Details

Server Description Host Name (FQDN) IP Address Username Password

Unified CM (Scenario Cisco Unified Communications Manager

Unified CM (Scenario Cisco Unified Communications Manager

Unified CM IM & P IM & Presence 11.5(1)SU2 imp1.dcloud.cisco.com 198.18.133.4 administrator dCloud123!

Unity Connection Unity Connection 11.5(1)SU2 cuc1.dcloud.cisco.com 198.18.133.5 administrator dCloud123!

Expressway-C Expressway 8.9.1 exp-c-1.dcloud.cisco.com 198.18.133.152 admin dCloud123!

Windows 7 Professional SP1 with Jabber

198.18.1.152 (Internal NIC)

Windows 7 Professional SP1 with Jabber 198.18.133.39 (Internal NIC)

User 4-digit Extension /

EXTERNAL / OUTSIDE (may be moved ON-PREMISE / INSIDE)

Scenario 1: Cisco Unified Communications Manager and Endpoint

A. Collaboration Application Certificate Investigation and Tasks

B. Provisioning and Registering On-Premise Hardware Endpoints and Clients

D. Move Unified CM Cluster to Mixed-Mode via CLI (soft e-Token) Method

E. Unified CM CAPF Enrollment for Jabber Client

G. Confirm Secure Calling (Phone to Phone, Jabber to Phone)

A. Collaboration Application Certificate Investigation and Tasks

Examine the existing certificates on Unified CM (cucm1.dcoud.cisco.com)

1. RDP to Workstation 3 (198.18.133.38) with username DCLOUD\mcheng and password: C1sco12345.

Figure 3. Unified CM Certificate List dCloud: The Cisco Demo Cloud

Generate a certificate signing request (CSR) for tomcat

Figure 4. Unified CM Tomcat / Tomcat-trust self-signed certificates

Figure 5. Generate Tomcat CSR

Figure 6. Tomcat CSR dCloud: The Cisco Demo Cloud

Generate a CallManager CSR

Figure 7. Unified CM CallManager / CallManager-trust self-signed certificates

dCloud: The Cisco Demo Cloud

Figure 8. Generate CallManager CSR

Figure 9. CallManager CSR

Downloading the tomcat CSR

Figure 10. Download CSR

Figure 11. Downloading and Opening the tomcat CSR

14. Close the Download CSR window before proceeding.

16. Click on Request a certificate.

Figure 13. Request a Signed Certificate from the Enterprise CA

Figure 14. Enterprise CA Advanced Certificate Request

Figure 16. Save the Signed tomcat Certificate

Downloading the CallManager CSR

Figure 17. Download CSR

Figure 19. Copying the CSR Text