Cisco CallManager Security Guide

Transcription

1 Release 4.1(2) Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA Tel: NETS (6387) Fax: Text Part Number:

2 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB s public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. CCSP, the Cisco Square Bridge logo, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iquick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iq Expertise, the iq logo, iq Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0406R) Copyright 2004 Cisco Systems, Inc. All rights reserved.

3 CONTENTS Preface 9 Purpose 10 Audience 10 Organization 11 Related Documentation 12 Conventions 13 Obtaining Documentation 13 Cisco.com 13 Ordering Documentation 14 Documentation Feedback 14 Obtaining Technical Assistance 14 Cisco Technical Support Website 15 Submitting a Service Request 15 Definitions of Service Request Severity 16 Obtaining Additional Publications and Information CHAPTER 1 Security Overview 1 Authentication and Encryption Terminology 2 System Requirements 4 Interactions and Restrictions 5 Installation 13 Certificate Types 14 Authentication and Integrity Overview 16 3

4 Contents Encryption Overview 18 Configuration Checklist Overview 20 Where to Find More Information 24 CHAPTER 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) 1 HTTPS Overview 1 Using Internet Explorer with HTTPS 3 Using Internet Explorer to Save the Certificate to the Trusted Folder 5 Viewing Details of the Certificate 6 Copying the Certificate to File 7 Using Netscape with HTTPS 8 Using Netscape To Save the Certificate to the Trusted Folder 9 Using a Server Authentication Certificate From a Third-Party Certificate Authority 10 CHAPTER 3 Configuring the Cisco CTL Client 1 Cisco CTL Client Overview 2 Cisco CTL Client Configuration Checklist 3 Activating the Cisco CTL Provider Service 5 Activating the Cisco CAPF Service 6 Configuring Ports for the TLS Connection 6 Installing the Cisco CTL Client 8 Upgrading the Cisco CTL Client and Migrating the Cisco CTL File 10 Configuring the Cisco CTL Client 11 Updating the CTL File 16 Updating the Clusterwide Security Mode 18 4

5 Contents Cisco CTL Client Configuration Settings 19 Deleting a CTL File Entry 22 CHAPTER 4 Using the Certificate Authority Proxy Function 1 Certificate Authority Proxy Function Overview 2 Cisco IP Phone and CAPF Interaction 3 CAPF System Interactions and Requirements 3 Configuring CAPF in Cisco CallManager Serviceability 5 Migrating Existing CAPF Data 6 CAPF Configuration Checklist 7 Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server 9 Activating the Certificate Authority Proxy Function Service 10 Updating CAPF Service Parameters 11 CAPF Service Parameters 12 Updating CAPF Enterprise Parameters 14 Installing/Upgrading the Locally Significant Certificates 15 Deleting the Locally Significant Certificate 16 CAPF Settings in the Phone Configuration Window 18 Using CAPF with the Bulk Administration Tool 21 Generating a CAPF Report 21 Finding Phones by Choosing the LSC Status 22 Entering the Authentication String on the Phone 22 CHAPTER 5 Configuring the Phones for Security 1 Phone Configuration Overview for Security 2 Installing, Upgrading, Deleting, or Troubleshooting Locally Significant Certificates in Phones 2 5

6 Contents Configuring the Device Security Mode 3 Configuring the Security Device System Default for Supported Phone Models 4 Configuring the Device Security Mode for a Single Device 5 Using the Cisco Bulk Administration Tool to Configure the Device Security Mode 6 Device Security Mode Configuration Settings 7 Finding Phones for Authentication, Encryption, and LSC Status 8 Phone Hardening 9 Performing Phone Hardening Tasks 11 CHAPTER 6 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference 1 Overview for Securing the SRST 1 Secure SRST Configuration Checklist 3 Configuring Secure SRST References 4 Security Configuration Settings for SRST References 6 CHAPTER 7 Troubleshooting 1 Using Alarms 2 Using Microsoft Performance Monitor Counters 3 Reviewing the Log Files 3 Troubleshooting HTTPS 4 Messages That Displays During HTTPS Configuration 5 Enabling HTTPS 6 Disabling HTTPS for the Virtual Directory 7 Deleting the HTTPS Certificate 8 Troubleshooting the Cisco CTL Client 8 Changing the Security Token Password (Etoken) 9 6

7 Contents Troubleshooting a Locked Security Token After You Consecutively Enter an Incorrect Security Token Password 10 Setting the Smart Card Service to Started and Automatic 11 Messages for the Cisco CTL Client 12 Troubleshooting the Phone When a Problem Exists with the CTL File 25 Comparing CTL File Versions on the Cisco IP Phone and Server 27 Deleting the CTL File on the Cisco IP Phone 28 Deleting the CTL File on the Server 29 Troubleshooting If You Lose One Security Token (Etoken) 31 Troubleshooting If You Lose All Security Tokens (Etoken) 32 Verifying the Security Mode for the Cisco CallManager Cluster 33 Verifying or Uninstalling the Cisco CTL Client 34 Determining the Cisco CTL Client Version 35 Troubleshooting CAPF 35 Messages for CAPF 36 Troubleshooting the Authentication String on the Phone 37 Troubleshooting If the Locally Significant Certificate Validation Fails 38 Verifying That the CAPF Certificate Installed on All Servers in the Cluster 38 Verifying That a Locally Significant Certificate Exists on the Phone 39 Verifying That a Manufactured-Installed Certificate (MIC) Exists in the Phone 40 Troubleshooting Encryption 40 SRTP/SCCP Troubleshooting Overview 41 Configuration Checklist for Packet Capturing 42 Configuring Packet Capturing Service Parameters 43 Packet Capturing Service Parameters 44 Configuring BAT for Packet Capturing 45 7

8 Contents Configuring Packet Capturing in the Phone Configuration Window 45 Packet Capturing Phone Configuration Settings 47 Analyzing Captured Packets 48 Messages for Packet Capturing in Cisco CallManager Administration 49 Message for Encryption and Barge Configuration 49 Troubleshooting Secure SRST References 50 Deleting Security from the SRST Reference 50 Security Message That Displays During SRST Reference Configuration 51 Troubleshooting When the SRST Certificate Is Deleted From the Gateway 51 I NDEX 8

9 Preface This preface describes the purpose, audience, organization, and conventions of this guide and provides information on how to obtain related documentation. The preface covers these topics: Purpose, page 10 Audience, page 10 Organization, page 11 Related Documentation, page 12 Conventions, page 13 Obtaining Documentation, page 13 9

10 Purpose Preface Purpose helps system and phone administrators perform the following tasks: Configure authentication. Configure encryption. Install server authentication certificate that is associated with HTTPS. Configure Certificate Authority Proxy Function (CAPF) to install, upgrade, or delete locally significant certificates on supported Cisco IP Phone models. Configure phone hardening. Configure Survivable Remote Site Telephony (SRST) references for security. Troubleshoot issues. Audience This guide provides a reference and procedural guide for system and phone administrators who plan to configure the security features. 10

11 Preface Organization Organization Table 1 lists the major sections of this guide: Table 1 Guide Overview Chapter Chapter 1, Security Overview Chapter 2, Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Chapter 3, Configuring the Cisco CTL Client Chapter 4, Using the Certificate Authority Proxy Function Chapter 5, Configuring the Phones for Security Chapter 6, Configuring a Secure Survivable Remote Site Telephony (SRST) Reference Chapter 7, Troubleshooting Description Provides an overview of security terminology, system requirements, interactions and restrictions, installation requirements, and a configuration checklist; describes the different types of authentication and encryption. Provides an overview of HTTPS and describes how to install the server authentication certificate in the trusted folder. Describes how to configure authentication by installing and configuring the Cisco CTL client. Provides an overview of Certificate Authority Proxy Function and describes how to install, upgrade, delete, or troubleshoot locally significant certificates on supported phones. Describes how to configure the Device Security Mode for supported phones; describes how to disable some phone settings in Cisco CallManager Administration to tighten security. Describes how to configure the SRST reference for security in Cisco CallManager Administration. Describes how to resolve some issues that are associated with security. 11

12 Related Documentation Preface Related Documentation Refer to the following documents for further information about related Cisco IP telephony applications and products: Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Models 7960G and 7940G Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Model 7970G Cisco IP Phone Administrator Guide for Cisco CallManager Models 7902G, 7905G, and 7912G The firmware release notes that support your phone model Cisco IP Telephony Solution Reference Network Design Guide Security application notes for topics, such as toll fraud, operating system hardening, TCP/UDP ports, and so on Cisco Security Agent documentation that is compatible with the version of Cisco CallManager 4.1 that is installed in the cluster Readme documentation for Cisco-provided operating system upgrades and service releases that post to cisco.com Cisco CallManager Administration documentation for Cisco MultiLevel Administration, toll fraud prevention, and SSL usage for directory applications Media and Signaling Authentication and Encryption Feature for Cisco IOS MGCP Gateways Configuring IPSEC from Cisco CallManager to MGCP Gateways Cisco Survivable Remote Site Telephony (SRST) administration documentation that supports the SRST-enabled gateway 12

13 Preface Conventions Conventions Notes use the following conventions: Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the publication. Tips use the following conventions: Tip Means the following are useful tips. Cautions use the following conventions: Caution Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data. Obtaining Documentation Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems. Cisco.com You can access the most current Cisco documentation at this URL: You can access the Cisco website at this URL: You can access international Cisco websites at this URL: 13

14 Documentation Feedback Preface Ordering Documentation You can find instructions for ordering documentation at this URL: You can order Cisco documentation in these ways: Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool: Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at or, elsewhere in North America, by calling NETS (6387). Documentation Feedback You can send comments about technical documentation to bug-doc@cisco.com. You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address: Cisco Systems, Inc. Attn: Customer Document Ordering 170 West Tasman Drive San Jose, CA We appreciate your comments. Obtaining Technical Assistance For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller. 14

15 Preface Obtaining Technical Assistance Cisco Technical Support Website The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year at this URL: Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL: Submitting a Service Request Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool automatically provides recommended solutions. If your issue is not resolved using the recommended resources, your service request will be assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL: For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly. To open a service request by telephone, use one of the following numbers: Asia-Pacific: (Australia: ) EMEA: USA: For a complete list of Cisco TAC contacts, go to this URL: 15

16 Obtaining Additional Publications and Information Preface Definitions of Service Request Severity To ensure that all service requests are reported in a standard format, Cisco has established severity definitions. Severity 1 (S1) Your network is down, or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation. Severity 2 (S2) Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation. Severity 3 (S3) Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels. Severity 4 (S4) You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations. Obtaining Additional Publications and Information Information about Cisco products, technologies, and network solutions is available from various online and printed sources. Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL: The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL: 16

17 Preface Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL: Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL: iq Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iq Magazine at this URL: Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL: World-class networking training is available from Cisco. You can view current offerings at this URL: 17

18 Preface 18

19 CHAPTER 1 Security Overview Implementing authentication and encryption in the Cisco CallManager system prevents identity theft of the phone/cisco CallManager server, data tampering, and call-signaling/media-stream tampering. To prevent these threats, the Cisco IP telephony network establishes and maintains authenticated communication streams, digitally signs files before the file is transferred to the phone, and encrypts media streams and call signaling between Cisco IP Phones. This chapter provides information on the following topics: Authentication and Encryption Terminology, page 1-2 System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Best Practices, page 1-10 Resetting Devices, Restarting Services, or Rebooting the Server/Cluster, page 1-12 Installation, page 1-13 Certificate Types, page 1-14 Authentication and Integrity Overview, page 1-16 Encryption Overview, page 1-18 Configuration Checklist Overview, page 1-20 Where to Find More Information, page

20 Authentication and Encryption Terminology Chapter 1 Security Overview Authentication and Encryption Terminology The definitions in Table 1-1 apply when you configure authentication and encryption for your Cisco IP telephony network: Table 1-1 Terminology Term Authentication Certificate Authority (CA) Certificate Authority Proxy Function (CAPF) Definition Process that verifies the identity of an entity. Entity that issues certificates; may be a Cisco or third-party entity. Process whereby supported devices can request locally significant certificates by using Cisco CallManager Administration. Certificate Trust List (CTL) List that Cisco IP Phones use; a file that you create after you install and configure the Cisco CTL client in the Cisco CallManager cluster; contains a predefined list of trusted items that the Cisco Site Administrator Security Token (security token) signs; provides authentication information to validate the certificates for servers and security tokens for Cisco IP Phones. Cisco Site Administrator Security Token (security token; etoken) Device Authentication Encryption A portable hardware security module that contains a private key and an X.509v3 certificate that the Cisco Certificate Authority signs; used for file authentication, it signs the CTL file and retrieves the private key of the certificate. Process that validates the identity of the device and ensures that the entity is what it claims to be. Process that ensures that only the intended recipient receives and reads the data; process that ensures the confidentiality of the information; process that translates data into ciphertext, which appears random and meaningless. 1-2

21 Chapter 1 Security Overview Authentication and Encryption Terminology Table 1-1 Terminology (continued) Term File Authentication Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Image Authentication Integrity Locally Significant Certificate (LSC) Manufacture Installed Certificate (MIC) Definition Process that validates digitally signed files that the phone downloads. The phone validates the signature to make sure that file tampering did not occur after the file creation. And IETF-defined protocol that ensures (at a minimum) the identity of the HTTPS server; by using encryption, ensures the confidentiality of the information that is exchanged between the IIS server and the browser client. Process that prevents tampering with the binary image prior to loading it on the phone; process whereby a phone validates the integrity and source of an image. Process that ensures that data tampering has not occurred between entities. A digital X.509v3 certificate that is installed on the phone; issued by a third-party certificate authority or CAPF. A digital X.509v3 certificate that is signed by the Cisco Certificate Authority and installed in supported phones by Cisco manufacturing. Man-in-the-Middle Attacks Process that allows an attacker to observe and modify the information flow between Cisco CallManager and the phone. Media Encryption Process whereby the confidentiality of the media occurs by using cryptographic procedures. Media encryption uses Secure Real Time Protocol (SRTP) as defined in IETF RFC Mixed Mode Mode within a cluster that you configured for security; includes authenticated and nonauthenticated devices that connect to the Cisco CallManager. 1-3

22 System Requirements Chapter 1 Security Overview Table 1-1 Terminology (continued) Term Nonsecure Call Secure Call Signaling Authentication Signaling Encryption Secure Survivable Remote Site Telephony (SRST) References Transport Layer Security (TLS) Definition Call in which at least one device is not authenticated or encrypted. Call in which all devices are authenticated, and the media stream is encrypted. Process that validates that no tampering has occurred to signaling packets during transmission; uses the Transport Layer Security protocol. Process that uses cryptographic methods to protect the confidentiality of all SCCP signaling messages that are sent between the device and the Cisco CallManager server. Gateways, which authenticate to secure phones, that perform limited call-processing tasks if the Cisco CallManager cannot perform the tasks. A security protocol that is defined by IETF and that provides integrity, authentication, and encryption and resides in the TCP layer in the IP communications stack. System Requirements The following system requirements exist for authentication or encryption: Cisco CallManager 4.1(2) serves as the minimum requirement for each server in the cluster. Cisco-provided operating system version (or later) serves as the minimum requirement for each server in the cluster. Verify that you have installed the latest operating system service release that goes with operating system (or later). Before you install the Cisco CTL client, verify that the workstation or server runs Windows 2000 sp3a (or later). 1-4

23 Chapter 1 Security Overview Interactions and Restrictions The same Windows administrator username and password must exist on each server in the cluster. For Certificate Authority Proxy Function (CAPF) information, see the CAPF System Interactions and Requirements section on page 4-3. Interactions and Restrictions, page 1-5 Installation, page 1-13 Configuration Checklist Overview, page 1-20 Troubleshooting, page 7-1 CAPF System Interactions and Requirements, page 4-3 Interactions and Restrictions This section contains information on the following topics: Interaction Between Cisco CallManager and the Cisco IP Phone, page 1-5 Security Menu and Icons on Supported Phones, page 1-7 Restrictions, page 1-7 Best Practices, page 1-10 Resetting Devices, Restarting Services, or Rebooting the Server/Cluster, page 1-12 Interaction Between Cisco CallManager and the Cisco IP Phone When you perform a new installation of Cisco CallManager, the Cisco CallManager cluster boots up in nonsecure mode; when the phones boot up after the Cisco CallManager installation, all devices register as nonsecure with Cisco CallManager. After you upgrade from Cisco CallManager 4.0(1) or a later release, the phones boot up in the security mode that you enabled prior to the upgrade; all devices register by using the chosen security mode. The Cisco CallManager installation creates a self-signed certificate on corresponding Cisco CallManager and TFTP servers. After you configure the cluster for authentication, Cisco CallManager uses this self-signed certificate to 1-5

24 Interactions and Restrictions Chapter 1 Security Overview authenticate with supported Cisco IP Phones. After a self-signed certificate exists on the Cisco CallManager and TFTP servers, Cisco CallManager does not reissue the certificates during each Cisco CallManager upgrade. Tip For information on unsupported or nonsecure scenarios, see the Restrictions section on page 1-7. Cisco CallManager maintains the authentication and encryption status at the device level. If all devices that are involved in the call register as secure, the call status registers as secure. If one of the devices registers as nonsecure, the call registers as nonsecure, even if the phone of the caller or recipient registers as secure. Cisco CallManager retains the authentication and encryption status of the device when a user uses Cisco CallManager Extension Mobility. Cisco CallManager also retains the authentication and encryption status of the device when shared lines are configured. Note The features in this document support a limited list of Cisco IP Phone models. For the latest list of supported phones, refer to the phone administration documentation that supports Cisco CallManager 4.1(2). Table 1-2 provides a list of supported features on various Cisco IP Phones. Table 1-2 Cisco IP Phone Features Cisco IP Phone Model Cisco IP Phone model 7970 Supported Feature Image authentication, file authentication, device authentication, signaling encryption, media encryption, manufacture- installed certificates, factory reset, and phone hardening, such as web server disabling 1-6

25 Chapter 1 Security Overview Interactions and Restrictions Table 1-2 Cisco IP Phone Features (continued) Cisco IP Phone Model Cisco IP Phone models 7960 and 7940 Cisco IP Phone models 7912, 7910, 7905G, and 7902 Supported Feature Image authentication, file authentication, device authentication, signaling encryption, media encryption, locally significant certificates, factory resets, and phone hardening, such as web server disabling Image authentication Security Menu and Icons on Supported Phones You can configure and view certain security-related settings on phones that support security; for example, from supported phones, you can view whether a phone has a locally significant certificate or manufacture-installed certificate installed. For additional information on the security menu and icons, refer to the Cisco IP Phone administration and user documentation that supports your phone model and this version of Cisco CallManager. Likewise, when Cisco CallManager classifies a call as authenticated or encrypted, an icon displays on the phone to indicate the call state. To determine when Cisco CallManager classifies the call as authenticated or encrypted, refer to the Restrictions section on page 1-7. Restrictions Consider the following restrictions before you install and configure the authentication and encryption features: Auto-registration does not work when you configure the cluster for mixed mode, which is required for device authentication. You cannot implement signaling or media encryption if device authentication does not exist in the cluster; that is, if you do not install and configure the Cisco CTL client. If you use a multicluster TFTP configuration, you must configure all Cisco CallManager clusters for the same security mode through the Cisco CTL client. You must install the Cisco CTL client in each cluster and choose the same clusterwide security mode during the configuration. 1-7

26 Interactions and Restrictions Chapter 1 Security Overview Caution Ensure that the TFTP path and alternate TFTP paths for building configuration files are unique; if the paths are not unique, a TFTP server may overwrite the CTL file that the other cluster creates. Cisco does not support Network Address Translation (NAT) with Cisco CallManager if you configure the cluster for mixed mode; Application Layer Gateways (ALG) that allow VOIP to traverse firewalls and NAT do not work with signaling encryption. You can enable UDP ALG in the firewall to allow media stream firewall traversal. Enabling the UDP ALG allows the media source on the trusted side of the firewall to open a bidirectional media flow through the firewall by sending the media packet through the firewall. Tip Hardware DSP resources cannot initiate this type of connection, and, therefore, must exist outside of the firewall. Signaling encryption does not support NAT traversal. Instead of using NAT, consider using LAN extension VPNs. A user cannot barge into an encrypted call if the phone that is used to barge is not configured for encryption. When barge fails in this case, a busy tone plays on the phone where the user initiated the barge. If the initiator phone is configured for encryption, the barge initiator can barge into an authenticated or nonsecure call from the encrypted phone. After the barge occurs, Cisco CallManager classifies the call as nonsecure. If the initiator phone is configured for encryption, the barge initiator can barge into an encrypted call, and the phone indicates that the call state equals encrypted. A user can barge into an authenticated call, even if the phone that is used to barge is nonsecure. The authentication icon continues to display on the authenticated devices in the call, even if the initiator phone does not support security. Use the preceding information in conjunction with the Message for Encryption and Barge Configuration section on page

27 Chapter 1 Security Overview Interactions and Restrictions Tip You can configure cbarge if you want barge functionality, but Cisco CallManager automatically classifies the call as nonsecure. The following information applies for Cisco IP Phone models 7960 or 7940 that are configured for encryption and associated with a wideband codec region. To establish an encrypted call, Cisco CallManager ignores the wideband codec and chooses another supported codec from the codec list that the phone presents. If the other devices in the call are not configured for encryption, Cisco CallManager may establish the authenticated/nonsecure call by using the wideband codec. Cisco CallManager supports authenticated and encrypted calls between secure Cisco IP Phones and secure IOS gateways within a single cluster where no media resources are used. For example, Cisco CallManager 4.1(2) does not provide authentication, integrity, or encryption in the following cases: Computer Telephony Integration (CTI) devices; some gateways; intercluster trunks; transcoders; media termination points Calls that are made over two different clusters Ad hoc or Meet Me conferences Music on Hold Session Initiation Protocol (SIP) and H.323 devices Some Cisco IP Phones models Tip The encryption lock icon indicates that the media stream between the Cisco IP devices is encrypted. The encryption lock icon may not display on the phone when you perform tasks such as conferencing, transferring, or putting a call on hold; the status changes from encrypted to nonsecure if the media streams that are associated with these tasks are not encrypted. 1-9

28 Interactions and Restrictions Chapter 1 Security Overview Tip Do not use Terminal Services to install the Cisco CTL client. Cisco installs Terminal Services, so Cisco Technical Assistance Center (TAC) can perform remote troubleshooting and configuration tasks. Using CAPF may cause high CPU utilization, so do not use VNC when you use CAPF to generate certificates. Best Practices Cisco strongly recommends the following best practices: Always perform installation and configuration tasks in a secure lab environment before you deploy to a wide-scale network. Cisco CallManager 4.1 automatically installs LDAPS (LDAP over SSL) for DC Directory. If you integrate your corporate directory, for example, Microsoft Active Directory or Netscape Server Directory, with Cisco CallManager, you can configure an option to support SSL. For information on how to perform this task, refer to the document, Installing Cisco Customer Directory Configuration Plugin for Cisco CallManager 4.0(1). For a list of Cisco-provided applications that use LDAPS, refer to the Cisco CallManager System Guide. Use the features that are described in this document in conjunction with the latest Cisco-provided operating system service releases and upgrades that are available on cisco.com. Use the features that are described in this document in conjunction with the Cisco Security Agent that supports this release of Cisco CallManager. Use the features that are described in this document with Cisco-approved, third-party security applications; for example, MacAfee antivirus software. Use Windows native mode IPSEC for gateways and other application servers at remote locations; for example, Cisco Unity, or Cisco IP Contact Center (IPCC), or other Cisco CallManager servers. 1-10

29 Chapter 1 Security Overview Interactions and Restrictions Configure IPSEC between Cisco CallManager and secure Cisco IOS MGCP gateways, which include 2600 XM, 2691, 2811, 2821, 2851, 3640A, 3660, 3725, 3745, 38XX series, and VG224. After you perform configuration tasks for Cisco CallManager and the gateway, secure MGCP gateways interact with Cisco CallManager by using Windows 2000 IPSEC, which ensures that the signaling information, for example, DTMF digits, passwords, PINs, encryption keys, and so on, is encrypted when it is sent between the MGCP gateway and Cisco CallManager. All call control and signaling packets between the MGCP gateway and Cisco CallManager go through this secure IPSEC tunnel. Cisco CallManager generates a master encryption key and salt for secure calls and sends them to the gateway for the SRTP stream only. Cisco CallManager does not send the key and salt for SRTCP streams, which the Cisco IOS MGCP gateway supports. Cisco CallManager supports gateways that use the MGCP SRTP package, which the gateway requires to encrypt and decrypt packets over a secure RTP connection. Cisco CallManager creates a SRTP connection to a device, but, if the device does not support SRTP, Cisco CallManager communicates with the gateway to ensure that the call uses a RTP connection. SRTP-to-RTP fallback (and vice versa) may occur for transfers from a secure device to a nonsecure device, for Music-On-Hold, for calls that use non-srtp transcoders, and so on. To configure security between Cisco IOS MGCP gateways and Cisco CallManager, verify that you installed and configured the Cisco CTL client for mixed mode. In Cisco CallManager Administration, verify that you configured the phones for encryption. Next, configure IPSEC between Cisco CallManager and the gateway. For information on how to configure IPSEC, refer to the IPSEC documentation that Microsoft and/or Cisco provides. Finally, perform security-related configuration tasks on the gateway, as described in the document, Media and Signaling Authentication and Encryption Feature for Cisco IOS MGCP Gateways, which you can obtain at the following URL: /123t/123t_11/gtsecure.htm 1-11

30 Interactions and Restrictions Chapter 1 Security Overview To prevent toll fraud, configure conference enhancements that are described in the Cisco CallManager System Guide. Likewise, you can perform configuration tasks to restrict external transferring of calls. For information on how to perform this task, refer to the Cisco CallManager Features & Services Guide. Configure SRST references and SRST-enabled gateways for security. Configure IPSEC from Cisco CallManager to MGCP gateways. Resetting Devices, Restarting Services, or Rebooting the Server/Cluster This section describes when you need to reset the devices, restart services in Cisco CallManager Serviceability, or when to reboot the server/cluster. Consider the following guidelines: Reset a single device after you change the device security mode in Cisco CallManager Administration. Reset the devices if you perform phone-hardening tasks. Reset the devices after you change the clusterwide security mode from mixed to nonsecure mode (or vice versa). Restart all devices after you configure the Cisco CTL client or update the CTL file. Reset dependent devices after you configure secure SRST references. Reset the devices after you update CAPF enterprise parameters. Restart the Cisco CTL Provider service after you update ports for the TLS connection. Restart the Cisco CallManager service after you change the clusterwide security mode from mixed to nonsecure mode (or vice versa). Restart the Cisco Certificate Authority Proxy Function service after you update associated CAPF service parameters. Restart all Cisco CallManager and Cisco TFTP services in Cisco CallManager Serviceability after you configure the Cisco CTL client or update the CTL file. Perform this task on all servers that run these services. Reboot the server where you installed the Cisco CTL client if you set the Smart Card service to Started and Automatic. To restart the Cisco CallManager service, refer to the Cisco CallManager Serviceability Administration Guide. 1-12

31 Chapter 1 Security Overview Installation To reset a single device after updating the configuration, see the Configuring the Device Security Mode for a Single Device section on page 5-5. To reset all devices in the cluster, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 In Cisco CallManager Administration, choose System > Cisco CallManager. In the pane on the left side of the window, choose a server. Click Reset Devices. Perform Step 2 and Step 3 for each server in the cluster. System Requirements, page 1-4 Configuring the Cisco CTL Client, page 3-1 Using the Certificate Authority Proxy Function, page 4-1 Configuration Checklist Overview, page 1-20 Troubleshooting, page 7-1 Installation To obtain authentication support, you install a plug-in, the Cisco CTL client, from Cisco CallManager Administration. You must install the Cisco CTL client on a single Windows 2000 server or workstation that has a USB port. If you choose to do so, you can install the client on a Cisco CallManager server that has a USB port. To install the Cisco CTL client, you must obtain at least two security tokens. Media and signaling encryption automatically install when you install Cisco CallManager. Cisco CallManager automatically installs Secure Sockets Layer (SSL) for Cisco CallManager virtual directories. Cisco Certificate Authority Proxy Function (CAPF) installs automatically as a part of Cisco CallManager Administration. 1-13

32 Certificate Types Chapter 1 Security Overview Configuring the Cisco CTL Client, page 3-1 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), page 2-1 Certificate Types Cisco uses the following certificates types in phones and servers: Manufacture-installed certificate (MIC) Cisco manufacturing automatically installs this certificate in supported phone models. With certain phone models, one MIC and one locally significant certificate can exist in the same phone, in which case, the LSC takes precedence over the MIC for authentication to the Cisco CallManager after you configure the device security mode for authentication or encryption. You cannot overwrite or delete the manufacture-installed certificate. Locally significant certificate (LSC) This certificate type installs on supported phones after you perform the necessary tasks that are associated with the Cisco Certificate Authority Proxy Function (CAPF). With certain phone models, one LSC and one MIC can exist in the same phone, in which case, the LSC takes precedence over the MIC for authentication to the Cisco CallManager after you configure the device security mode for authentication or encryption. CAPF certificate This certificate gets copied to all servers in the cluster after you complete the Cisco CTL client configuration. This certificate installs to C:\Program Files\Cisco\Certificates on each server in the cluster. HTTPS certificate When installed on the IIS web site that hosts the Cisco CallManager SSL-enabled virtual directories, this server authentication certificate, httpscert.cer, provides authentication between the IIS server and the browser client. This certificate installs to C:\Program Files\Cisco\Certificates. Self-signed Cisco CallManager certificate This certificate, ccmserver.cer, automatically installs when you install Cisco CallManager 4.1. The Cisco CallManager self-signed certificates provide server identification, including the Cisco CallManager server name and the Global Unique Identifier (GUID). On each server in the cluster, Cisco CallManager stores 1-14

33 Chapter 1 Security Overview Certificate Types the certificates, which exist in DER format, in C:\Program Files\Cisco\Certificates. Administrators have read-only access to the certificates. SRST certificate in the SRST-enabled gateway This certificate gets added to the Cisco CallManager database after you configure the SRST reference for security and reset the phones. The phone obtains this certificate through the configuration file. This certificate does not exist in the Cisco CTL file. For more information on the SRST certificate in the gateway, refer to the Cisco SRST documentation that supports the gateway. Interactions and Restrictions, page 1-5 Installation, page 1-13 Authentication and Integrity Overview, page 1-16 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), page 2-1 Configuring the Cisco CTL Client, page 3-1 Using the Certificate Authority Proxy Function, page 4-1 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference, page

34 Authentication and Integrity Overview Chapter 1 Security Overview Authentication and Integrity Overview Integrity and authentication protect against the following threats: TFTP file manipulation (integrity) Modification of call-processing signaling between the phone and Cisco CallManager (authentication) Man-in-the-middle attacks (authentication), as defined in Table 1-1 Phone and server identity theft (authentication) Image Authentication This process prevents tampering with the binary image, that is, the firmware load, prior to loading it on the phone. Tampering with the image causes the phone to fail the authentication process and reject the image. Image authentication occurs through signed binary files that are automatically installed when you install Cisco CallManager. Likewise, firmware updates that you download from the web also provide signed binary images. For a list of devices that are supported, see the Interactions and Restrictions section on page 1-5. Device Authentication This process validates the identity of the device and ensures that the entity is who it claims to be; for a list of devices that are supported, see the Interactions and Restrictions section on page 1-5. Device authentication occurs between the Cisco CallManager server and supported Cisco IP Phones when each entity accepts the certificate of the other entity; only then does a secure connection between the entities occur. Device authentication relies on the creation of the Cisco CTL file, as described in Configuring the Cisco CTL Client section on page 3-1. File Authentication This process validates digitally signed files that the phone downloads; for example, the configuration, ring list, locale, and CTL files. The phone validates the signature to verify that file tampering did not occur after the file creation; for a list of devices that are supported, see the Interactions and Restrictions section on page

35 Chapter 1 Security Overview Authentication and Integrity Overview The TFTP server does not sign any files if you configure the cluster for nonsecure mode. If you configure the cluster for mixed mode, the TFTP server signs static files, such as ring list, localized, default.cnf.xml, and ring list wav, files in.sgn format. The TFTP server signs files in <device name>.cnf.xml format every time that the TFTP server verifies that a data change occurred for the file. The TFTP server writes the signed files to disk if caching is disabled. If the TFTP server verifies that a saved file has changed, the TFTP server re-signs the file. The new file on the disk overwrites the saved file that gets deleted. Before the phone can download the new file, the administrator must restart affected devices in Cisco CallManager Administration. After the phone receives the files from the TFTP server, the phone verifies the integrity of the files by validating the signature on the file. For the phone to establish a TLS connection, ensure that the following criteria are met: A certificate must exist in the phone. The CTL file must exist on the phone, and the Cisco CallManager entry and certificate must exist in the file. You configured the device for authentication or encryption. Note File authentication relies on the creation of the Certificate Trust List (CTL) file, which is described in the Configuring the Cisco CTL Client section on page 3-1. Signaling Authentication This process, also known as signaling integrity, uses the TLS protocol to validate that no tampering has occurred to signaling packets during transmission. Signaling authentication relies on the creation of the Certificate Trust List (CTL) file, which is described in the Configuring the Cisco CTL Client section on page 3-1. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Configuring the Cisco CTL Client, page 3-1 Using the Certificate Authority Proxy Function, page

36 Encryption Overview Chapter 1 Security Overview Configuring the Device Security Mode, page 5-3 Troubleshooting, page 7-1 Encryption Overview Tip Encryption installs automatically when you install Cisco CallManager 4.1 on each server in the cluster. For a list of devices that support encryption, see the System Requirements section on page 1-4. The files from the security package install in C:\Program Files\Cisco\bin. Cisco CallManager supports the following types of encryption: Signaling Encryption, page 1-18 Media Encryption, page 1-19 Signaling Encryption Signaling encryption ensures that all SCCP signaling messages that are sent between the device and the Cisco CallManager server are encrypted. Signaling encryption ensures that the information that pertains to the parties, DTMF digits that are entered by the parties, call status, media encryption keys, and so on are protected against unintended or unauthorized access. Cisco does not support Network Address Translation (NAT) with Cisco CallManager if you configure the cluster for mixed mode; Application Layer Gateways (ALG) that allow VOIP to traverse firewalls and NAT do not work with signaling encryption. 1-18

37 Chapter 1 Security Overview Encryption Overview You can enable UDP ALG in the firewall to allow media stream firewall traversal. Enabling the UDP ALG allows the media source on the trusted side of the firewall to open a bidirectional media flow through the firewall by sending the media packet through the firewall. Tip Hardware DSP resources cannot initiate this type of connection, and, therefore, must exist outside of the firewall. Signaling encryption does not support NAT traversal. Instead of using NAT, consider using LAN extension VPNs. Media Encryption Media encryption, which uses SRTP, ensures that only the intended recipient can interpret the media streams between supported devices. Support includes audio streams only. Media encryption includes creating a media master key pair for the devices, delivering the keys to the devices, and securing the delivery of the keys while the keys are in transport. Authentication and signaling encryption serve as the minimum requirements for media encryption; that is, if the devices do not support signaling encryption and authentication, media encryption cannot occur. The following example demonstrates media encryption. 1. Device A and Device B, which support media encryption and authentication, register with Cisco CallManager. 2. When Device A places a call to Device B, Cisco CallManager requests two sets of media session master values from the key manager function. 3. Both devices receive the two sets, one set for the media stream, Device A Device B, and the other set for the media stream, Device B Device A. 4. Using the first set of master values, Device A derives the keys that encrypt and authenticate the media stream, Device A Device B. 5. Using the second set of master values, Device A derives the keys that authenticate and decrypt the media stream, Device B Device A. 6. Device B uses these sets in the inverse operational sequence. 7. After the devices receive the keys, the devices perform the required key derivation, and SRTP packet processing occurs. 1-19

38 Configuration Checklist Overview Chapter 1 Security Overview Tip For a list of supported items, see the Interactions and Restrictions section on page 1-5. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Configuring the Device Security Mode, page 5-3 Troubleshooting, page 7-1 Configuration Checklist Overview Table 1-3 describes tasks that you must perform to implement authentication and encryption. Additionally, chapters may contain a checklist for the tasks that you must perform for the specified security feature. Table 1-3 Configuration Checklist for Authentication and Encryption Configuration Steps Step 1 On each server in the cluster, activate the Cisco CTL Provider service in Cisco CallManager Serviceability. Tip If you activated this service prior to a Cisco CallManager upgrade, you do not need to activate the service again. The service automatically activates after the upgrade. Related Procedures and Topics Activating the Cisco CTL Provider Service, page

39 Chapter 1 Security Overview Configuration Checklist Overview Table 1-3 Configuration Checklist for Authentication and Encryption (continued) Configuration Steps Step 2 On the publisher database server, activate the Cisco Certificate Authority Proxy service in Cisco CallManager Serviceability to install, upgrade, troubleshoot, or delete locally significant certificates. Step 3 Step 4 Step 5 Timesaver Performing this task before you install and configure the Cisco CTL client ensures that you do not have to update the CTL file to use CAPF. If you do not want to use the default settings, configure ports for the TLS connection. Tip If you configured these settings prior to a Cisco CallManager upgrade, the settings migrate automatically during the upgrade. Obtain at least two security tokens and the passwords, hostnames/ip addresses, and port numbers for the servers that you will configure for the Cisco CTL client. Install the Cisco CTL client. Tip You cannot use the Cisco CTL client that was available with Cisco CallManager 4.0. To update the Cisco CTL file after an upgrade to Cisco CallManager 4.1, you must install the plugin that is available in Cisco CallManager Administration 4.1. If you do not need to make changes to the file, you do not need to install the 4.1 client version. Related Procedures and Topics Activating the Certificate Authority Proxy Function Service, page 4-10 Configuring Ports for the TLS Connection, page 3-6 Configuring the Cisco CTL Client, page 3-11 System Requirements, page 1-4 Installation, page 1-13 Installing the Cisco CTL Client, page

40 Configuration Checklist Overview Chapter 1 Security Overview Table 1-3 Configuration Checklist for Authentication and Encryption (continued) Configuration Steps Step 6 Configure the Cisco CTL client. Tip If you created the Cisco CTL file prior to a Cisco CallManager upgrade, the Cisco CTL file migrates automatically during the upgrade. To update the Cisco CTL file after an upgrade to Cisco CallManager 4.1, you must install and configure the 4.1 version of the Cisco CTL client. Step 7 Configure CAPF to issue certificates. If you performed certificate operations before the upgrade to Cisco CallManager 4.1 and CAPF ran on a subscriber server, you must copy the CAPF data to the 4.0 publisher database server before you upgrade the cluster to Cisco CallManager 4.1. Related Procedures and Topics Configuring the Cisco CTL Client, page 3-11 System Requirements, page 1-4 CAPF Configuration Checklist, page 4-7 Migrating Existing CAPF Data, page 4-6 Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server, page 4-9 Caution The CAPF data on the Cisco CallManager 4.0 subscriber server does not migrate to the Cisco CallManager 4.1 database, and a loss of data occurs if you do not copy the data to the 4.1 publisher database. If a loss of data occurs, the locally significant certificates that you issued with CAPF utility 1.0(1) remain in the phones, but CAPF 4.1(2) must reissue the certificate, which is not valid. 1-22

41 Chapter 1 Security Overview Configuration Checklist Overview Table 1-3 Configuration Checklist for Authentication and Encryption (continued) Configuration Steps Step 8 Verify that the locally significant certificates installed on supported Cisco IP Phones. Step 9 Step 10 Step 11 Step 12 Configure supported devices for authentication or encryption. Tip The device configuration migrates automatically during the Cisco CallManager upgrade. If you want to configure encryption for devices that only supported authentication in Cisco CallManager 4.0, you must update the Device Security Mode in the Phone Configuration window in Cisco CallManager Administration. Configure security settings for SRST references. Tip This feature supports Cisco CallManager 4.1(1) or later. Perform phone-hardening tasks. Tip If you configured phone-hardening settings prior to a Cisco CallManager upgrade, the device configuration settings migrate automatically during the upgrade. Configure IPSEC between Cisco CallManager and secure Cisco IOS MGCP gateways. Related Procedures and Topics System Requirements, page 1-4 Entering the Authentication String on the Phone, page 4-22 Verifying That a Locally Significant Certificate Exists on the Phone, page 7-39 Configuring the Device Security Mode, page 5-3 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference, page 6-1 Performing Phone Hardening Tasks, page 5-11 Best Practices, page

42 Where to Find More Information Chapter 1 Security Overview Table 1-3 Configuration Checklist for Authentication and Encryption (continued) Configuration Steps Related Procedures and Topics Step 13 Reset all phones in the cluster. Resetting Devices, Restarting Services, or Rebooting the Server/Cluster, page 1-12 Step 14 Reboot all servers in the cluster. Resetting Devices, Restarting Services, or Rebooting the Server/Cluster, page 1-12 Where to Find More Information Related Cisco Documentation Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Models 7960G and 7940G Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Model 7970G Cisco IP Phone Administrator Guide for Cisco CallManager Models 7902G, 7905G, and 7912G The firmware release notes that support your phone model Cisco IP Telephony Solution Reference Network Design Guide Security application notes for topics, such as toll fraud, operating system hardening, TCP/UDP ports, and so on Cisco Security Agent documentation that is compatible with the version of Cisco CallManager 4.1 that is installed in the cluster Readme documentation for Cisco-provided operating system upgrades and service releases that post to cisco.com Cisco CallManager Administration documentation for Cisco MultiLevel Administration, toll fraud prevention, and SSL usage for directory applications Media and Signaling Authentication and Encryption Feature for Cisco IOS MGCP Gateways Configuring IPSEC from Cisco CallManager to MGCP Gateways Cisco Survivable Remote Site Telephony (SRST) administration documentation that supports the SRST-enabled gateway 1-24

43 CHAPTER 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) This chapter contains information on the following topics: HTTPS Overview, page 2-1 Using Internet Explorer to Save the Certificate to the Trusted Folder, page 2-5 Viewing Details of the Certificate, page 2-6 Copying the Certificate to File, page 2-7 Using Netscape To Save the Certificate to the Trusted Folder, page 2-9 Using a Server Authentication Certificate From a Third-Party Certificate Authority, page 2-10 HTTPS Overview Hypertext Transfer Protocol over Secure Sockets Layer (SSL), which secures communication between the browser client and the IIS server, uses a certificate and a public key to encrypt the data that is transferred over the internet. HTTPS also ensures that the user login password transports securely via the web. The following Cisco CallManager applications support HTTPS, which ensures the identity of the server: Cisco CallManager Administration, Cisco CallManager Serviceability, the Cisco IP Phone User Option Pages, the Bulk Administration Tool (BAT), TAPS, Cisco CDR Analysis and Reporting (CAR), Trace Collection Tool, and the Real Time Monitoring Tool. 2-1

44 HTTPS Overview Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) When you install/upgrade Cisco CallManager, the HTTPS self-signed certificate, httpscert.cer, automatically installs on the IIS default website that hosts the Cisco CallManager virtual directories in Table 2-1: Table 2-1 Cisco CallManager Virtual Directories Cisco CallManager Virtual Directory CCMAdmin CCMService CCMUser AST RTMTReports CCMTraceAnalysis PktCap ART CCMServiceTraceCollecti ontool BAT TAPS Corresponding Application Cisco CallManager Administration Cisco CallManager Serviceability Cisco IP Phone User Option Pages Real-Time Monitoring Tool (RTMT) RTMT reports archive Trace Analysis Tool Troubleshooting tools Note These troubleshooting tools use the virtual directory to get the trace files that contain the SCCP signaling packet traces. Cisco CDR Analysis and Reporting (CAR) Trace Collection Tool Bulk Administration Tool (BAT) Tool for Auto-Registered Phones Support (TAPS) The HTTPS certificate gets stored in the C:\Program Files\Cisco\Certificates directory. If you prefer to do so, you can install a server authentication certificate from a certificate authority and use it instead of the HTTPS self-signed certificate. To use the certificate authority certificate after the Cisco CallManager installation/upgrade, you must delete the self-signed certificate, as described in the Troubleshooting section on page 7-1. Then, you install the server authentication certificate that is provided by the certificate authority, as described in the certificate authority documentation. 2-2

45 Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Using Internet Explorer with HTTPS Note If you access the web application by using the hostname and install the certificate in the trusted folder and then try to access the application by using the localhost or IP address, the Security Alert dialog box displays to indicate that the name of the security certificate does not match the name of the site. If you use the localhost, the IP address, or the hostname in the URL to access the application that supports HTTPS, you must save the certificate in the trusted folder for each of type of URL (with the local host, IP address, and so on); otherwise, the Security Alert dialog box displays for each type. Cisco CallManager Administration Guide Cisco CallManager System Guide Bulk Administration Tool User Guide Cisco CallManager Serviceability Administration Guide Cisco CallManager Serviceability System Guide Customizing Your Cisco IP Phone on the Web Using Internet Explorer to Save the Certificate to the Trusted Folder, page 2-5 Viewing Details of the Certificate, page 2-6 Copying the Certificate to File, page 2-7 Using Internet Explorer with HTTPS This section provides details on the following topics that are associated with using HTTPS with Internet Explorer: Using Internet Explorer to Save the Certificate to the Trusted Folder, page 2-5 Viewing Details of the Certificate, page 2-6 Copying the Certificate to File, page

46 Chapter 2 Using Internet Explorer with HTTPS Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) The first time that you (or a user) accesses Cisco CallManager Administration or other Cisco CallManager SSL-enabled virtual directories after the Cisco CallManager 4.1 installation/upgrade from a browser client, a Security Alert dialog box asks whether you trust the server. When the dialog box displays, you must perform one of the following tasks: By clicking Yes, you choose to trust the certificate for the current web session only. If you trust the certificate for the current session only, the Security Alert dialog box displays each time that you access the application; that is, until you install the certificate in the trusted folder. By clicking View Certificate > Install Certificate, you intend to perform certificate installation tasks, so you always trust the certificate. If you install the certificate in the trusted folder, the Security Alert dialog box does not display each time that you access the web application. By clicking No, you cancel the action. No authentication occurs, and you cannot access the web application. To access the web application, you must click Yes or install the certificate via the View Certificate > Install Certificate options. HTTPS Overview, page 2-1 Using Internet Explorer to Save the Certificate to the Trusted Folder, page 2-5 Viewing Details of the Certificate, page 2-6 Copying the Certificate to File, page 2-7 Troubleshooting HTTPS, page

47 Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Using Internet Explorer with HTTPS Using Internet Explorer to Save the Certificate to the Trusted Folder To save the HTTPS certificate in the trusted folder on the browser client so the Security Alert dialog box does not display each time that you access the web application, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Browse to the application on the IIS server. When the Security Alert dialog box displays, click View Certificate. In the Certificate pane, click Install Certificate. Click Next. Click the Place all certificates in the following store radio button; click Browse. Browse to Trusted Root Certification Authorities. Click Next. Click Finish. To install the certificate, click Yes. A message states that the import was successful.click OK. In the lower, right corner of the dialog box, click OK. To trust the certificate so you do not receive the dialog box again, click Yes. Note If you use the localhost, the IP address, or the hostname in the URL to access the application that supports HTTPS, you must save the certificate in the trusted folder for each of type of URL (with the local host, IP address, and so on); otherwise, the Security Alert dialog box displays for each type. 2-5

48 Chapter 2 Using Internet Explorer with HTTPS Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) HTTPS Overview, page 2-1 Viewing Details of the Certificate, page 2-6 Copying the Certificate to File, page 2-7 Viewing Details of the Certificate To view the details of the certificate, perform one of the following tasks: Click the View Certificate button and then the Details tab. On the server where the certificate exists, right-click the certificate in C:\Program Files\Cisco\Certificates\httpscert.cer; click Open. Tip You cannot change any data that displays for the settings in the pane. For descriptive information on the following settings, refer to Microsoft documentation. The following certificate settings may display: Version Serial Number Signature Algorithm Issuer Valid From Valid To Subject Public key Subject Key Installer Key Usage Enhanced Key Usage Thumbprint Algorithm Thumbprint 2-6

49 Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Using Internet Explorer with HTTPS To display a subset of settings, if available, choose one of the following options: All All options display in the Details pane. Version 1 Fields Only Version, Serial Number, Signature Algorithm, Issuer, Valid From, Valid To, Subject, and the Public Key options display. Extensions Only Subject Key Identifier, Key Usage, and the Enhanced Key Usage options display. Critical Extensions Only Critical Extensions, if any Properties Only Thumbprint algorithm and the thumbprint options display. HTTPS Overview, page 2-1 Using Internet Explorer to Save the Certificate to the Trusted Folder, page 2-5 Copying the Certificate to File, page 2-7 Copying the Certificate to File Copying the certificate to file allows you to restore the certificate whenever necessary. You can also use the following procedure to install a certificate file that another user sends you. Performing the following procedure copies the certificate by using a standard certificate storage format. To copy the certificate contents to file, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 In the Security Alert dialog box, click View Certificate. Click the Details tab. Click the Copy to File button. The Welcome Wizard displays. Click Next. The following list defines the file formats from which you can choose. Choose the file format that you want to use to export the file; click Next. 2-7

50 Using Netscape with HTTPS Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) DER encoded binary X.509 (.CER) Uses DER to transfer information between entities. Base-64 encoded X.509 (.CER) Sends secure binary attachments over the internet; uses ASCII text format to prevent corruption of file. Cryptographic Message Syntax Standard-PKCS #7 Certificates (.P7B) Exports the certificate and all certificates in the certification path to the chosen PC. Step 6 Step 7 Step 8 Browse to the file that you want to export. Click Finish. When the successful export dialog box displays, click OK. HTTPS Overview, page 2-1 Using Internet Explorer to Save the Certificate to the Trusted Folder, page 2-5 Viewing Details of the Certificate, page 2-6 Using Netscape with HTTPS When you use HTTPS with Netscape, you can view the certificate credentials, trust the certificate for one session, trust the certificate until it expires, or not trust the certificate at all. Tip If you trust the certificate for one session only, you must repeat the Using Netscape To Save the Certificate to the Trusted Folder procedure each time that you access the HTTPS-supported application. If you do not trust the certificate, you cannot access the application. HTTPS Overview, page 2-1 Using Netscape To Save the Certificate to the Trusted Folder, page

51 Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Using Netscape To Save the Certificate to the Trusted Folder Troubleshooting HTTPS, page 7-4 Using Netscape To Save the Certificate to the Trusted Folder Perform the following procedure to save the certificate to the trusted folder: Procedure Step 1 Step 2 Step 3 Access the application, for example, Cisco CallManager Administration, through Netscape. After the New Site Certificate window displays, click Next. After the next New Site Certificate window displays, click Next. Tip To view the certificate credentials before you click Next, click More Info. Review the credentials, and click OK.; then, click Next in the New Site Certificate window. Step 4 Step 5 Click one of the following radio buttons: Accept this certificate for this session Do not accept this certificate and do not connect Accept this certificate forever (until it expires) Click Next. Step 6 If you clicked the Do not accept this certificate... radio button, go to Step 8. Step 7 Step 8 If you want Netscape to warn you before sending information to other sites, check the Warn me before I send information to this site check box; then, click Next. Click Finish. HTTPS Overview, page

52 Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Using a Server Authentication Certificate From a Third-Party Certificate Authority Using Netscape with HTTPS, page 2-8 Troubleshooting HTTPS, page 7-4 Using a Server Authentication Certificate From a Third-Party Certificate Authority To use a server authentication certificate from a third-party certificate authority instead of the certificate that is provided with Cisco CallManager, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Delete the HTTPS certificate, as described in the Enabling HTTPS section on page 7-6. Install the certificate that you want to use. Right-click the certificate file. Choose the Install Certificate option. Tip You can install by using the default setting. Step 5 Install the certificate on the IIS default website by performing the following tasks: a. Choose Start > Programs > Administrative Tools > Internet Service Manager. b. Click the name of the server where you want to install the certificate. c. Click the Directory Security tab. d. Under Secure Communications, click the Server Certificate button. e. Click Next. f. Choose the Assign an Existing Certificate option. g. Choose the certificate from Step 2. h. Click Next. 2-10

53 Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Using a Server Authentication Certificate From a Third-Party Certificate Authority i. Click Finish. Troubleshooting, page 7-1 HTTPS Overview, page

54 Chapter 2 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Using a Server Authentication Certificate From a Third-Party Certificate Authority 2-12

55 CHAPTER 3 Configuring the Cisco CTL Client This chapter contains information on the following topics: Cisco CTL Client Overview, page 3-2 Cisco CTL Client Configuration Checklist, page 3-3 Activating the Cisco CTL Provider Service, page 3-5 Configuring Ports for the TLS Connection, page 3-6 Installing the Cisco CTL Client, page 3-8 Upgrading the Cisco CTL Client and Migrating the Cisco CTL File, page 3-10 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Updating the Clusterwide Security Mode, page 3-18 Cisco CTL Client Configuration Settings, page 3-19 Deleting a CTL File Entry, page

56 Cisco CTL Client Overview Chapter 3 Configuring the Cisco CTL Client Cisco CTL Client Overview Device, file, and signaling authentication rely on the creation of the Certificate Trust List (CTL) file, which is created when you install and configure the Cisco Certificate Trust List (CTL) client on a single Windows 2000 workstation or server, perhaps a Cisco CallManager server, that has a USB port. The CTL file contains entries for the following servers or security tokens: Site Administrator Security Token (SAST) Cisco CallManager and Cisco TFTP running on the same server Certificate Authority Proxy Function (CAPF) Alternate Cisco TFTP The CTL file contains a server certificate, public key, serial number, signature, issuer name, subject name, server function, DNS name, and IP address for servers. After you create the CTL file, you must restart the Cisco CallManager and Cisco TFTP services in Cisco CallManager Serviceability on all servers in the cluster that run these services. The next time that the phone initializes, it downloads the CTL file from the TFTP server. If the CTL file contains a TFTP server entry that has a self-signed certificate, the phone requests a signed configuration file in.sgn format. If none of the TFTP servers contains a certificate, the phone requests an unsigned file. Note Cisco CallManager stores the CTL file, which exists in.tlv format, in the directory that is specified in the TFTP File Location and TFTP Alternate File Locations. After you install and configure the Cisco CTL client, verify that a certificate exists in the phone, and configure the device for authentication or encryption, the phone establishes a TLS connection through a TLS SCCP port, which is a configured port number added to (+) 443. By default, the phone connects to port 2443 by using TLS. The handshake authenticates the certificates and establishes a secure connection. Cisco CTL Client Configuration Checklist, page 3-3 Authentication and Integrity Overview, page

57 Chapter 3 Configuring the Cisco CTL Client Cisco CTL Client Configuration Checklist Cisco CTL Client Configuration Checklist Table 3-1 provides a list of configuration tasks that you perform to install and configure the Cisco CTL client for the first time. Table 3-1 Cisco CTL Client Configuration Checklist Configuration Steps Step 1 Step 2 Step 3 On each Cisco CallManager and Cisco TFTP server in the cluster, activate the Cisco CTL Provider service in Cisco CallManager Serviceability. Tip If you activated this service prior to a Cisco CallManager upgrade, you do not need to activate the service again. The service automatically activates after the upgrade. On the publisher database server, activate the Cisco Certificate Authority Proxy service in Cisco CallManager Serviceability. Timesaver Performing this task before you install and configure the Cisco CTL client ensures that you do not have to update the CTL file to use CAPF. If you do not want to use the default settings, configure ports for the TLS connection. Tip If you configured these settings prior to a Cisco CallManager upgrade, the settings migrate automatically. Related Procedures and Topics Activating the Cisco CTL Provider Service, page 3-5 Activating the Certificate Authority Proxy Function Service, page 4-10 Configuring Ports for the TLS Connection, page

58 Cisco CTL Client Configuration Checklist Chapter 3 Configuring the Cisco CTL Client Table 3-1 Cisco CTL Client Configuration Checklist Configuration Steps Step 4 Obtain at least two security tokens and the passwords, hostnames/ip addresses, and port numbers for the servers that you will configure for the Cisco CTL client. Step 5 Install the Cisco CTL client. Step 6 Tip You cannot use the Cisco CTL client that was available with Cisco CallManager 4.0. To update the CTL file after a Cisco CallManager 4.1 upgrade, you must install the plug-in that is available with Cisco CallManager Administration 4.1. Configure the Cisco CTL client. Tip If you created the CTL file prior to a Cisco CallManager upgrade, the CTL file migrates automatically during the upgrade. To update the CTL file after a Cisco CallManager Release 4.1 upgrade, you must install and configure the Cisco CTL client that is available with Cisco CallManager Administration 4.1. Related Procedures and Topics Configuring the Cisco CTL Client, page 3-11 System Requirements, page 1-4 Installation, page 1-13 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page

59 Chapter 3 Configuring the Cisco CTL Client Activating the Cisco CTL Provider Service Activating the Cisco CTL Provider Service After you configure the Cisco CTL client, this service changes the cluster security mode from nonsecure to mixed mode and vice versa and transports the server certificates to the CTL file; the service then transports the CTL file to all Cisco CallManager and Cisco TFTP servers. If you activate the service and then upgrade Cisco CallManager, Cisco CallManager automatically reactivates the service after the upgrade. Tip You must activate the Cisco CTL Provider service on all servers in the cluster. Verify that the local administrator password or the Power Users account username and password are synchronized on all Cisco CallManager and Cisco TFTP servers. To activate the service, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 In Cisco CallManager Serviceability, choose Tools > Service Activation. In the pane on the left side of the window, choose a server where you have activated the Cisco CallManager or Cisco TFTP services. Check the CTL Provider service check box. Click Update. Perform this procedure on all servers in the cluster. Note After you activate the service, the Cisco CTL Provider service reverts to the default CTL port, which is If you want to change the port, see the Configuring Ports for the TLS Connection section on page 3-6. Step 6 Verify that the service runs on all servers in the cluster. In Cisco CallManager Serviceability, choose Tools > Control Center to verify the state of the service. 3-5

60 Activating the Cisco CAPF Service Chapter 3 Configuring the Cisco CTL Client Cisco CallManager Serviceability Administration Guide Cisco CallManager Serviceability System Guide Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Activating the Cisco CAPF Service For information on activating this service, see the Activating the Certificate Authority Proxy Function Service section on page Timesaver Performing this task before you install and configure the Cisco CTL client ensures that you do not have to update the CTL file to use CAPF. Cisco CTL Client Configuration Checklist, page 3-3 CAPF Configuration Checklist, page 4-7 Activating the Certificate Authority Proxy Function Service, page 4-10 Configuration Checklist Overview, page 1-20 Configuring Ports for the TLS Connection You may have to configure a different port number if the port is currently being used or if you use a firewall and you cannot use the port within the firewall. The Cisco CTL Provider default port for the TLS connection equals The Cisco CTL Provider port monitors requests from the Cisco CTL client. This port processes Cisco CTL client requests, such as retrieving the CTL file, setting the clusterwide security mode, saving the CTL file to TFTP servers, and retrieving a list of Cisco CallManager and TFTP servers in the cluster. 3-6

61 Chapter 3 Configuring the Cisco CTL Client Configuring Ports for the TLS Connection The Cisco CallManager port monitors registration requests from the phone. In nonsecure mode, the phone connects through port In mixed mode, the Cisco CallManager port for TLS connection equals the value for the Cisco CallManager port number added to (+) 443; therefore, the default TLS connection for Cisco CallManager equals Tip After you update the port(s), you must restart the Cisco Provider service in Cisco CallManager Administration. To change the default setting, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Perform the following tasks, depending on the port that you want to change: To change the Cisco CTL Provider port, perform Step 2 through Step 6. To change the Cisco CallManager port, perform Step 7 through Step 10. To change the Cisco CTL Provider port, choose Service > Service Parameters from Cisco CallManager Administration. Choose a server where the Cisco CTL Provider service runs. Choose Cisco CTL Provider service. Tip In the upper, right corner of the window, click the i button to review information for the service parameter. Step 5 Step 6 Step 7 Step 8 To change the Cisco CTL Provider port, enter the new port number in the Port Number field. Click Update. To change the Cisco CallManager port, choose System > Cisco CallManager in Cisco CallManager Administration. Choose a server where the Cisco CallManager service runs. 3-7

62 Installing the Cisco CTL Client Chapter 3 Configuring the Cisco CTL Client Step 9 Step 10 In the Ethernet Phone Port field, enter the new port number. Click Update. Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Cisco CTL Client Configuration Settings, page 3-19 Troubleshooting, page 7-1 Installing the Cisco CTL Client You install the Cisco CTL client on a single Windows 2000 workstation or server that has a USB port. The server or workstation can exist at a remote site. If you choose to do so, you can install the client on a server where Cisco CallManager is installed as long as the server has a USB port. You must use the client and update the CTL file when the following events occur: After the Cisco CallManager installation After you restore a Cisco CallManager server or Cisco CallManager data After you change the IP address or hostname of the Cisco CallManager server After you add or remove a security token, TFTP server, or Cisco CallManager server 3-8

63 Chapter 3 Configuring the Cisco CTL Client Installing the Cisco CTL Client Caution Do not use Terminal Services to install the client. Cisco installs Terminal Services, so Cisco Technical Assistance Center (TAC) can perform remote troubleshooting and configuration tasks. Before you run the plug-in, you must disable Cisco Security Agent (CSA) or other Cisco-approved intrusion detection or antivirus applications. Failure to disable the applications may prevent the installation and result in unrecoverable errors. Tip If the Smart Card service is not set to started and automatic on the server or workstation where you plan to install the client, the installation fails. For information on how to perform this task, see the Troubleshooting section on page 7-1. To review a list of messages that could display during the installation of the plug-in, see the Troubleshooting section on page 7-1. To install the Cisco CTL client, perform the following procedure: Procedure Step 1 Verify that the Smart Card service is set to started and automatic. For more information, see the Setting the Smart Card Service to Started and Automatic section on page Step 2 Browse to Cisco CallManager Administration from the Windows 2000 workstation or server that has the USB port; that is, the location where you plan to install the client. Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 From Cisco CallManager Administration, choose Application > Install Plugins. To download the file, click Cisco CTL Client. Download the file to a location that you will remember. To begin the installation, double-click Cisco CTL Client (icon or executable depending on where you saved the file). The version of the Cisco CTL client displays; click Continue. The installation wizard displays. Click Next. 3-9

64 Upgrading the Cisco CTL Client and Migrating the Cisco CTL File Chapter 3 Configuring the Cisco CTL Client Step 9 Step 10 Step 11 Step 12 Accept the license agreement and click Next. Choose a folder where the client will exist. If you want to do so, click Browse to change the default location; after you choose the location, click Next. To begin the installation, click Next. After the installation completes, click Finish to exit. Tip To verify that the client installed, see the Troubleshooting section on page 7-1. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Activating the Cisco CTL Provider Service, page 3-5 Setting the Smart Card Service to Started and Automatic, page 7-11 Activating the Cisco CTL Provider Service, page 3-5 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Deleting a CTL File Entry, page 3-22 Configuring the Device Security Mode, page 5-3 Troubleshooting, page 7-1 Upgrading the Cisco CTL Client and Migrating the Cisco CTL File If you want to make changes to the CTL file after the Cisco CallManager 4.1 upgrade, you must install and configure the Cisco CTL client that is available with Cisco CallManager Administration

65 Chapter 3 Configuring the Cisco CTL Client Configuring the Cisco CTL Client If you did not remove or add any servers before the Cisco CallManager upgrade, you do not need to reconfigure the Cisco CTL client after the upgrade. The Cisco CallManager upgrade automatically migrates the data in the CTL file. Cisco CTL Client Configuration Checklist, page 3-3 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Troubleshooting, page 7-1 Configuring the Cisco CTL Client Tip Configure the Cisco CTL client during a scheduled maintenance window because you must restart the Cisco CallManager and Cisco TFTP services in Cisco CallManager Serviceability on all servers in the cluster that run these services. The Cisco CTL client performs the following tasks: Sets the Cisco CallManager cluster security mode. Tip You cannot set the Cisco CallManager clusterwide mixed mode through the Enterprise Parameters window in Cisco CallManager Administration. You must configure the CTL client to set the clusterwide mode. For more information, see the Cisco CTL Client Configuration Settings section on page Creates the Certificate Trust List (CTL), which is a file that contains certificate entries for security tokens, Cisco CallManager, alternate TFTP, and CAPF servers. The CTL file indicates the servers that support TLS for the phone connection. The client automatically detects the Cisco CallManager, Cisco TFTP servers, and the Cisco CAPF server and adds certificate entries for these servers. 3-11

66 Configuring the Cisco CTL Client Chapter 3 Configuring the Cisco CTL Client You must manually add alternate TFTP servers and Site Administrator Security Tokens (SAST) to the CTL file. The security tokens that you insert during the configuration sign the CTL file. Tip You can configure an alternative TFTP server, even if this server exists in a different cluster. Through manual configuration, the certificate from the alternate TFTP server gets added to the CTL file, which is written to the FileLocation path as specified in the TFTP service parameter. For a multicluster configuration, you must map the drive on the alternate TFTP server and configure the FileLocation parameter to the mapped drive. For example, if you use TFTP1 as your alternate TFTP server and you have mapped drive L: to the path on TFTP1, the FileLocation equals L:\TFTPPath. You must add the TFTP server, TFTP1, for example, by specifying a valid administrator username and password for TFTP1. The Cisco CTL client will write the CTL file to L:\TFTPPath. Before you implement this TFTP configuration, all servers in the multicluster environment must run the same version of Cisco CallManager and be configured for the same clusterwide security mode; be aware that all servers in the multicluster environment must run the Cisco CTL Provider service. Before You Begin Before you configure the Cisco CTL client, verify that you activated the Cisco CTL Provider service and the Cisco Certificate Authority Proxy Function service in Cisco CallManager Serviceability. Obtain at least two security tokens; the Cisco certificate authority issues these security tokens. You will insert the tokens one at a time into the USB port on the server/workstation. If you do not have a USB port on the server, you may use a USB PCI card. Obtain the following passwords, hostnames/ip addresses, and port numbers: Local administrative password and hostname/ip address for Cisco CallManager and the port number for the CTL Provider service Local administrative password and hostname/ip address for alternate TFTP Security token administrative password See Table 3-2 for a description of the preceding information. 3-12

67 Chapter 3 Configuring the Cisco CTL Client Configuring the Cisco CTL Client Tip Before you install the Cisco CTL client, verify that you have network connectivity to each server in the cluster; likewise, ensure that the server uses DNS and that each server is running. To ensure that you have network connectivity to all servers in the cluster, issue a ping command to each server. Choose Start > Run; enter cmd, and click OK. At the command prompt, enter ping <server>, where server equals the name of the server that displays in the Server Configuration window of Cisco CallManager Administration. Repeat the ping command for each server in the cluster. If you installed multiple Cisco CTL clients, Cisco CallManager only accepts CTL configuration information on one client at a time, but you can perform configuration tasks on up to five Cisco CTL clients simultaneously. While you perform configuration tasks on one client, Cisco CallManager automatically stores the information that you entered on the other clients. After You Complete the Cisco CTL Client Configuration After you complete the Cisco CTL Client configuration, the CTL Client performs the following tasks: Writes the CTL file to all Cisco CallManager servers in the cluster. Writes the CTL file to alternate TFTP server(s) that you configured. Writes CAPF capf.cer to all Cisco CallManager subscribers in the cluster. Writes CAPF certificate file in PEM format to all Cisco CallManager subscribers in the cluster. To configure the client, perform the following procedure: Procedure Step 1 Step 2 Step 3 Obtain at least two security tokens that you purchased. Perform one of the following tasks: Double-click the Cisco CTL Client icon that exists on the desktop of the workstation/server where you installed it. Choose Start > Programs > Cisco CTL Client. Enter the configuration settings for the Cisco CallManager server, as described in Table 3-2; click Next. 3-13

68 Configuring the Cisco CTL Client Chapter 3 Configuring the Cisco CTL Client Step 4 Step 5 Click Set CallManager Cluster to Mixed Mode, as described in Table 3-2; click Next. Perform the following tasks, depending on what you want to accomplish: To add a security token, see Step 6 through Step 12. To add an alternate TFTP server, see Step 13 through Step 15. To complete the Cisco CTL client configuration, see Step 17 through Step 21. Caution You need a minimum of two security tokens the first time that you configure the client. Do not insert the tokens until the application prompts you to do so. If you have two USB ports on the workstation or server, do not insert two security tokens at the same time. Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 When the application prompts you to do so, insert one security token in an available USB port on the workstation or server where you are currently configuring the Cisco CTL client; click OK. The security token information displays for the token that you inserted; click Add. The detected certificate entries display in the pane. To add other security token(s) to the certificate trust list, click Add Tokens. If you have not already done so, remove the token that you inserted into the server or workstation. When the application prompts you to do so, insert the next token and click OK. The security token information for the second token displays; click Add. Step 12 For all security tokens, repeat Step 9 through Step 11. Step 13 The certificate entries display in the pane. If you need to add an Alternate TFTP server, click Add TFTP Server. Step 14 Enter the configuration settings, as described in Table 3-2. Step 15 Step 16 Step 17 Click Next. Enter the configuration settings, as described in Table 3-2; click Next. When you have added all security tokens and servers, click Finish. Step 18 Enter the username password for the security token, as described in Table 3-2; click OK. 3-14

69 Chapter 3 Configuring the Cisco CTL Client Configuring the Cisco CTL Client Step 19 Step 20 Step 21 Step 22 After the client creates the CTL file, a window displays the server, file location, and status of the CTL file on each server. Click Finish. Reset all devices in the cluster. See the Resetting Devices, Restarting Services, or Rebooting the Server/Cluster section on page In Cisco CallManager Serviceability, restart the Cisco CallManager and Cisco TFTP services that run on each server in the cluster. After you create the CTL file, you may remove the security token from the USB port. Store all security tokens in a safe place that you will remember. Tip To verify that you set the Cisco CallManager cluster to mixed mode, see the Troubleshooting section on page 7-1. If you are prompted to change the security token password, see the Troubleshooting section on page 7-1. Cisco CTL Client Configuration Settings, page 3-19 System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Activating the Cisco CTL Provider Service, page 3-5 Setting the Smart Card Service to Started and Automatic, page 7-11 Activating the Cisco CTL Provider Service, page 3-5 Cisco CTL Client Configuration Settings, page 3-19 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Configuring the Device Security Mode, page 5-3 Troubleshooting, page

70 Updating the CTL File Chapter 3 Configuring the Cisco CTL Client Updating the CTL File You must update the CTL file if the following scenarios occur: If you add a new Cisco CallManager server to the cluster If you change the name or IP address of the Cisco CallManager server in the cluster If you enabled the Cisco Certificate Authority Function service in Cisco CallManager Serviceability If you need to add or delete additional security tokens If you need to add or delete the alternate TFTP server If you restore the Cisco CallManager server or Cisco CallManager data For the changes to take effect, you must restart the Cisco CallManager and Cisco TFTP services in Cisco CallManager Serviceability for all servers that run these services; you must also reset all devices in the cluster after you restart the services. See the Resetting Devices, Restarting Services, or Rebooting the Server/Cluster section on page 1-12 for more information on how to perform this task. Tip Cisco strongly recommends that you update the file when minimal call-processing interruptions will occur. To update the information that exists in CTL file, perform the following procedure: Procedure Step 1 Step 2 Step 3 Obtain one security token that you inserted to configure the latest CTL file. Double-click the Cisco CTL Client icon that exists on the desktop of the workstation/server where you installed it. Enter the configuration settings for the Cisco CallManager server, as described in Table 3-2; click Next. Tip You make updates in this window for the Cisco CallManager server. 3-16

71 Chapter 3 Configuring the Cisco CTL Client Updating the CTL File Step 4 To update the CTL file, click Update CTL File, as described in Table 3-2; click Next. Caution Step 5 Step 6 For all CTL file updates, you must insert one security token that already exists in the CTL file into the USB port. The client validates the signature of the CTL file through this token. You cannot add new tokens until the CTL client validates the signature. If you have two USB ports on the workstation or server, do not insert both security tokens at the same time. If you have not already inserted one security token in an available USB port on the workstation or server where you are currently updating the CTL file, insert one of the security tokens; click OK. The security token information displays for the token that you inserted; click Next. The detected certificate entries display in the pane. Tip You cannot update the Cisco CallManager or Cisco TFTP entries from this pane. To update the Cisco CallManager entry, click Cancel and perform Step 2 through Step 6 again. Step 7 To update existing Cisco CTL entries or to add or delete security tokens, consider the following information: To update alternate TFTP entries, delete the entry, as described in Deleting a CTL File Entry section on page 3-22; then, add the entry, as described in Configuring the Cisco CTL Client section on page To add new security tokens, see Configuring the Cisco CTL Client section on page To delete a security token, see the Deleting a CTL File Entry section on page Tip If you are prompted to change the security token password, see the Troubleshooting section on page

72 Updating the Clusterwide Security Mode Chapter 3 Configuring the Cisco CTL Client Cisco CTL Client Configuration Settings, page 3-19 System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Activating the Cisco CTL Provider Service, page 3-5 Setting the Smart Card Service to Started and Automatic, page 7-11 Activating the Cisco CTL Provider Service, page 3-5 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Configuring the Device Security Mode, page 5-3 Troubleshooting, page 7-1 Updating the Clusterwide Security Mode You must use the Cisco CTL client to configure the clusterwide security mode. You cannot change the clusterwide security mode from the Enterprise Parameters window of Cisco CallManager Administration. To change the clusterwide security mode after the initial configuration of the Cisco CTL client, you must update the CTL file, as described in the Updating the CTL File section on page 3-16 and Table 3-2. If you change the clusterwide security mode from mixed to nonsecure mode, the CTL file still exists on the servers in the cluster, but the CTL file does not contain any certificates. Because no certificates exist in the CTL file, the phone requests an unsigned configuration file and registers as nonsecure with Cisco CallManager. Updating the CTL File, page 3-16 Cisco CTL Client Configuration Settings, page 3-19 Troubleshooting, page

73 Chapter 3 Configuring the Cisco CTL Client Cisco CTL Client Configuration Settings Cisco CTL Client Configuration Settings The cluster can exist in one of two modes, as described in Table 3-2. Only mixed mode supports authentication. When you configure the Cisco CTL client for authentication, you must choose Set CallManager Cluster to Mixed Mode. Use Table 3-2 to configure the Cisco CTL client for the first time, to update the CTL file, or to change the mode from mixed to nonsecure. Table 3-2 Configuration Settings for CTL Client Setting CallManager Server Hostname or IP Address Port Username and Password Description Enter the hostname or IP address for a server in the cluster that runs the Cisco CallManager or Cisco TFTP service. Enter the port number, which equals the CTL port for the Cisco CTL Provider service that runs on the specified Cisco CallManager server. The default port number equals Enter a username and password that has administrative privileges on the Cisco CallManager server. Tip Verify that you entered the username and password for the Cisco CallManager administrator or Power User account. The same username and password must exist on all servers in the cluster. 3-19

74 Cisco CTL Client Configuration Settings Chapter 3 Configuring the Cisco CTL Client Table 3-2 Configuration Settings for CTL Client (continued) Setting Radio Button Set CallManager Cluster to Mixed Mode Set CallManager Cluster to Non-Secure Mode Update CTL File Description Mixed mode allows authenticated or encrypted Cisco IP Phones and nonauthenticated Cisco IP Phones to register with Cisco CallManager. In this mode, Cisco CallManager ensures that authenticated or encrypted devices use a secure SCCP port. Note Cisco CallManager disables auto-registration if you configure the cluster for mixed mode. All devices register as unauthenticated with Cisco CallManager, and Cisco CallManager supports image authentication only. When you choose this mode, the CTL client removes the certificates for all entries that are listed in the CTL file, but the CTL file still exists in the directory that you specified. The phone requests unsigned configuration files and registers as nonsecure with Cisco CallManager. Tip To revert the phone to the default nonsecure mode, you must delete the CTL file from the phone and all Cisco CallManager servers. For information on deleting the CTL file from the phone and Cisco CallManager servers, see the Troubleshooting section on page 7-1. Tip You can use auto-registration in this mode. After you have created the CTL file, you must choose this option to make any changes to the CTL file. Choosing this option ensures that the Cluster Security mode does not change. 3-20

75 Chapter 3 Configuring the Cisco CTL Client Cisco CTL Client Configuration Settings Table 3-2 Configuration Settings for CTL Client (continued) Setting Description Alternate TFTP Server Hostname or IP Address Note Alternate TFTP server designates a Cisco TFTP server that exists in a different cluster. If you use two different clusters for the alternate TFTP server configuration, both clusters must use the same clusterwide security mode, which means that you must install and configure the Cisco CTL client in both clusters. Likewise, both clusters must run the same version of Cisco CallManager. Caution Ensure that the path in the TFTP service parameter, FileLocation, is the same for all servers in the cluster. Port Username and Password Security Token User Password Enter the hostname or IP address for the TFTP server. Enter the port number, which equals the CTL port for the Cisco CTL Provider service that runs on the specified TFTP server. The default port number equals Enter a username and password that have local administrative privileges on the server. The first time that you configure the Cisco CTL client, enter Cisco123, the case-sensitive default password, to retrieve the private key of the certificate and ensure that the CTL file gets signed. Tip To change this password, see the Changing the Security Token Password (Etoken) section on page

76 Deleting a CTL File Entry Chapter 3 Configuring the Cisco CTL Client System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Activating the Cisco CTL Provider Service, page 3-5 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Configuring the Device Security Mode, page 5-3 Troubleshooting, page 7-1 Deleting a CTL File Entry At any time, you can delete some CTL entries that display in the CTL Entries window of the Cisco CTL client. After you open the client and follow the prompts to display the CTL Entries window, click Delete Selected to delete the entry. You cannot delete servers that run Cisco CallManager, Cisco TFTP, or Cisco CAPF from the CTL file. You can delete alternate TFTP servers and security tokens that you manually add to the CTL file, but you cannot delete TFTP servers that the client automatically detects. Two security token entries must exist in the CTL file at all times. You cannot delete all security tokens from the file. Tip For information on uninstalling the Cisco CTL client, deleting the CTL file from the phone, or deleting the CTL file from the server, see the Troubleshooting the Cisco CTL Client section on page 7-8. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Activating the Cisco CTL Provider Service, page

77 Chapter 3 Configuring the Cisco CTL Client Deleting a CTL File Entry Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Configuring the Device Security Mode, page 5-3 Troubleshooting, page

78 Deleting a CTL File Entry Chapter 3 Configuring the Cisco CTL Client 3-24

79 CHAPTER 4 Using the Certificate Authority Proxy Function This chapter provides information on the following topics: Certificate Authority Proxy Function Overview, page 4-2 Cisco IP Phone and CAPF Interaction, page 4-3 CAPF System Interactions and Requirements, page 4-3 Migrating Existing CAPF Data, page 4-6 Configuring CAPF in Cisco CallManager Serviceability, page 4-5 CAPF Configuration Checklist, page 4-7 Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server, page 4-9 Activating the Certificate Authority Proxy Function Service, page 4-10 Updating CAPF Service Parameters, page 4-11 Updating CAPF Enterprise Parameters, page 4-14 CAPF Service Parameters, page 4-12 Installing/Upgrading the Locally Significant Certificates, page 4-15 Deleting the Locally Significant Certificate, page 4-16 CAPF Settings in the Phone Configuration Window, page 4-18 Using CAPF with the Bulk Administration Tool, page

80 Certificate Authority Proxy Function Overview Chapter 4 Using the Certificate Authority Proxy Function Generating a CAPF Report, page 4-21 Finding Phones by Choosing the LSC Status, page 4-22 Entering the Authentication String on the Phone, page 4-22 Certificate Authority Proxy Function Overview Certificate Authority Proxy Function (CAPF), which automatically installs with Cisco CallManager, performs the following tasks, depending on your configuration: Issue locally significant certificates to supported Cisco IP Phone models. Using SCEP, request certificates from third-party certificate authorities on behalf of supported Cisco IP Phone models. Upgrade existing locally significant certificates on the phones. Retrieve phone certificates for viewing and troubleshooting. Delete locally significant certificates on the phone. Authenticate via the manufacture-installed certificate After you activate the Cisco Certificate Authority Proxy Function service, CAPF automatically generates a key pair and certificate that is specific for CAPF. The CAPF certificate, which the Cisco CTL Client copies to all servers in the cluster, uses the.0 extension. To verify that the CAPF certificate exists, browse to C:\Program Files\Cisco\Certificates on each server and locate the following files: In DER encoded format CAPF.cer In PEM encoded format.0 extension file that contains the same common name string as the CAPF.cer CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page

81 Chapter 4 Using the Certificate Authority Proxy Function Cisco IP Phone and CAPF Interaction Cisco IP Phone and CAPF Interaction When the phone interacts with CAPF, the phone generates its public key and private key pair and then forwards its public key to the CAPF server in a signed message. The private key remains in the phone and is never exposed externally. Depending on the configuration in Cisco CallManager Administration, CAPF may sign the phone certificate or may act as a SCEP protocol proxy to the third-party, Cisco-approved CA server to sign the phone certificate. CAPF then sends the certificate back to the phone in a signed message. The following information applies when a communication or power failure occurs. If a communication failure occurs while the certificate installation is taking place on the phone, the phone will attempt to obtain the certificate three more times in 30-second intervals. You cannot configure these values. If a power failure occurs while the phone attempts a session with CAPF, the phone will use the authentication mode that is stored in flash; that is, if the phone cannot load the new configuration file from the TFTP server after the phone reboots. After the certificate operation completes, the system clears the value in flash. Tip Be aware that the phone user can abort the certificate operation or view the operation status on the phone. CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page 4-7 Cisco IP Phone Administration Guide for Cisco CallManager CAPF System Interactions and Requirements The following requirements exist for CAPF: Before you upgrade to Cisco CallManager 4.1, review the following sections: Migrating Existing CAPF Data, page

82 CAPF System Interactions and Requirements Chapter 4 Using the Certificate Authority Proxy Function Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server, page 4-9 Before you use CAPF, ensure that you performed all necessary tasks to install and configure the Cisco CTL client. To use CAPF, you must activate the Cisco Certificate Authority Proxy Function service on the publisher database server. Cisco strongly recommends that you use CAPF during a scheduled maintenance window because generating many certificates at the same time may cause call-processing interruptions. All servers in the Cisco CallManager 4.1 cluster must use the same administrator username and password, so CAPF can authenticate to all servers in the cluster. Ensure that the publisher database server is functional and running during the entire certificate operation. Ensure that the phone is functional during the entire certificate operation. If you want to do so, you can use the Microsoft Certificate Services with CAPF if the Microsoft Certificate Services software runs on a Windows 2003 server. For information on how to use this software or for troubleshooting support, contact the certificate authority vendor directly. If CAPF will request certificates from Microsoft Certificate Services, you must enter the necessary configuration information, for example, the IP address or hostname, for this certificate authority in the applicable CAPF service parameter. If you plan to use Microsoft Certificate Services, you must install the SCEP addon on the server where you install Microsoft Certificate Services. To obtain the SCEP addon, contact the certificate authority vendor directly. Tip Before you use a third-party certificate authority (CA) with CAPF, review the certificate authority vendor documentation to ensure that no limitations exist that may affect the ability to issue certificates. If you want to do so, you can use Keon Utility to generate certificates for CAPF. You must enter the necessary configuration information, for example, the IP address or hostname, for this certificate authority in the applicable CAPF service parameter. You must also provide the Keon Jurisdiction ID in the appropriate service parameter field. 4-4

83 Chapter 4 Using the Certificate Authority Proxy Function Configuring CAPF in Cisco CallManager Serviceability For information on how to use the Keon software or for troubleshooting support, contact the certificate authority vendor directly. To use the Keon Utility or Microsoft Certificate Services with CAPF, you must define the following Object IDs. For information on how to use the following settings, refer to the certificate authority vendor documentation. ( ) Server SSL/TLS authentication ( ) Client SSL/TLS authentication ( ) IPSec end system authentication Tip Cisco IP Telephony Backup and Restore System (BARS) backs up the CAPF data and reports because Cisco CallManager stores the information in the Cisco CallManager database. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 Migrating Existing CAPF Data, page 4-6 CAPF Configuration Checklist, page 4-7 Configuring CAPF in Cisco CallManager Serviceability You perform the following tasks in Cisco CallManager Serviceability: Activate the Cisco Certificate Authority Proxy Function service. Configure trace settings for CAPF. Cisco CallManager Serviceability Administration Guide Cisco CallManager Serviceability System Guide 4-5

84 Migrating Existing CAPF Data Chapter 4 Using the Certificate Authority Proxy Function Migrating Existing CAPF Data Caution Failing to perform the tasks that are described in this section may cause a loss of CAPF data. Review the following details before you install or overwrite a locally significant certificate: Upgrades from Cisco CallManager 4.0 where CAPF was installed on the Cisco CallManager 4.0 publisher database server If you performed certificate operations with Cisco CallManager 4.0 and CAPF 1.0(1) ran on the publisher database server, the latest operation status migrates to the Cisco CallManager 4.1 database. Upgrades from Cisco CallManager where CAPF was installed on a Cisco CallManager 4.0 subscriber server If you performed certificate operations with Cisco CallManager 4.0 and CAPF 1.0(1) ran on a subscriber server, you must copy the CAPF data to the 4.0 publisher database server before you upgrade the cluster to Cisco CallManager 4.1. Caution If you fail to copy the data prior to the Cisco CallManager 4.1 upgrade, the CAPF data on the Cisco CallManager 4.0 subscriber server does not migrate to the Cisco CallManager 4.1 database, and a loss of data may occur. If a loss of data occurs, the locally significant certificates that you issued with CAPF utility 1.0(1) remain in the phones. CAPF 4.1(2) must reissue the certificate, which is not valid. Upgrades from one release of Cisco CallManager 4.1(x) to a later release of Cisco CallManager 4.1(x) The upgrade automatically migrates the CAPF data. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page 4-7 Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server, page

85 Chapter 4 Using the Certificate Authority Proxy Function CAPF Configuration Checklist CAPF Configuration Checklist Table 4-1 provides a list of tasks that you perform to install, upgrade, delete or troubleshoot locally significant certificates. Table 4-1 CAPF Configuration Checklist Configuration Steps Step 1 Step 2 Step 3 Step 4 Determine whether a locally significant certificate exists in the phone. Determine whether you need to copy CAP 1.0(1) data to the Cisco CallManager 4.1(2) publisher database server. If you used the CAPF utility with Cisco CallManager 4.0 and verified that the CAPF data exists in the Cisco CallManager 4.1 database, delete the CAPF utility that you used with Cisco CallManager 4.0. Verify that the Cisco Certificate Authority Proxy Function service is running. Tip This service must run during all CAPF operations. It must also run for the Cisco CTL client to include the CAPF certificate in the CTL file. Verify that you performed all necessary tasks to install and configure the Cisco CTL client. Ensure that the CAPF certificate exists in the Cisco CTL file. Related Procedures and Topics Verifying That a Manufactured-Installed Certificate (MIC) Exists in the Phone, page 7-40 Verifying That a Locally Significant Certificate Exists on the Phone, page 7-39 Migrating Existing CAPF Data, page 4-6 Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server, page 4-9 Choose Settings > Control Panel. Double-click Add/Remove Programs and locate the utility. Remove the utility. Activating the Certificate Authority Proxy Function Service, page 4-10 Configuring the Cisco CTL Client, page

86 CAPF Configuration Checklist Chapter 4 Using the Certificate Authority Proxy Function Table 4-1 CAPF Configuration Checklist (continued) Configuration Steps Step 5 If necessary, update CAPF service parameters. Step 6 Step 7 Step 8 Step 9 To install, upgrade, delete, or troubleshoot locally significant certificates in the phone, use Cisco CallManager Administration or BAT. To view a list of devices that use CAPF, generate a CAPF report in Cisco CallManager Administration. If it is required for certificate operations, enter the authentication string on the phone. Verify that the certificate operation succeeded as planned. Related Procedures and Topics Updating CAPF Service Parameters, page 4-11 CAPF Service Parameters, page 4-12 Installing/Upgrading the Locally Significant Certificates, page 4-15 CAPF Settings in the Phone Configuration Window, page 4-18 Using CAPF with the Bulk Administration Tool, page 4-21 Generating a CAPF Report, page 4-21 Entering the Authentication String on the Phone, page 4-22 Verifying That a Locally Significant Certificate Exists on the Phone, page 7-39 Verifying That a Manufactured-Installed Certificate (MIC) Exists in the Phone, page

87 Chapter 4 Using the Certificate Authority Proxy Function Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server Copying CAPF 1.0(1) Data From a 4.0 Subscriber Server to the 4.0 Publisher Database Server Caution If you installed CAPF utility 1.0(1) on a Cisco CallManager 4.0 subscriber server, you must copy the CAPF data to the 4.0 publisher database server before you upgrade to Cisco CallManager 4.1. Failing to perform this task causes a loss of CAPF data; for example, you may lose the phone record files in C:\Program Files\Cisco\CAPF\CAPF.phone. If a loss of data occurs, the locally significant certificates that you issued with CAPF utility 1.0(1) remain in the phones; CAPF 4.1(2) must reissue the certificates, which are not valid. Use the following procedure in conjunction with the Migrating Existing CAPF Data section on page 4-6. To copy the files, perform the following procedure: Procedure Step 1 Copy the files in Table 4-2 from the machine where CAPF 1.0 is installed to the publisher database server where Cisco CallManager 4.0 is installed: Table 4-2 Copy From Server to Server From Machine Where Files to Copy CAPF 1.0 Is Installed *.0 in C:\Program Files\Cisco\CAPF CAPF.phone in C:\Program Files\Cisco\CAPF CAPF.cfg files in C:\Program Files\Cisco\CAPF To Publisher Database Server Where Cisco CallManager 4.0 Is Installed to C:\Program Files\Cisco\Certificates to C:\Program Files\Cisco\CAPF to C:\Program Files\Cisco\CAPF Step 2 Upgrade every server in the cluster to Cisco CallManager

88 Chapter 4 Activating the Certificate Authority Proxy Function Service Using the Certificate Authority Proxy Function Step 3 After you upgrade the cluster to Cisco CallManager 4.1, upgrade the Cisco CTL client, and run it before you use the phones. The Cisco CTL client will copy the CAPF certificate to all the servers in the cluster. Step 4 Delete the CAPF utility that you used with Cisco CallManager 4.0. See Table 4-1. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 Migrating Existing CAPF Data, page 4-6 CAPF Configuration Checklist, page 4-7 Activating the Certificate Authority Proxy Function Service Cisco CallManager 4.1 does not automatically activate the Certificate Authority Proxy Function service in Cisco CallManager Serviceability. Activate this service only on the publisher database server. If you did not activate this service before you installed and configured the Cisco CTL client, you must update the CTL file, as described in the Updating the CTL File section on page To activate the service, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 In Cisco CallManager Serviceability, choose Tools > Service Activation. In the pane on the left side of the window, choose the publisher database server. Check the Certificate Authority Proxy Function service check box. Click Update. 4-10

89 Chapter 4 Using the Certificate Authority Proxy Function Updating CAPF Service Parameters CAPF Configuration Checklist, page 4-7 Cisco CallManager Serviceability Administration Guide Cisco CallManager Serviceability Service Guide Updating CAPF Service Parameters If you use Microsoft Certificate Services or Keon Utility to generate certificates, you must update some CAPF service parameters in Cisco CallManager Administration. The CAPF Service Parameter window also provides information on the number of years that the certificate is valid, the maximum number of times that the system retries to generate the key, the key size, and so on. Before the CAPF service parameters will display in Cisco CallManager Administration, you must activate the Certificate Authority Proxy Function service, as described in Activating the Certificate Authority Proxy Function Service section on page To update the CAPF service parameters, perform the following procedure: Procedure Step 1 Step 2 Step 3 In Cisco CallManager Administration, choose Service > Service Parameter. From the Server drop-down list box, choose the publisher database server. From the Service drop-down list box, choose the Cisco Certificate Authority Proxy Function service. Step 4 Update the CAPF service parameters, as described in Table 4-3. Step 5 For the changes to take effect, restart the Cisco Certificate Authority Proxy Function service. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page

90 CAPF Service Parameters Chapter 4 Using the Certificate Authority Proxy Function CAPF Configuration Checklist, page 4-7 Activating the Certificate Authority Proxy Function Service, page 4-10 CAPF Service Parameters, page 4-12 CAPF Service Parameters Use Table 4-3 in conjunction with the Updating CAPF Service Parameters section on page Table 4-3 CAPF Service Parameters Parameter Certificate Issuer Duration of Certificate Validity (years) Key Size (bits) Maximum Allowable Time for Key Generation (minutes) Description From the drop-down list box, choose the entity that will issue the locally significant certificate. Tip If you update this field, you must use the Cisco CTL client to update the CTL file. This field specifies the number of years that the locally significant certificate is valid. A third-party certificate issuer, such as Keon or Microsoft Certificate Services, may have established a different value for this field. The value that these issuers establish does not display in this field. Contact the certificate issuer for more information on the duration of the certificate validity. This field specifies the key size that CAPF will use to generate the CAPF public and private keys. This field specifies the number of minutes during which CAPF attempts to generate the CAPF keys. This parameter also specifies the maximum number of minutes that CAPF waits for a phone to complete the key-generation process. 4-12

91 Chapter 4 Using the Certificate Authority Proxy Function CAPF Service Parameters Table 4-3 CAPF Service Parameters (continued) Parameter Maximum Allowable Attempts for Key Generation Keon Jurisdiction ID SCEP Port Number Certificate Authority Address Description This field specifies the maximum number of attempts that CAPF tries to generate the CAPF keys. This parameter also specifies the maximum number of attempts in which the phone can generate the corresponding keys. This field specifies the Jurisdiction ID that you use with the Keon Utility. This field specifies the SCEP port number for the CAPF server. Enter the IP address of the server where you installed the Microsoft Certificate Services or Keon Utility. If you chose the Cisco Certificate Authority Proxy Server from the Certificate Generation Method drop-down list box, you do not need to enter the IP address of the CAPF server. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page 4-7 Activating the Certificate Authority Proxy Function Service, page 4-10 Updating CAPF Service Parameters, page

92 Updating CAPF Enterprise Parameters Chapter 4 Using the Certificate Authority Proxy Function Updating CAPF Enterprise Parameters The enterprise parameters in Table 4-4 support CAPF. To access the parameters in Cisco CallManager Administration, choose System > Enterprise Parameters. Tip For the changes to take effect, you must reset the phones after you update the parameters. Table 4-4 CAPF Enterprise Parameters Parameter CAPF Phone Port CAPF Operation Expires in (days) Description This parameter specifies the port that the Cisco Authority Proxy Function service uses to request a certificate from the phone. You must restart the Cisco Authority Proxy Function service for the change to take effect. This parameter, which affects all phones that use CAPF, specifies the number of days in which you must complete any CAPF operation; for example, troubleshooting, installing/upgrading, or deleting certificates. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page 4-7 Activating the Certificate Authority Proxy Function Service, page 4-10 Updating CAPF Service Parameters, page

93 Chapter 4 Using the Certificate Authority Proxy Function Installing/Upgrading the Locally Significant Certificates Installing/Upgrading the Locally Significant Certificates Use Table 4-5 as a reference when you use CAPF. Perform the following procedure to use the Certificate Authority Proxy Function: Procedure Step 1 Step 2 In Cisco CallManager Administration, choose Device > Phone. Find the phone where you want to install, upgrade, delete, or troubleshoot the certificate. For information on finding a phone, refer to the Cisco CallManager Administration Guide. Step 3 Enter the configuration settings, as described in Table 4-5. Step 4 Step 5 Step 6 Click Update. Click Reset Phone. If you chose the Install/Upgrade Certificate Operation option and the By Authentication String mode option, you must enter the authentication string on the phone. For information on how to perform this task, see the Entering the Authentication String on the Phone section on page Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Using CAPF with the Bulk Administration Tool, page 4-21 Entering the Authentication String on the Phone, page

94 Deleting the Locally Significant Certificate Chapter 4 Using the Certificate Authority Proxy Function Deleting the Locally Significant Certificate CAPF does not delete certificates that Cisco manufacturing installed in the phone. CAPF only deletes certificates that CAPF or the Cisco-approved, third-party certificate authority issued. Caution If the phone does not contain a manufacture installed certificate (MIC), you must change the device security mode to nonsecure for the phone before you delete the LSC. If you delete the certificate before you change the device security mode, the phone cannot register to Cisco CallManager. For information on changing the device security mode, see the Configuring the Phones for Security section on page 5-1. To delete the certificate from Cisco CallManager Administration instead of from the phone, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 In Cisco CallManager Administration, choose Device > Phone. Find the phone where you want to delete the locally significant certificate. For information on how to find a phone that uses CAPF, refer to the Cisco CallManager Administration Guide. From the Certificate Operation drop-down list box, choose the Delete option. Click Update. Click Reset Phone. If you chose the By Authentication String mode, the user must enter the string to revoke the certificate. If you used a Cisco-approved, third-party certificate authority to issue the certificates, verify that the certificate authority revoked the certificate. Contact the third-party certificate authority vendor for information on how to perform this task. After the certificate authority deletes the certificate from the phone, the Operation Status field in the Phone Configuration window displays Delete Success. 4-16

95 Chapter 4 Using the Certificate Authority Proxy Function Deleting the Locally Significant Certificate Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 Migrating Existing CAPF Data, page 4-6 Activating the Certificate Authority Proxy Function Service, page 4-10 Updating CAPF Service Parameters, page 4-11 CAPF Service Parameters, page 4-12 Installing/Upgrading the Locally Significant Certificates, page 4-15 CAPF Settings in the Phone Configuration Window, page 4-18 Using CAPF with the Bulk Administration Tool, page 4-21 Entering the Authentication String on the Phone, page 4-22 Deleting the Locally Significant Certificate, page

96 CAPF Settings in the Phone Configuration Window Chapter 4 Using the Certificate Authority Proxy Function CAPF Settings in the Phone Configuration Window Table 4-5 describes the CAPF settings in the Phone Configuration window in Cisco CallManager Administration. Table 4-5 Setting Certificate Operation CAPF Configuration Settings Description From the drop-down list box, choose one of the following options: No Pending Operation Displays when no certificate operation is occurring. (default setting) Install/Upgrade Installs a new or upgrades an existing locally significant certificate in the phone. Delete Deletes the locally significant certificate that exists in the phone. Troubleshoot Retrieves the locally significant certificate (LSC) or the manufacture installed certificate (MIC), so you can view the certificate credentials in the CAPF trace file. If both certificate types exist in the phone, Cisco CallManager creates two trace files, one for each certificate type. By choosing the Troubleshooting option, you can verify that a LSC or MIC exists in the phone. 4-18

97 Chapter 4 Using the Certificate Authority Proxy Function CAPF Settings in the Phone Configuration Window Table 4-5 CAPF Configuration Settings (continued) Setting Authentica tion Mode Description This field allows you to choose the method by which you want the phone to authenticate with CAPF. Use this field if you want to install/upgrade, delete, or troubleshoot a locally significant certificate or authenticate by a manufacture-installed certificate. From the drop-down list box, choose one of the following options: By Authentication String Installs/upgrades, deletes, or troubleshoots a locally significant certificate only when the user enters the CAPF authentication string on the phone. By Null String Automatically installs/upgrades, deletes, or troubleshoots a locally significant certificate without user intervention. This option provides no security; Cisco strongly recommends that you choose this option only for closed, secure environments. By Existing Certificate (Precedence to LSC) Automatically installs/upgrades, deletes, or troubleshoots a locally significant certificate if a manufacture-installed (MIC) or locally significant certificate (LSC) exists in the phone. If a LSC exists in the phone, authentication occurs via the LSC, regardless whether a MIC exists in the phone. If a MIC and LSC exist in the phone, authentication occurs via the LSC. If a LSC does not exist in the phone but a MIC does exist, authentication occurs via the MIC. Before you choose this option, verify that a certificate exists in the phone. If you choose this option and no certificate exists in the phone, the operation fails. At any time, the phone uses only one certificate to authenticate to CAPF even though a MIC and LSC can exist in the phone at the same time. If the primary certificate, which takes precedence, becomes compromised for any reason, or, if you want to authenticate via the other certificate, you must update the authentication mode. By Existing Certificate (Precedence to MIC) Automatically installs/upgrades, deletes, or troubleshoots a locally significant certificate if a LSC or MIC exists in the phone. If a MIC exists in the phone, authentication occurs via the MIC, regardless whether a LSC exists in the phone. If a LSC exists in the phone but a MIC does not exist, authentication occurs via the LSC. Before you choose this option, verify that a certificate exists in the phone. If you choose this option and no certificate exists in the phone, the operation fails. 4-19

98 CAPF Settings in the Phone Configuration Window Chapter 4 Using the Certificate Authority Proxy Function Table 4-5 Setting Authentica tion String Generate String Key Size (bits) Operation Completes by Operation Status CAPF Configuration Settings (continued) Description If you chose the By Authentication String option, this field applies. Manually enter a string or generate a string by clicking the Generate String button. Ensure that the string contains 4 to 10 digits. To install, upgrade, delete, or troubleshoot a locally significant certificate, the phone user or administrator must enter the authentication string on the phone. If you want CAPF to automatically generate an authentication string, click this button. The 4- to-10 digit authentication string displays in the Authentication String field. From the drop-down list box, choose the key size for the certificate. The default setting equals Other options include 512 and If you choose a higher key size than the default setting, the phones take longer to generate the entropy that is required to generate the keys. This field, which supports the Install/Upgrade, Delete, and Troubleshoot Certificate Operation options, specifies the date and time by which you must complete the operation. The values that display apply for the publisher database server. This field displays the progress of the certificate operation; for example, <operation type> pending, failed, or successful, where operating type equals the Install/Upgrade, Delete, or Troubleshoot Certificate Operation options. You cannot change the information that displays in this field. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page 4-7 Installing/Upgrading the Locally Significant Certificates, page 4-15 Using CAPF with the Bulk Administration Tool, page 4-21 Entering the Authentication String on the Phone, page 4-22 Deleting the Locally Significant Certificate, page

99 Chapter 4 Using the Certificate Authority Proxy Function Using CAPF with the Bulk Administration Tool Using CAPF with the Bulk Administration Tool If you want to install, upgrade, delete, or troubleshoot many locally significant certificates at the same time, you must use the Cisco Bulk Administration Tool that is compatible with the version of Cisco CallManager that runs in the cluster. Before you use BAT to install or delete certificates, you must activate the Cisco Certificate Authority Proxy Function service. Cisco strongly recommends that you install certificates during a scheduled maintenance window because generating certificates may cause call-processing interruptions. CAPF Configuration Checklist, page 4-7 Activating the Certificate Authority Proxy Function Service, page 4-10 Bulk Administration Tool User Guide Generating a CAPF Report In Cisco CallManager Administration, you can generate a CAPF report to view the certificate operation status, to view the authentication strings, or to view the authentication mode for listed devices. After you generate the CAPF report, you can view the report in a CSV file. To generate a CAPF report, perform the following procedure: Procedure Step 1 Step 2 Step 3 In Cisco CallManager Administration, choose Device > Device Settings > CAPF Report. To find the devices that you want to display in the report, choose the criteria from the Find/List drop-down list boxes. Click Find. A list of devices display. 4-21

100 Finding Phones by Choosing the LSC Status Chapter 4 Using the Certificate Authority Proxy Function Step 4 Step 5 To view the CAPF report in a CSV file, click the View the Report in File link in the upper, right corner of the window. If you want to do so, save the CSV file to a secure location and modify as needed. Certificate Authority Proxy Function Overview, page 4-2 CAPF System Interactions and Requirements, page 4-3 CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Entering the Authentication String on the Phone, page 4-22 Finding Phones by Choosing the LSC Status For information on how to find and list phones by choosing the LSC Status, see the Finding Phones for Authentication, Encryption, and LSC Status section on page 5-8. CAPF Configuration Checklist, page 4-7 Troubleshooting, page 7-1 Entering the Authentication String on the Phone If you chose the By Authentication String mode and generated an authentication string in Cisco CallManager, you must enter the authentication string on the phone before the locally significant certificate installation occurs. Tip The phone user can perform the following procedure to install the certificate. The authentication string applies for one-time use only. 4-22

101 Chapter 4 Using the Certificate Authority Proxy Function Entering the Authentication String on the Phone Before You Begin Verify that the CAPF certificate exists in the CTL file. Verify that the CAPF certificate exists in the certificate folder on the Cisco CallManager server; on the server, browse to C:\Program Files\Cisco\Certificates. Verify that you activated the Cisco Certificate Authority Proxy Function service, as described in Activating the Certificate Authority Proxy Function Service section on page Verify that the publisher database server is functional and running. Ensure that the server runs for each certificate installation. Verify that a signed image exists on the phone; refer to the Cisco IP Phone administration documentation that supports your phone model. Obtain the authentication string that displays in the Phone Configuration window or in the CAPF Report window. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 For the device, obtain the CAPF authentication string from the Phone Configuration window or the CAPF Report window. Verify that the device registers with Cisco CallManager. Verify that the device security mode equals Nonsecure. On nonsecure Cisco IP Phone models 7970, 7960, or 7940, press the Settings button. On the Settings menu, scroll to the Security Configuration option; press the Select softkey. Tip If the phone menu is locked, press **# to unlock the menu. Step 6 Step 7 Scroll to the LSC option; press the Update softkey. Enter the 4 to 10 digit authentication string for the phone and press Submit. Tip If you need to change the authentication string before you press Submit, press <<. 4-23

102 Entering the Authentication String on the Phone Chapter 4 Using the Certificate Authority Proxy Function The phone installs, updates, deletes, or fetches the certificate, depending on the current CAPF configuration. Monitor the progress of the certificate operation by viewing the messages that display on the phone. After you press Submit, the message, Pending, displays under the LSC option. The phone generates the public key and private key pair and displays the information on the phone. When the phone successfully completes the process, the phone displays a successful message. If the phone displays a failure message, you entered the wrong authentication string or did not enable the phone for upgrade; see the Troubleshooting section on page 7-1. At any time, you can stop the process by choosing the Stop option. You can verify that the certificate installed on the phone by choosing Settings > Model Information and viewing the LSC setting, which indicates Installed or Not Installed. CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Using CAPF with the Bulk Administration Tool, page 4-21 Entering the Authentication String on the Phone, page 4-22 Deleting the Locally Significant Certificate, page 4-16 Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Models 7960G and 7940G 4-24

103 CHAPTER 5 Configuring the Phones for Security This chapter contains information on the following topics: Phone Configuration Overview for Security, page 5-2 Installing, Upgrading, Deleting, or Troubleshooting Locally Significant Certificates in Phones, page 5-2 Configuring the Device Security Mode, page 5-3 Configuring the Security Device System Default for Supported Phone Models, page 5-4 Configuring the Device Security Mode for a Single Device, page 5-5 Using the Cisco Bulk Administration Tool to Configure the Device Security Mode, page 5-6 Device Security Mode Configuration Settings, page 5-7 Finding Phones for Authentication, Encryption, and LSC Status, page 5-8 Phone Hardening, page 5-9 Disabling the Gratuitous ARP Setting, page 5-9 Disabling Web Access Setting, page 5-9 Disabling the PC Voice VLAN Access Setting, page 5-10 Disabling the Setting Access Setting, page 5-10 Disabling the PC Port Setting, page 5-11 Performing Phone Hardening Tasks, page

104 Phone Configuration Overview for Security Chapter 5 Configuring the Phones for Security Phone Configuration Overview for Security This section provides an overview of the tasks that you perform to configure security for supported phones: Installing or upgrading locally significant certificates (LSC) on supported phones; deleting or troubleshooting the certificates Configuring supported phones for authentication or encryption through the Device Security Mode Disabling phone settings in Cisco CallManager Administration to harden the phone Installing, Upgrading, Deleting, or Troubleshooting Locally Significant Certificates in Phones, page 5-2 Configuring the Device Security Mode, page 5-3 Device Security Mode Configuration Settings, page 5-7 Finding Phones for Authentication, Encryption, and LSC Status, page 5-8 Phone Hardening, page 5-9 Performing Phone Hardening Tasks, page 5-11 Installing, Upgrading, Deleting, or Troubleshooting Locally Significant Certificates in Phones To install, upgrade, delete, or troubleshoot locally significant certificates in phones, you must configure the CAPF settings in the Phone Configuration window of Cisco CallManager Administration. For information on how to configure CAPF settings, see the Using the Certificate Authority Proxy Function section on page

105 Chapter 5 Configuring the Phones for Security Configuring the Device Security Mode CAPF Configuration Checklist, page 4-7 CAPF System Interactions and Requirements, page 4-3 Configuring the Device Security Mode, page 5-3 Finding Phones for Authentication, Encryption, and LSC Status, page 5-8 Phone Hardening, page 5-9 Performing Phone Hardening Tasks, page 5-11 Troubleshooting, page 7-1 Configuring the Device Security Mode To configure the devices for authentication or encryption, perform one of the following tasks: Configure the default device security mode for supported phone models. Configure the device security mode for a single device in the Phone Configuration window of Cisco CallManager Administration. Configure the device security mode for a supported phone model by using the Cisco Bulk Administration Tool. Tip Before you configure the device security mode, the phone must contain a locally significant certificate or manufacture installed certificate. For information on the device security mode configuration settings, see the Device Security Mode Configuration Settings section on page 5-7. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Activating the Cisco CTL Provider Service, page 3-5 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page

106 Chapter 5 Configuring the Security Device System Default for Supported Phone Models Configuring the Phones for Security Configuring the Device Security Mode, page 5-3 Using the Certificate Authority Proxy Function, page 4-1 Troubleshooting, page 7-1 Configuring the Security Device System Default for Supported Phone Models Note This procedure requires that you reset the devices and restart the Cisco CallManager service for the changes to take effect. In Cisco CallManager Administration, the security device system default for all phone types displays as Non-Secure. To set the security device system default to Authenticated or Encrypted, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 From Cisco CallManager Administration, choose System > Enterprise Parameters. In the Security Parameters section, locate Device Security Mode. From the drop-down list box, choose Authenticated or Encrypted. For more information, see Table 5-1. At the top of the Enterprise Parameters window, click Update. Reset all devices in the cluster; see Resetting Devices, Restarting Services, or Rebooting the Server/Cluster section on page Restart the Cisco CallManager service for the changes to take effect. 5-4

107 Chapter 5 Configuring the Phones for Security Configuring the Device Security Mode for a Single Device System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Configuring the Device Security Mode, page 5-3 Using the Certificate Authority Proxy Function, page 4-1 Configuring the Device Security Mode for a Single Device To configure the device security mode for a single device, perform the following procedure. This procedure assumes that you added the device to the database and installed a certificate in the phone, if a certificate does not already exist. Configuring the Device Security Mode in the Phone Configuration window of Cisco CallManager Administration triggers a rebuild of the device configuration.xml file. After you configure the device security mode for the first time or if you change the device security mode, you must reset the device, so the phone requests the new configuration file. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 In Cisco CallManager Administration, choose Device > Phone. Specify the criteria to find the phone and click Find or click Find to display a list of all phones. If you have not added the phone to the database, the phone does not display in the list. For information on adding a phone, refer to the Cisco CallManager Administration Guide. To open the Phone Configuration window for the device, click the device name. Locate the Device Security Mode drop-down list box. If the phone type does not support security, this option does not display. You cannot configure authentication or encryption for the phone type. From the Device Security Mode drop-down list box, choose the option that you want to configure. See Table 5-1 for information on the options. 5-5

108 Chapter 5 Using the Cisco Bulk Administration Tool to Configure the Device Security Mode Configuring the Phones for Security Step 6 Step 7 The Device Security Mode drop-down list box only displays if the phone supports authentication or encryption. For example, if the phone does not support encryption, the encryption option does not display in the drop-down list box. Click Update. Click Reset Phone. Caution When you reset the phone, the system drops all calls that are occurring through a gateway. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Configuring the Device Security Mode, page 5-3 Using the Certificate Authority Proxy Function, page 4-1 Using the Cisco Bulk Administration Tool to Configure the Device Security Mode You can use the Cisco Bulk Administration Tool that supports Cisco CallManager 4.1(2) to configure the device security mode for specific phone models that support encryption or authentication. For more information on how to perform this task, refer to the Bulk Administration Tool User Guide that supports this version of Cisco CallManager. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Configuring the Device Security Mode, page 5-3 Using the Certificate Authority Proxy Function, page 4-1 Bulk Administration Tool User Guide 5-6

109 Chapter 5 Configuring the Phones for Security Device Security Mode Configuration Settings Device Security Mode Configuration Settings The options in Table 5-1 exist for the device security mode. Table 5-1 Device Security Modes Option Use System Default Non-secure Authenticated Encrypted Description The phone uses the value that you specified for the enterprise parameter, Device Security Mode. No security features except image authentication exist for the phone. A TCP connection opens to Cisco CallManager. Cisco CallManager provides integrity and authentication for the phone. A TLS connection that uses NULL/SHA opens. Cisco CallManager provides integrity, authentication, and encryption for the phone. A TLS connection that uses AES128/SHA opens. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Configuring the Device Security Mode, page 5-3 Using the Certificate Authority Proxy Function, page 4-1 Bulk Administration Tool User Guide 5-7

110 Finding Phones for Authentication, Encryption, and LSC Status Chapter 5 Configuring the Phones for Security Finding Phones for Authentication, Encryption, and LSC Status To find a phone that is associated with the security features, you can choose one of the following criteria in the Phone Find/List window in Cisco CallManager Administration: Device Security Mode Choosing this option returns a list of phones that support authentication or encryption. If you choose this option, you can also specify whether the device is Authenticated or Encrypted. After you click the Find button, the phone model, Device Security Mode, Device Name, Description, Directory Number, Owner User ID, and so on may display (if configured). LSC Status Choosing this option returns a list of phones that use CAPF to install, upgrade, delete, or troubleshoot locally significant certificates. If you choose this option, you can also specify the Certification Operation that is currently performed by CAPF; for example, Operation Pending, Success, Upgrade Failed, Delete Failed, or Troubleshoot Failed. After you click the Find button, the phone model, the LSC Status, Device Name, Description, Directory Number, and the Owner User ID display (if configured). For information on how to find and list phones, refer to the Cisco CallManager Administration Guide. Tip From the Phone Find/List window in Cisco CallManager Administration, you can also delete and reset devices. Cisco CallManager Administration Guide Using the Certificate Authority Proxy Function, page

111 Chapter 5 Configuring the Phones for Security Phone Hardening Phone Hardening To tighten security on the phone, you can perform tasks in the Phone Configuration window of Cisco CallManager Administration. This section contains information on the following topics: Disabling the Gratuitous ARP Setting, page 5-9 Disabling Web Access Setting, page 5-9 Disabling the PC Voice VLAN Access Setting, page 5-10 Disabling the Setting Access Setting, page 5-10 Disabling the PC Port Setting, page 5-11 Disabling the Gratuitous ARP Setting By default, Cisco IP Phones accept Gratuitous ARP, or GARP, packets. GARPs, which are used by devices, announce the presence of the device on the network. However, attackers can use these packets to spoof a valid network device; for example, an attacker could send out a GARP that claims to be the default router. If you choose to do so, you can disable Gratuitous ARP in the Phone Configuration window of Cisco CallManager Administration. Note Disabling GARP does not prevent the phone from identifying its default router. Disabling Web Access Setting Disabling the web server functionality for the phone blocks access to the phone internal web pages, which provide statistics and configuration information. Features, such as Cisco Quality Report Tool, do not function properly without access to the phone web pages. Disabling the web server also affects any serviceability application, such as CiscoWorks, that relies on web access. To determine whether the web services are disabled, the phone parses a parameter in the configuration file that indicates whether the services are disabled or enabled. If the web services are disabled, the phone does not open the HTTP port 80 for monitoring purposes and blocks access to the phone internal web pages. 5-9

112 Phone Hardening Chapter 5 Configuring the Phones for Security Disabling the PC Voice VLAN Access Setting By default, Cisco IP Phones forward all packets that are received on the switch port (the one that faces the upstream switch) to the PC port. If you choose to disable the PC Voice VLAN Access setting in the Phone Configuration window of Cisco CallManager Administration, packets received from the PC port that use voice VLAN functionality will drop. Various Cisco IP Phone models use this functionality differently. Cisco IP Phone models 7940 and 7960 drop any packets tagged with the voice VLAN, in or out of the PC port. Cisco IP Phone model 7970 drops any packet that contains an 802.1Q tag on any VLAN, in or out of the PC port. Cisco IP Phone model 7912 cannot perform this functionality. Disabling the Setting Access Setting By default, pressing the Settings button on a Cisco IP Phone provides access to a variety of information, including phone configuration information. Disabling the Setting Access setting in the Phone Configuration window of Cisco CallManager Administration prohibits access to all options that normally display when you press the Settings button on the phone; for example, the Contrast, Ring Type, Network Configuration, Model Information, and Status settings. The preceding settings do not display on the phone if you disable the setting in Cisco CallManager Administration. If you disable this setting, the phone user cannot save the settings that are associated with the Volume button; for example, the user cannot save the volume. Disabling this setting automatically saves the current Contrast, Ring Type, Network Configuration, Model Information, Status, and Volume settings that exist on the phone. To change these phone settings, you must enable the Setting Access setting in Cisco CallManager Administration. 5-10

113 Chapter 5 Configuring the Phones for Security Performing Phone Hardening Tasks Disabling the PC Port Setting By default, Cisco CallManager enables the PC port on all Cisco IP Phones that have a PC port. If you choose to do so, you can disable the PC Port setting in the Phone Configuration window of Cisco CallManager Administration. Disabling the PC port proves useful for lobby or conference room phones. Interactions and Restrictions, page 1-5 Performing Phone Hardening Tasks, page 5-11 Cisco IP Phone Administration Guide for Cisco CallManager Performing Phone Hardening Tasks Caution The following procedure disables functionality for the phone. Perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 In Cisco CallManager Administration, choose Device > Phone. Specify the criteria to find the phone and click Find or click Find to display a list of all phones. To open the Phone Configuration window for the device, click the device name. Locate the following product-specific parameters: PC Port Settings Access Gratuitous ARP PC Voice VLAN Access Web Access 5-11

114 Performing Phone Hardening Tasks Chapter 5 Configuring the Phones for Security Tip To review information on these settings, click the i button that displays next to the parameters in the Phone Configuration window. Step 5 Step 6 From the drop-down list box for each parameter that you want to disable, choose Disabled. Click Update. Interactions and Restrictions, page 1-5 Disabling the Gratuitous ARP Setting, page 5-9 Disabling Web Access Setting, page 5-9 Disabling the PC Voice VLAN Access Setting, page 5-10 Disabling the Setting Access Setting, page 5-10 Disabling the PC Port Setting, page

115 CHAPTER 6 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference This chapter contains information on the following topics: Overview for Securing the SRST, page 6-1 Secure SRST Configuration Checklist, page 6-3 Configuring Secure SRST References, page 6-4 Security Configuration Settings for SRST References, page 6-6 Overview for Securing the SRST A SRST-enabled gateway provides limited call-processing tasks if the Cisco CallManager cannot complete the call. Secure SRST-enabled gateways contain a self-signed or certificate-authority issued certificate. After you perform SRST configuration tasks in Cisco CallManager Administration, Cisco CallManager uses a TLS connection to authenticate with the Certificate Provider service in the SRST-enabled gateway. Cisco CallManager then retrieves the certificate from the SRST-enabled gateway and adds the certificate to the Cisco CallManager database. 6-1

116 Chapter 6 Overview for Securing the SRST Configuring a Secure Survivable Remote Site Telephony (SRST) Reference After you reset the dependent devices in Cisco CallManager Administration, the TFTP server adds the SRST certificate to the phone cnf.xml file and sends the file to the phone. A secure phone then uses a TLS connection to interact with the SRST-enabled gateway. Tip Cisco CallManager only supports depth-1 chaining for the SRST certificates; that is, the phone configuration file only contains a certificate from a single issuer. HSRP is not supported. Ensure that the following criteria are met, so the TLS handshake occurs between the secure phone and the SRST-enabled gateway: The SRST reference contains a self-signed or certificate-authority issued certificate. You configured the cluster for mixed mode through the Cisco CTL client. You configured the phone for authentication or encryption. You configured the SRST reference in Cisco CallManager Administration. You reset the SRST-enabled gateway and the dependent phones after the SRST configuration. Secure SRST Configuration Checklist, page 6-3 Configuring Secure SRST References, page 6-4 Security Configuration Settings for SRST References, page 6-6 Troubleshooting, page

117 Chapter 6 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference Secure SRST Configuration Checklist Secure SRST Configuration Checklist Use Table 6-1 to guide you through the SRST configuration process for security. Table 6-1 Configuration Checklist for Securing the SRST Configuration Steps Step 1 Step 2 Verify that you performed all necessary tasks on the SRST-enabled gateway, so the device supports Cisco CallManager and security. Verify that you performed all necessary tasks to install and configure the Cisco CTL client. Related Procedures and Topics System administration guide for the Cisco SRST-enabled gateway that supports this version of Cisco CallManager Configuring the Cisco CTL Client, page 3-1 Step 3 Verify that a certificate exists in the phone. Verifying That a Locally Significant Certificate Exists on the Phone, page 7-39 Step 4 Step 5 Step 6 Verify that you configured the phones for authentication or encryption. In Cisco CallManager Administration, configure the SRST reference for security, including enabling the SRST reference in the Device Pool Configuration window. Reset the SRST-enabled gateway and phones. Verifying That a Manufactured-Installed Certificate (MIC) Exists in the Phone, page 7-40 Configuring the Device Security Mode, page 5-3 Configuring Secure SRST References, page 6-4 Configuring Secure SRST References, page

118 Chapter 6 Configuring Secure SRST References Configuring a Secure Survivable Remote Site Telephony (SRST) Reference Configuring Secure SRST References Consider the following information before you add, update, or delete the SRST reference in Cisco CallManager Administration: Adding a Secure SRST Reference The first time that you configure the SRST reference for security, you must configure all settings that are described in Table 6-2. Updating a Secure SRST Reference Performing SRST updates in Cisco CallManager Administration does not automatically update the SRST certificate. To update the certificate, you must click the Update SRST Certificate button; after you click the button, the contents of the certificate display, and you must accept or reject the certificate. If you accept the certificate, Cisco CallManager replaces the SRST certificate in the trust folder on each server in the cluster. Deleting a Secure SRST Reference Deleting a secure SRST reference removes the SRST certificate from the Cisco CallManager database and the cnf.xml file in the phone. To configure a secure SRST reference, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 In Cisco CallManager Administration, choose System > SRST. Perform one of the following tasks: Add a SRST reference for the first time. For information on how to perform this task, refer to the Cisco CallManager Administration Guide. Find the SRST reference that you want to configure for security. For information on finding SRST references, refer to the Cisco CallManager Administration Guide. Use Table 6-2 to update an existing SRST reference for security. Click Insert or Update, depending on whether you added or updated the SRST reference. To update the SRST certificate in the database, click the Update SRST Certificate button. 6-4

119 Chapter 6 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference Configuring Secure SRST References Tip This button displays only when you update an existing SRST reference. Step 5 Step 6 Click Reset Devices. Verify that you enabled the SRST reference in the Device Pool Configuration window. Overview for Securing the SRST, page 6-1 Secure SRST Configuration Checklist, page 6-3 Security Configuration Settings for SRST References, page 6-6 Troubleshooting, page

120 Chapter 6 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference Security Configuration Settings for SRST References Security Configuration Settings for SRST References Use Table 6-2 to configure secure SRST references. Table 6-2 Configuration Settings for Secure SRST References Setting Is SRST Secure? SRST Certificate Provider Port Description After you verify that the SRST-enabled gateway contains a self-signed or certificate-authority issued certificate, check this check box. After you configure the SRST and reset the gateway and dependent phones, the Cisco CTL Provider service authenticates to the Certificate Provider service on the SRST-enabled gateway. The Cisco CTL client retrieves the certificate from the SRST-enabled gateway and stores the certificate in the Cisco CallManager database. Tip To remove the SRST certificate from the database and phone, uncheck this check box, click Update, and reset the dependent phones. This port monitors requests for the Certificate Provider service on the SRST-enabled gateway. Cisco CallManager uses this port to retrieve the certificate from the SRST-enabled gateway. The Cisco SRST Certificate Provider default port equals After you configure this port on the SRST-enabled gateway, enter the port number in this field. Tip You may need to configure a different port number if the port is currently used or if you use a firewall and you cannot use the port within the firewall. 6-6

121 Chapter 6 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference Security Configuration Settings for SRST References Table 6-2 Configuration Settings for Secure SRST References (continued) Setting Update SRST Certificate Description Tip This button displays only for existing secure SRST references. After you click this button, the Cisco CTL client replaces the existing SRST certificate that is stored in the Cisco CallManager database. After you reset the dependent phones, the TFTP server sends the cnf.xml file (with the new SRST certificate) to the phones. Overview for Securing the SRST, page 6-1 Secure SRST Configuration Checklist, page 6-3 Troubleshooting, page

122 Chapter 6 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference Security Configuration Settings for SRST References 6-8

123 CHAPTER 7 Troubleshooting This chapter contains information on the following topics: Using Alarms, page 7-2 Using Microsoft Performance Monitor Counters, page 7-3 Reviewing the Log Files, page 7-3 Troubleshooting HTTPS, page 7-4 Troubleshooting the Cisco CTL Client, page 7-8 Troubleshooting CAPF, page 7-35 Troubleshooting Encryption, page 7-40 Troubleshooting Secure SRST References, page 7-50 Tip This chapter does not describe how to reset the Cisco IP Phone if it has been corrupted by bad loads, security bugs, and so on. For information on resetting the phone, refer to the Cisco IP Phone Administration Guide for Cisco CallManager that matches the model of the phone. This chapter describes how to delete the CTL file from Cisco IP Phone models 7970, 7960, and 7940 only; for information on how to perform this task, see Table 7-4 or the Cisco IP Phone Administration Guide for Cisco CallManager that matches the model of the phone. 7-1

124 Using Alarms Chapter 7 Troubleshooting Using Alarms Cisco CallManager Serviceability generates alarms for the following cases: If an authenticated device attempts to register by using a non-tls SCCP connection, or an unauthenticated phone attempts to register by using a TLS SCCP connection. If the device name in subject line of the peer certificate does not match the the device name that is used for device registration. If device attempts to register to Cisco CallManager by using TLS connection that is not compatible with the Cisco CallManager configuration. Alarms may get generated on the phone under the following conditions: TFTP Not Authorized: <IP address> The phone generates this alarm when the TFTP server information (alternate or otherwise) does not exist in the CTL file. The phone may issue the alarm twice if DHCP has provided primary and backup server addresses and neither address exists in the CTL file. Verify that you entered the CTL file information correctly and that you configured the DHCP server with the correct address. File Auth Failed The phone may generate this alarm for a variety of reasons; for example, the CTL file appears corrupt. If the CTL file is corrupt, you may need to use a sniffer trace to troubleshoot the network. If you cannot identify the problem, you may need to debug by using a console cable, as described in Cisco IP Phone Administration Guide for Cisco CallManager (available for Cisco IP Phone Models 7970, 7960, and 7940, unless otherwise indicated in the administration documentation that supports your phone model). Tip For additional alarms that get generated on the phone, refer to the Cisco IP Phone Administration Guide for Cisco CallManager that matches the model of the phone and to the Troubleshooting the Phone When a Problem Exists with the CTL File section on page

125 Chapter 7 Troubleshooting Using Microsoft Performance Monitor Counters Cisco CallManager Serviceability Administration Guide Cisco CallManager Serviceability System Guide Cisco IP Phone Administration Guide for Cisco CallManager Using Microsoft Performance Monitor Counters Microsoft Performance Monitor counters exist to monitor the number of authenticated phones that register with Cisco CallManager, the number of authenticated calls that are completed, and the number of authenticated calls that are active at any time. Cisco CallManager Serviceability Administration Guide Cisco CallManager Serviceability System Guide Reviewing the Log Files Before you contact the team that provides technical assistance for this product, for example, your Cisco AVVID Partner or the Cisco Technical Assistance Center (TAC), obtain and review the following log files: Cisco CallManager C:\Program Files\Cisco\Trace\CCM TFTP C:\Program Files\Cisco\Trace\TFTP DBL C:\Program Files\Cisco\Trace\DBL C:\Program Files\Cisco\Trace\DBL\DBLR* C:\Program Files\Cisco\Trace\DBL\DBLRT* C:\Program Files\Cisco\Trace\DBL\DBL_CCM* C:\Program Files\Cisco\Trace\DBL\DBL_TFTP* C:\Program Files\Cisco\Trace\DBL\DBL_CTLPROVIDER* 7-3

126 Troubleshooting HTTPS Chapter 7 Troubleshooting Cisco CallManager SDL Traces C:\Program Files\Cisco\Trace\SDL\CCM Tip If the locally significant certificate validation fails, review the SDL trace files. HTTPS C:\program files\common files\cisco\logs\httpscertinstall.log CTL Provider Service C:\Program Files\Cisco\Trace\CTLProvider Cisco CTL client C:\Program Files\Cisco\CTL Client\Trace By default, the Cisco CTL client installs in C:\Program Files\Cisco\CTL File on the server or workstation where the CTL client exists; C:\ctlinstall.log Cisco Certificate Authority Proxy Function (CAPF) service C:\Program Files\Cisco\Trace\CAPF SRST reference winnt\system32\trace Configuring the Cisco CTL Client, page 3-1 Using the Certificate Authority Proxy Function, page 4-1 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), page 2-1 Configuring a Secure Survivable Remote Site Telephony (SRST) Reference, page 6-1 Troubleshooting HTTPS This section provides information on the following topics: Messages That Displays During HTTPS Configuration, page 7-5 Enabling HTTPS, page 7-6 Disabling HTTPS for the Virtual Directory, page

127 Chapter 7 Troubleshooting Troubleshooting HTTPS Messages That Displays During HTTPS Configuration Table 7-1 describes the messages, corrective actions, and reasons for problems that may occur during HTTPS configuration. Table 7-1 Messages that Display During HTTPS Configuration Message The security library has encountered an improperly formatted DER-encoded message. A network error occurred while Netscape was receiving data. (Network Error: Connection refused) Try connecting again. Corrective Action or Reason This error occurs because the certificate that enables the HTTPS service uses the hostname as the subject name of the certificate; Netscape 4.79 considers the underscore in the subject name to be an invalid character, so HTTPS will not work. When the message displays, click OK. For HTTPS support, use Internet Explorer. To use Netscape 4.79 and the hostname to access the application, disable HTTPS, as described in the Disabling HTTPS for the Virtual Directory section on page 7-7. A Cisco CallManager certificate for HTTPS exists on the local Netscape 4.79 browser, but it appears that the Cisco CallManager HTTPS certificate changed. User cannot connect by using the Netscape 4.79 browser. Perform one of the following methods: Use Internet Explorer to access the application. By using Netscape 4.79, choose Communicator -> Tools -> Security Info -> Certificates -> Web sites; highlight the HTTPS certificate for the Cisco CallManager server; click Delete; to confirm, click OK; in the Web Sites Certificates window, click OK. Enabling HTTPS, page 7-6 Deleting the HTTPS Certificate, page

128 Troubleshooting HTTPS Chapter 7 Troubleshooting Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), page 2-1 Enabling HTTPS To enable virtual directories for HTTPS, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Choose Start > Programs > Administrative Tools > Internet Services Manager. Click the name of the server where the HTTPS certificate exists. Click Default Web Site. Click the virtual directory. Right-click Properties. Click the Directory Security tab. Under Secure Communications, click the Edit button. Check the SSL Required check box. Perform this procedure for all virtual directories where you want to enable HTTPS. Enabling HTTPS, page 7-6 Messages That Displays During HTTPS Configuration, page 7-5 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), page

129 Chapter 7 Troubleshooting Troubleshooting HTTPS Disabling HTTPS for the Virtual Directory To disable HTTPS for a virtual directory, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Choose Start > Programs > Administrative Tools > Internet Services Manager. Click the name of the server where the HTTPS certificate exists. Click Default Web Site. Click the virtual directory; for example, CCMAdmin. Right-click Properties. Click the Directory Security tab. Under Secure Communications, click Edit. Uncheck the SSL Required check box. Perform this task for each virtual directory: CCMAdmin, CCMService, CCMUser, AST, BAT, RTMTReports, CCMTraceAnalysis, CCMServiceTraceCollectionTool, PktCap, and ART. Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), page 2-1 Deleting the HTTPS Certificate, page 7-8 Enabling HTTPS, page

130 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Deleting the HTTPS Certificate To delete the HTTPS certificate, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Choose Start > Programs > Administrative Tools > Internet Services Manager. Click the name of the server where the HTTPS certificate exists. Click the Directory Security tab. Under Secure Communications, click the Server Certificate button. Click Next. Choose Remove the Current Certificate. Click Next. Click Finish. Enabling HTTPS, page 7-6 Messages That Displays During HTTPS Configuration, page 7-5 Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), page 2-1 Troubleshooting the Cisco CTL Client The section contains information on the following topics: Changing the Security Token Password (Etoken), page 7-9 Troubleshooting a Locked Security Token After You Consecutively Enter an Incorrect Security Token Password, page 7-10 Setting the Smart Card Service to Started and Automatic, page 7-11 Messages for the Cisco CTL Client, page

131 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Troubleshooting the Phone When a Problem Exists with the CTL File, page 7-25 Comparing CTL File Versions on the Cisco IP Phone and Server, page 7-27 Deleting the CTL File on the Cisco IP Phone, page 7-28 Deleting the CTL File on the Server, page 7-29 Troubleshooting If You Lose One Security Token (Etoken), page 7-31 Troubleshooting If You Lose All Security Tokens (Etoken), page 7-32 Verifying or Uninstalling the Cisco CTL Client, page 7-34 Verifying the Security Mode for the Cisco CallManager Cluster, page 7-33 Changing the Security Token Password (Etoken) This administrative password retrieves the private key of the certificate and ensures that the CTL file gets signed. Each security token comes with a default password. You can change the security token password at any time. If the Cisco CTL client prompts you to change the password, you must change the password before you can proceed with the configuration. To review pertinent information on setting passwords, click the Show Tips button. If you cannot set the password for any reason, review the tips that display. To change the security token password, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Verify that you have installed the Cisco CTL client on a Windows 2000 server or workstation. If you have not already done so, insert the security token into the USB port on the Windows 2000 server or workstation where you installed the Cisco CTL client. Choose Start > Programs > etoken > Etoken Properties; right-click etoken and choose Change etoken password. In the Current Password field, enter the password that you originally created for the token. Enter a new password. 7-9

132 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Step 6 Step 7 Enter the new password again to confirm it. Click OK. Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Cisco CTL Client Configuration Settings, page 3-19 Troubleshooting a Locked Security Token After You Consecutively Enter an Incorrect Security Token Password Each security token contains a retry counter, which specifies the number of consecutive attempts to log in to the etoken Password window. The retry counter value for the security token equals 15. If the number of consecutive attempts exceeds the counter value, that is, 16 unsuccessful consecutive attempts occur, a message indicates that the security token is locked and unusable. You cannot reenable a locked security token. Obtain additional security token(s) and configure the CTL file, as described in Configuring the Cisco CTL Client section on page If necessary, purchase new security token(s) to configure the file. Tip After you successfully enter the password, the counter resets to zero. Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Cisco CTL Client Configuration Settings, page

133 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Setting the Smart Card Service to Started and Automatic If the Cisco CTL client installation detects that the Smart Card service is disabled, you must set the Smart Card service to automatic and started on the server or workstation where you are installing the Cisco CTL plug-in. Tip You cannot add the security tokens to the CTL file if the service is not set to started and automatic. After you upgrade the operating system, apply service releases, upgrade Cisco CallManager, and so on, verify that the Smart Card service is started and automatic. To set the service to started and automatic, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 On the server or workstation where you installed the Cisco CTL client, choose Start > Programs > Administrative Tools > Services. From the Services window, right-click the Smart Card service and choose Properties. In the Properties window, verify that the General tab displays. From the Startup type drop-down list box, choose Automatic. Click Apply. In the Service Status area, click Start. Click OK. Reboot the server or workstation and verify that the service is running. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Activating the Cisco CTL Provider Service, page

134 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Activating the Cisco CTL Provider Service, page 3-5 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Configuring the Device Security Mode, page 5-3 Messages for the Cisco CTL Client Table 7-2 provides the messages that may display and the corresponding corrective actions/reasons for the Cisco CTL client. Table 7-2 Messages for the Cisco CTL Client Message Unknown CTL Error Invalid Port number Invalid Range for port numbers Could not write information to the local Windows Registry Invalid Group Name Invalid User Name Corrective Action or Reason Internal CTL error occurred. Review the CTL logs for errors. Enter a valid port number, which must comprise numbers only. Specify the correct range. Valid port numbers range from 1026 and The CTL client does not have access to the registry. Verify that you logged in by using the local administrator or local power users account. The Cisco CTL client does not save the server name, port, and administrator name with subsequent logins. The CTL Provider service cannot retrieve Windows 2000 User Groups where the user belongs. Verify that you logged in by using the local administrator or local power users account. You did not enter a valid user name. The user name field appears blank, or the name exceeds the maximum number of characters. Enter a valid user name. 7-12

135 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Table 7-2 Messages for the Cisco CTL Client (continued) Message Invalid IP Address Invalid Hostname User could not be authenticated Invalid Password Cannot run CTL Client from Terminal Services Failed to create CTL File Please insert a Security Token. Click Ok when done Cannot create CTL Entries. Total number of CTL Records has exceeded the Maximum Unable to create CTL Entry Corrective Action or Reason You did not enter a valid IP address. Ensure that the address exists in the X.X.X.X format and contains the valid IP range. Enter a valid IP address. You did not enter a valid hostname. The server name field remains blank, or it includes more than the maximum number of allowed characters. Enter the valid hostname. You entered the wrong password for the specified user name. Enter the correct password. You entered an invalid password. Either the password is blank, or the password exceeds the maximum number of allowed characters. Enter the correct password. The CTL client does not work with Terminal Services. You must configure the client on the machine where you installed the application. After the error occurs, a dialog box, which displays in the CTL client window, lists the servers and failure reason. Insert a security token and click OK. If the message continues to display, restart the Etoken Notification service on the client machine. The CTL file contains more than the maximum number of certificates or entries that are allowed in the file. Delete servers or etokens that are not required. The maximum limit equals 100. CTL File exceeded maximum file size limit. Maximum file size equals 75K. Consider deleting security tokens or alternate TFTP server entries that you no longer use. 7-13

136 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Table 7-2 Messages for the Cisco CTL Client (continued) Message Unable to parse CTL File CTL Client version is not compatible with the CTL Provider Please select an item to delete Error occurred when creating Dialog Corrective Action or Reason System could not parse CTL file. The CTL file appears corrupt. On all servers in the cluster, determine whether someone tampered with or replaced the CTL file. Tip You can connect to the subscriber server from the CTL client to retrieve the CTL file from the subscriber server. If file is corrupt on subscriber servers, delete the existing CTL file and create a new file. If the CTL file does not appear to be corrupt on the subscriber server, manually copy the file to the publisher; before you copy the file, verify that you have the latest CTL file. Compare the version of the CTL client and the version of Cisco CallManager. Run the Cisco CTL client that displays in Cisco CallManager Administration 4.1. In the CTL Entries window, choose an entry before you click Delete. Insufficient system memory exists. Free up memory resources and rerun the CTL client. --- No Issuer Name--- In nonsecure mode, the CTL Entries window displays the issuer name as No Issuer Name. This message indicates that the application will write a null issuer name to the CTL file because the file exists in nonsecure mode. --- No Subject Name--- In nonsecure mode, the CTL Entries window displays the subject name as No Subject Name. This message indicates that the application will write a null issuer name to the CTL file because the file exists in nonsecure mode. 7-14

137 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Table 7-2 Messages for the Cisco CTL Client (continued) Message You cannot delete this item. You can only delete Security Tokens and multi-cluster TFTP Are you sure you want to delete this item? You have selected to exit the CTL Client application. Are you sure you want to exit? You must have at least 2 security tokens in the CTL File You must have at least one CallManager server in the cluster Could not get CallManager Certificate from server <server name> Entry for Server already exists. No Help available. Corrective Action or Reason In the CTL Entries window, you can delete security tokens and alternate TFTP servers only. This message displays before you delete an entry from the CTL Entries window. This message displays when you click Cancel or exit from any Cisco CTL client windows. Before you click Finish to sign the CTL file, verify that at least two security tokens exist in the CTL Entries pane. Before you click Finish to sign the CTL file, verify that one Cisco CallManager server (with function CCM+TFTP) exists in the CTL Entries pane. Perform the following tasks: 1. Verify that you have network connectivity to the Cisco CallManager server. 2. Verify that the Cisco CTL client connects to the port where the Cisco CTL Provider service is configured. 3. Verify that the Cisco CallManager self-signed certificate exists in c:\program files\cisco\certificates\ccmserver.cer. 4. In Cisco CallManager Serviceability, enable detailed traces for the Cisco CTL Provider service and review the traces for that service. An entry for the server already exists in the CTL file. Online help does not exist for this window. 7-15

138 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Table 7-2 Messages for the Cisco CTL Client (continued) Message No CTL File exists on the server but the CallManager Cluster Security Mode is in Mixed Mode. You must create the CTL File and set Call Manager Cluster to Mixed Mode. The CTL File signature is invalid or the CTL File is corrupt. You must recreate the CTL File. All existing certificate information in the CTL file will be lost. There are no Security Tokens in CTL File. You must have at least 2 security tokens. Select Update CTL File to add security Tokens. Please insert a Security Token. Click Ok when done. Please insert another Security Token. Click Ok when done. The Security Token you have inserted already exists in the CTL File. Corrective Action or Reason This message displays if someone manually deletes or tampers with the CTL file. All data in the CTL file, including certificate and security token information, not longer exists in the file. Re-create the CTL file. The CTL file appears corrupt. All data in the CTL file, including certificate and security token information, not longer exists in the file. Re-create the CTL file. Re-create the CTL file by running the Cisco CTL client. This message displays if CTL file is corrupt or invalid or if the CTL client cannot read the security token information. The CTL file must contain entries for at least two security tokens. Choose the Update CTL File option and re-create the CTL file. Insert a Cisco security token in the USB port. Click OK. If this message continues to display, verify that Cisco issued the security token and that the Etoken Notification and Smart Card services are running. To add a new token to the CTL file, insert a Cisco security token in the USB port. Click OK. If this message continues to display, verify that Cisco issued the security token and that the Etoken Notification and Smart Card services are running. The security token information already exists in the CTL file. Insert a token that does not already exist in the file. 7-16

139 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Table 7-2 Messages for the Cisco CTL Client (continued) Message The Security Token cannot be used to sign the CTL File. The token must already exist in the CTL file. No CTL File. Error opening CTL File. Error reading CTL File. CTL Filename or contents are invalid. CTL File is not valid. CTL File created successfully. CTL File operation was not successful on one or all the servers. Please correct the error and run the CTL Client again. You must restart all the CallManager and TFTP nodes in the Cluster. No Valid Server Certificate found. Corrective Action or Reason You must sign the CTL file by inserting a token that already exists in the file. CTLFile.tlv does not exist. The application cannot open CTLFile.tlv. Review the Cisco CTL Provider service traces. The system could not read CTLFile.tlv. Review the Cisco CTL Provider service traces. The CTL file name appears invalid, or the CTL File contents appear invalid. Verify that CTLFile.tlv exists in the TFTP service parameter FileLocation path and review the Cisco CTL Provider service traces. The CTL file appears corrupt or invalid. Review the Cisco CTL Provider service traces. The CTL File exists in the TFTPPath location. Verify the server name, path, and error reason in the CTL client window where this error displays. After you create the CTL file, restart the Cisco CallManager and TFTP services on all servers in the cluster that run the services. Likewise, reset the devices. The application cannot read the security token certificate. Verify that the Cisco issued the security token and verify that the token is valid. 7-17

140 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Table 7-2 Messages for the Cisco CTL Client (continued) Message No Server Certificate File found. Server Certificate is Invalid. Certificate Date Invalid. Certificate expired. Certificate is not of type RSA. No Issuer Name in Certificate. Issuer name is not valid. Invalid Issuer Name length. Corrective Action or Reason The application cannot read certificate file from the Cisco CallManager server. Verify that c:\program files\cisco\certificiates\ccmserver.cer exists. The application detects that an invalid Cisco CallManager certificate exists. Verify that c:\program files\cisco\certificiates\ccmserver.cer exists. Review the Cisco CTL Provider service traces. The application detects that the certificate contains an invalid date. Review the Cisco CTL Provider service traces. In the Security Token Information window in the Cisco CTL client, review the valid from and valid up to dates for the security token certificate. The certificate expired. Review the Cisco CTL Provider service traces. Review the certificate for the security token. The Cisco CallManager certificate does not use the RSA type. Double-click ccmserver.cer. In the Certificate Details window, verify that the public key specifies RSA. If not, you have an invalid Cisco CallManager server certificate. The certificate does not contain an issuer name. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate issuer name appears invalid. Review the Cisco CTL Provider service traces. Review the certificate for the security token. The certificate issuer name length exceeds 256 characters. Review the Cisco CTL Provider service traces. Review certificate for the security token. 7-18

141 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Table 7-2 Messages for the Cisco CTL Client (continued) Message No Subject Name in Certificate. Corrective Action or Reason The certificate does not contain a subject name. Review the Cisco CTL Provider service traces. Review certificate for the security token. Subject name is not valid. The certificate subject name appears invalid. Review the Cisco CTL Provider service traces. Review certificate for the security token. Invalid Subject Name length. No Public Key in Certificate. Public Key is not valid. The certificate subject name exceeds 256 characters. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate does not contain a public key. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate public key appears invalid. Review the Cisco CTL Provider service traces. Review certificate for the security token. Invalid Public Key length. The certificate public key length exceeds 512 characters. Review the Cisco CTL Provider service traces. Review certificate for the security token. No Private Key File. Private Key File is not valid. Invalid Cipher for Private key. The certificate does not contain a private key. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate private key appears invalid. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate private key cipher appears invalid. Review the Cisco CTL Provider service traces. Review certificate for the security token. Invalid Signature length. The certificate signature length exceeds 1024 characters. Review the Cisco CTL Provider service traces. Review certificate for the security token. Invalid Signature Algorithm. The certificate signature algorithm appears invalid. Review the Cisco CTL Provider service traces. Review certificate for the security token. 7-19

142 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Table 7-2 Messages for the Cisco CTL Client (continued) Message No Signature. Invalid Thumbprint. Invalid Serial Number. Invalid Serial Number length. Error Opening Security Token Store. No Certificate in Security Token. Could not Sign Message. Corrective Action or Reason The certificate does not contain a signature. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate thumbprint appears invalid. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate serial number appears invalid. Review the Cisco CTL Provider service traces. Review certificate for the security token. The certificate serial number exceeds 256 characters. Review the Cisco CTL Provider service traces. Review certificate for the security token. The application cannot read the security token certificate. Verify that the Etoken Notification and Smart card services are running. The security token contains no certificate. Verify that Cisco issued the security token. The Cisco CTL client cannot sign the contents of the CTL file. Review the Cisco CTL client traces; run the Cisco CTL client again. Could not verify Message. The Cisco CTL client cannot verify the signature after signing the contents of the CTL file. Review the Cisco CTL client traces; run the Cisco CTL client again. Could not sign CTL File. Review the Cisco CTL client traces; run the Cisco CTL client again. 7-20

143 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Table 7-2 Messages for the Cisco CTL Client (continued) Message For the security of the phones, tokens inserted during update cannot be used to sign the CTL File. You must use one of the tokens that already existed in the CTL file to sign. Once this token has been inserted and the phones have been restarted, you may use the new tokens to sign the CTL File. Error Initializing SDI Control. Corrective Action or Reason The message provides the corrective action. Fatal error occurred in initializing tracing for CTL Provider. Configure a trace in Cisco CallManager Serviceability. DBL Exception occurred. Fatal error occurred in initializing Database layer for CTL Provider. Review the DBL logs for exceptions. CM Name is too long. The Cisco CallManager hostname that you entered exceeds 256 characters. Enter the hostname again. Init TLS Failed. TLS Connect Error when Opening Sockets. Error occurred during SSL Handshake. Could not connect to CTL provider Service. The application cannot initialize SSL between the Cisco CTL client and the Cisco CTL Provider service. Review the Cisco CTL client traces; run the Cisco CTL client again. Review the Cisco CTL client traces; run the Cisco CTL client again. Review the Cisco CTL client traces; run the Cisco CTL client again. Verify that the Cisco CTL Provider hostname where the client connects is valid and accessible. Verify that the CTL provider listens on the port where the client connects. 7-21

144 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Table 7-2 Messages for the Cisco CTL Client (continued) Message Parsing data from CTLProvider failed. Error occurred during Post CTL File operation. Error occurred during Get CAPF File operation. Error occurred during Get CCM Certificate operation. Error occurred during Get CAPF Certificate operation. Error occurred during Authenticate User operation. Invalid Response for Authenticate User operation. Invalid Response for Get CCM List operation. Invalid Response for Get CCM Certificate operation. Corrective Action or Reason An internal error occurred. The Cisco CTL client received invalid data from the Cisco CTL Provider service. An internal error occurred when the Cisco CTL client attempted to copy the CTL file to the servers in the cluster. An internal error occurred when the Cisco CTL client attempted to retrieve files from the certificate trust list folder. An internal error occurred when the Cisco CTL client attempted to retrieve the Cisco CallManager certificate. An internal error occurred when the Cisco CTL client attempted to retrieve the CAPF certificate. An internal error occurred when the Cisco CTL client attempted to authenticate user. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration

145 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Table 7-2 Messages for the Cisco CTL Client (continued) Message Invalid Response for Get CAPF Certificate operation. Invalid Response for get CTL File operation. Invalid Response for Get CAPF File operation. Invalid Response for Get Cluster Security Mode operation. Invalid Response for Get CTL Version operation. Invalid Response for Get Alternate Paths operation. Invalid Response for Authenticate User operation. Not enough Memory to run Application. Corrective Action or Reason The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. The Cisco CTL client version appears incompatible with the Cisco CTL Provider service. Install and configure the Cisco CTL client plug-in that displays in Cisco CallManager Administration 4.1. You cannot execute the Cisco CTL client because the system has insufficient system memory. Free up memory resources and rerun the Cisco CTL client. 7-23

146 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Table 7-2 Messages for the Cisco CTL Client (continued) Message Could not get CAPF Certificate(s). CAPF Service seems to be running on the CCM Publisher but the certificate file(s) do not exist in the Certificates trust path. Please check if the following certificates exist. Entry for this certificate already exists. Failed to set Cluster Security Mode on the CallManager publisher. You must run the CTL Client again to set the correct value for the Cluster Security Mode. The Alternate TFTP Server entry is invalid. You must delete the entry for the Alternate TFTP Server and add it again Corrective Action or Reason If you activated the CAPF Service on the publisher database server, verify that the capf.cer and the corresponding capf (.0) files exist in the certificates trust folder. Verify that the alternate TFTP server does not already exist in the CTL file. The CTL client cannot set the Cluster Security Mode to the correct value. The message provides the corrective action. Delete the alternate TFTP server entry from the Cisco CTL Entries pane and add the entry again. Failing to perform this task may cause the phones to fail to register. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Reviewing the Log Files, page

147 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Troubleshooting the Phone When a Problem Exists with the CTL File Table 7-3 describes problems that may exist with the CTL file on the phone. To perform the corrective actions in Table 7-3, obtain one security token that exists in the CTL file. To update the CTL file, see the Updating the CTL File section on page Table 7-3 CTL File Problems That Affect the Phone Problem Possible Cause Corrective Action Phone cannot Consider the following causes: authenticate CTL file. Phone cannot authenticate any configuration files other than the CTL file. Phone reports TFTP authorization failure. The security token that signed the updated CTL file does not exist in the CTL file on the phone. You attempted to add new security tokens to the existing CTL file. You attempted to sign the CTL file with the last token that was added to the file. The existing CTL file on the phone may not contain a record for the new security token. Update the CTL file, and sign the CTL file by using a security token that exists in the file. If the problem persists, delete the CTL file from the phone, and run the Cisco CTL client again. An incorrect TFTP entry exists in the CTL file. Update the CTL file. Consider the following causes: The TFTP address for the phone does not exist in the CTL file. If you created a new CTL file with a new TFTP record, the existing CTL file on the phone may not contain a record for the new TFTP server. Update the CTL file. If the new CTL file contains different TFTP information than the existing CTL file on the phone, delete the existing CTL file from the phone; see the Deleting the CTL File on the Cisco IP Phone section on page

148 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Table 7-3 CTL File Problems That Affect the Phone (continued) Problem Possible Cause Corrective Action Phone does not register with Cisco CallManager. Phone does not interact with the correct CAPF server to obtain the locally significant certificate. A TLS handshake error occurs. Phone does not request signed configuration files. The CTL file does not contain the correct information for the Cisco CallManager server. Auto-registration may be enabled. The CAPF certificate changed since the last update of the CTL file. The CTL file contains a TFTP entry that does not have a certificate with it. Verify that auto-registration is disabled. Update the CTL file. Update the CTL file. Update the CTL file. When you update the CTL file, verify that you set the Cisco CallManager clusterwide security mode to Mixed Mode. System Requirements, page 1-4 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Reviewing the Log Files, page

149 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Comparing CTL File Versions on the Cisco IP Phone and Server You can identify the version of the CTL file on the phone by calculating the MD5 hash, which is a cryptographic hash that is computed on the file contents. On the phone, an option exists for CTL file; this option provides the MD5 hash value. An MD5 application allows you to compute the MD5 hash of files on disc. When you compare the hash values for saved CTL files on disc with the value that displays on the phone, you can determine which version is installed on the phone. After you determine the version of the CTL file that exists on the phone, you can run an MD5 check on the server CTL file to verify that the phone uses the correct CTL file. To compute the MD5 value, perform the following procedure: Procedure Step 1 Step 2 On the server where the CTL file exists, open the command window, cd c:\program files\cisco\bin\ To compute the MD5 value for a file, enter MD5UTIL.EXE <drive:><path><filename>. Tip The variables, <drive:><path> <filename>, specify the drive, directory, and/or file for which you want to compute the MD5 value. To view this description in the CLI, enter md5util -?. For example, to compute the MD5 value for the CTL file, enter MD5UTIL.exe c:\program files\cisco\tftppath\ctlfile.tlv. Activating the Cisco CTL Provider Service, page 3-5 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Cisco CTL Client Configuration Settings, page

150 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Deleting the CTL File on the Cisco IP Phone Caution Cisco recommends that you perform this task in a secure lab environment, especially if you do not plan to delete the CTL file from the Cisco CallManager servers in the cluster. Delete the CTL file on the Cisco IP Phone if the following cases occur: You lose all security tokens that signed the CTL file. The security tokens that signed the CTL file appear compromised. You move a phone out of a secure cluster; for example, to a storage area, to a nonsecure cluster, or to another secure cluster in a different domain. You move a phone from an area with an unknown security policy to a secure cluster. You change the alternate TFTP server address to a server that does not exist in the CTL file. 7-28

151 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client To delete the CTL file on the Cisco IP Phone, perform the tasks in Table 7-4. Table 7-4 Deleting the CTL File on the Cisco IP Phone Cisco IP Phone Model Cisco IP Phones 7960 and 7940 Cisco IP Phone 7970 Tasks Under the Security Configuration menu on the phone, press CTL file, unlock or **#, and erase. Perform one of the following methods: Unlock the Security Configuration menu, as described in Cisco IP Phone Administration Guide for Cisco CallManager. Under the CTL option, press the Erase softkey. Under the Settings menu, press the Erase softkey. Note Pressing the Erase softkey under the Settings menu deletes other information besides the CTL file. For additional information, refer to the Cisco IP Phone Administration Guide for Cisco CallManager. System Requirements, page 1-4 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Reviewing the Log Files, page 7-3 Deleting the CTL File on the Server Delete the CTL file that exists on the server if the following cases occur: You lose all security tokens that signed the CTL file. The security tokens that signed the CTL file appear compromised. 7-29

152 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Tip Remember to delete the file from all servers in the cluster where the Cisco CallManager or Cisco TFTP services run. To delete the CTL file, perform the following procedure: Procedure Step 1 Step 2 Step 3 Browse to C:\Program Files\Cisco\tftppath (the default location) or to the location where you saved the CTLFile.tlv. Right-click CTLFile.tlv and choose Delete. Perform this procedure on all servers in the cluster where the Cisco CallManager and Cisco TFTP services run. System Requirements, page 1-4 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Reviewing the Log Files, page

153 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Troubleshooting If You Lose One Security Token (Etoken) If you lose one security token, perform the following procedure: Procedure Step 1 Step 2 Step 3 Purchase a new security token. Using a token that signed the CTL file, update the CTL file by performing the following tasks: a. Add the new token to the CTL file. b. Delete the lost token from the CTL file. For more information on how to perform these tasks, see the Updating the CTL File section on page Reset all phones, as described in Resetting Devices, Restarting Services, or Rebooting the Server/Cluster section on page System Requirements, page 1-4 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Reviewing the Log Files, page

154 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting Troubleshooting If You Lose All Security Tokens (Etoken) Tip Perform the following procedure during a scheduled maintenance window because you must reboot all servers in the cluster for the changes to take effect. If you lose the security tokens and you need to update the CTL file, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 On every Cisco CallManager, Cisco TFTP, or alternate TFTP server, browse to directory where the file, CTLFile.tlv, exists. The following location designates the default directory: C:\program files\cisco\tftppath. To identify where you stored the CTL file, locate the File Location service parameter for the TFTP service in the Service Parameters window of Cisco CallManager Administration. Delete CTLFile.tlv. Repeat Step 1 and Step 2 for every Cisco CallManager, Cisco TFTP, and alternate TFTP server. Obtain at least two new security tokens. By using the Cisco CTL client, create the CTL File, as described in Installing the Cisco CTL Client section on page 3-8 and Configuring the Cisco CTL Client section on page Tip If the clusterwide security mode exists in mixed mode, the Cisco CTL client displays the message, No CTL File exists on the server but the CallManager Cluster Security Mode is in Mixed Mode. For the system to function, you must create the CTL File and set CallManager Cluster to Mixed Mode." Click OK; then, choose Set Call Manager Cluster to Mixed Mode and complete the CTL file configuration. 7-32

155 Chapter 7 Troubleshooting Troubleshooting the Cisco CTL Client Step 6 Step 7 After you create the CTL file on all the servers, delete the CTL file from the phone, as described in Deleting the CTL File on the Cisco IP Phone section on page Reboot all the servers in the cluster. System Requirements, page 1-4 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Reviewing the Log Files, page 7-3 Verifying the Security Mode for the Cisco CallManager Cluster To verify the security mode for the Cisco CallManager cluster, perform the following procedure: Procedure Step 1 From Cisco CallManager Administration, choose System > Enterprise Parameters. Step 2 Locate the Cluster Security Mode field. If the value in the field displays as 1, you correctly configured the Cisco CallManager cluster for mixed mode. Tip You cannot configure this value in Cisco CallManager Administration. This value displays after you configure the Cisco CTL client. 7-33

156 Troubleshooting the Cisco CTL Client Chapter 7 Troubleshooting System Requirements, page 1-4 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page 3-16 Reviewing the Log Files, page 7-3 Verifying or Uninstalling the Cisco CTL Client Uninstalling the Cisco CTL client does not delete the CTL file. Likewise, the clusterwide security mode and the CTL file do not change when you uninstall the client. If you choose to do so, you can uninstall the CTL client, install the client on a different Windows 2000 workstation or server, and continue to use the same CTL file. To verify that the Cisco CTL client installed, perform the following procedure: Procedure Step 1 Step 2 Step 3 Step 4 Choose Start > Control Panel > Add Remove Programs. Double-click Add Remove Programs. To verify that the client installed, locate Cisco CTL Client. To delete the client, click Remove. System Requirements, page 1-4 Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Updating the CTL File, page

157 Chapter 7 Troubleshooting Troubleshooting CAPF Reviewing the Log Files, page 7-3 Determining the Cisco CTL Client Version To determine which version of the Cisco CTL client you are using, perform the following procedure: Procedure Step 1 Step 2 Step 3 Perform one of the following tasks: Double-click the Cisco CTL Client icon that exists on the desktop. Choose Start > Programs > Cisco CTL Client. In the Cisco CTL client window, click the icon in the upper, left corner of the window. Choose About Cisco CTL Client. The version of the client displays. Activating the Cisco CTL Provider Service, page 3-5 Installing the Cisco CTL Client, page 3-8 Configuring the Cisco CTL Client, page 3-11 Troubleshooting CAPF This section contains information on the following topics: Messages for CAPF, page 7-36 Troubleshooting the Authentication String on the Phone, page 7-37 Troubleshooting If the Locally Significant Certificate Validation Fails, page 7-38 Verifying That the CAPF Certificate Installed on All Servers in the Cluster, page

158 Troubleshooting CAPF Chapter 7 Troubleshooting Verifying That a Locally Significant Certificate Exists on the Phone, page 7-39 Verifying That a Manufactured-Installed Certificate (MIC) Exists in the Phone, page 7-40 Messages for CAPF Table 7-5 displays messages and corrective actions for CAPF: Table 7-5 Messages for CAPF Message Authentication String contains one or more invalid characters. Valid characters for Authentication String are numbers. CAPF Authentication String length should be between 4 and 10. Operation Completes By contains one or more invalid characters. Valid characters for Operation Completes By are numbers. Invalid Year. Please enter a value equal to or greater than the current year. Invalid Month. Please adjust your entry to continue. Invalid Date. Please enter a value equal to or greater than the current date. Invalid Date. Please adjust your entry to continue. Corrective Action Enter the appropriate information as described in the message. The range for the authentication string no fewer than 4 and no more than 10 digits. Enter the appropriate information. Enter the appropriate information as described in the message. The message provides the corrective action. The message provides the corrective action. You entered a past date. Enter the appropriate date. You entered a date that is not valid for the month. Enter the appropriate date. 7-36

159 Chapter 7 Troubleshooting Troubleshooting CAPF Table 7-5 Messages for CAPF (continued) Message Invalid Time. Please enter a value equal to or greater than current time (hours). Invalid Time. Please adjust your entry to continue. Corrective Action You enter a past time. Enter the appropriate time. The message provides the corrective action. System Requirements, page 1-4 Interactions and Restrictions, page 1-5 Certificate Authority Proxy Function Overview, page 4-2 CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Entering the Authentication String on the Phone, page 4-22 Troubleshooting the Authentication String on the Phone If you incorrectly enter the authentication string on the phone, a message displays on the phone. Enter the correct authentication string on the phone. Tip Verify that the phone is registered to the Cisco CallManager. If the phone is not registered to the Cisco CallManager, you cannot enter the authentication string on the phone. Verify that the device security mode for the phone equals nonsecure. CAPF limits the number of consecutive attempts in which you can enter the authentication string on the phone. If you have not entered the correct authentication string after 10 attempts, wait at least ten minutes before you attempt to enter the correct string again. 7-37

160 Troubleshooting CAPF Chapter 7 Troubleshooting Entering the Authentication String on the Phone, page 4-22 CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Troubleshooting If the Locally Significant Certificate Validation Fails On the phone, the locally significant certificate validation may fail if the certificate is not the version that CAPF issued, the certificate has expired, the CAPF certificate does not exist on all servers in the cluster, the CAPF certificate does not exist in the CAPF directory, the phone is not registered to Cisco CallManager, and so on. If the locally significant certificate validation fails, review the SDL trace files and the CAPF trace files for errors. Entering the Authentication String on the Phone, page 4-22 CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Reviewing the Log Files, page 7-3 Certificate Authority Proxy Function Overview, page 4-2 Verifying That the CAPF Certificate Installed on All Servers in the Cluster After you activate the Cisco Certificate Authority Proxy Function service, CAPF automatically generates a key pair and certificate that is specific for CAPF. The CAPF certificate, which the Cisco CTL Client copies to all servers in the cluster, 7-38

161 Chapter 7 Troubleshooting Troubleshooting CAPF uses the.0 extension. To verify that the CAPF certificate exists, browse to C:\Program Files\Cisco\Certificates on each server in the cluster and locate the following files: In DER encoded format CAPF.cer In PEM encoded format.0 extension file that contains the same common name string as the CAPF.cer Entering the Authentication String on the Phone, page 4-22 CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Verifying That a Locally Significant Certificate Exists on the Phone You can verify that the locally significant certificate installed on the phone by choosing Settings > Model Information and viewing the LSC setting. The LSC setting displays Installed or Not Installed, depending on the circumstances. Entering the Authentication String on the Phone, page 4-22 CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page

162 Troubleshooting Encryption Chapter 7 Troubleshooting Verifying That a Manufactured-Installed Certificate (MIC) Exists in the Phone You can verify that a MIC exists in the phone by choosing the MIC option on the Security Configuration menu on the phone. The setting states Installed or Not Installed, depending on the circumstances. CAPF Configuration Checklist, page 4-7 CAPF Settings in the Phone Configuration Window, page 4-18 Reviewing the Log Files, page 7-3 Certificate Authority Proxy Function Overview, page 4-2 Troubleshooting Encryption This section contains information on the following topics: SRTP/SCCP Troubleshooting Overview, page 7-41 Configuration Checklist for Packet Capturing, page 7-42 Configuring Packet Capturing Service Parameters, page 7-43 Packet Capturing Service Parameters, page 7-44 Configuring BAT for Packet Capturing, page 7-45 Configuring Packet Capturing in the Phone Configuration Window, page 7-45 Packet Capturing Phone Configuration Settings, page 7-47 Analyzing Captured Packets, page 7-48 Messages for Packet Capturing in Cisco CallManager Administration, page 7-49 Message for Encryption and Barge Configuration, page

163 Chapter 7 Troubleshooting Troubleshooting Encryption SRTP/SCCP Troubleshooting Overview Because third-party troubleshooting tools that sniff media and TCP packets do not work after you enable encryption, you must use Cisco CallManager Administration to perform the following tasks if a problem occurs: Analyze TCP packets for SCCP messages that are exchanged between Cisco CallManager and the device. Capture the SRTP packets between the devices. Extract the media encryption key material from SCCP messages and decrypt the media between the devices. Configuration Checklist for Packet Capturing, page 7-42 Packet Capturing Service Parameters, page 7-44 Packet Capturing Phone Configuration Settings, page 7-47 Analyzing Captured Packets, page 7-48 Messages for Packet Capturing in Cisco CallManager Administration, page

164 Troubleshooting Encryption Chapter 7 Troubleshooting Configuration Checklist for Packet Capturing Extracting and analyzing pertinent data includes performing the following tasks in Table 7-6: Table 7-6 Configuration Checklist for Packet Capturing Configuration Steps Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Enable packet capturing in the Service Parameter window in Cisco CallManager Administration. If you do not want to use the default settings for the service parameters. update other applicable service parameters in the Service Parameter window. Configure packet capturing on a per-device basis in the Phone Configuration window. Note Cisco strongly recommends that you do not enable packet capturing for many devices at the same time because this task may cause high CPU usage in your network. After you capture the packets, set the Signal Packet Capture Mode to None and the Packet Capture Enable service parameter to False. Gather the files that you need to analyze the packets. Cisco Technical Assistance Center (TAC) analyzes the packets. Contact TAC directly to perform this task. Related Procedures and Topics Configuring Packet Capturing Service Parameters, page 7-43 Packet Capturing Service Parameters, page 7-44 Configuring Packet Capturing Service Parameters, page 7-43 Packet Capturing Service Parameters, page 7-44 Configuring Packet Capturing in the Phone Configuration Window, page 7-45 Packet Capturing Phone Configuration Settings, page 7-47 Configuring Packet Capturing Service Parameters, page 7-43 Packet Capturing Service Parameters, page 7-44 Analyzing Captured Packets, page 7-48 Analyzing Captured Packets, page

165 Chapter 7 Troubleshooting Troubleshooting Encryption Configuring Packet Capturing Service Parameters Perform the following procedure to configure parameters for packet capturing: Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 In Cisco CallManager Administration, choose Service > Service Parameters. From the Server drop-down list box, choose a server where you activated the Cisco CallManager service. From the Service drop-down list box, choose the Cisco CallManager service. Scroll to the Packet Capture parameters and configure the settings, as described in Table 7-8. For the changes to take effect, click Update. To continue packet capturing configuration, see the Configuring Packet Capturing in the Phone Configuration Window section on page Configuration Checklist for Packet Capturing, page 7-42 Packet Capturing Service Parameters, page

166 Troubleshooting Encryption Chapter 7 Troubleshooting Packet Capturing Service Parameters Use Table 7-7 in conjunction with the Configuring Packet Capturing Service Parameters section on page Table 7-7 Packet Capturing Configuration Settings Parameter Packet Capture Enable Packet Capture Service Listen TLS Port Packet capture Max real time Client Connections Packet Capture Max File Description This parameter enables packet capturing over a TLS connection. For information on the default value, click the i button that displays in the Service Parameter window. This port accepts requests from real-time debugging tools for capturing packets over a TLS connection. For information on the default value, click the i button that displays in the Service Parameter window. This parameter specifies the maximum number of connections from real-time debugging tools that you can use to capture packets. For information on the default value, click the i button that displays in the Service Parameter window. This parameter specifies the maximum size for the packet capture file that is created by Cisco CallManager during batch mode debugging. Cisco CallManager stops writing to the file after the maximum value is reached. For information on default and maximum values, click the i button that displays in the Service Parameter window. Configuration Checklist for Packet Capturing, page 7-42 Configuring Packet Capturing Service Parameters, page 7-43 Packet Capturing Phone Configuration Settings, page

167 Chapter 7 Troubleshooting Troubleshooting Encryption Configuring BAT for Packet Capturing By using the Bulk Administration Tool that is compatible with this Cisco CallManager release, you can configure the Packet Capture mode. For information on how to perform this task, refer to the Bulk Administration Tool User Guide. Tip Performing this task in BAT may cause high CPU usage and call-processing interruptions. Cisco strongly recommends that you perform this task when you can minimize call-processing interruptions. Bulk Administration Tool User Guide SRTP/SCCP Troubleshooting Overview, page 7-41 Configuration Checklist for Packet Capturing, page 7-42 Configuring Packet Capturing in the Phone Configuration Window After you enable packet capturing in the Service Parameter window, you must configure packet capturing on a per-device basis in the Phone Configuration window of Cisco CallManager Administration. You enable or disable packet capturing on a per-device basis. The default setting for packet capturing equals None. 7-45

168 Troubleshooting Encryption Chapter 7 Troubleshooting Tip Cisco strongly recommends that you do not enable packet capturing for many devices at the same time because this task may cause high CPU usage in your network. If you do not want to capture packets or if you completed the task, set the Signal Packet Capture Mode to None and the Packet Capture Enable service parameter to False. Procedure Step 1 Step 2 Step 3 In Cisco CallManager Administration, choose Device > Phone. Specify the criteria to find the phone and click Find or click Find to display a list of all phones. If you have not added the phone to the database, the phone does not display in the list. For information on adding a phone, refer to the Cisco CallManager Administration Guide. To open the Phone Configuration window for the device, click the device name. Step 4 Configure the troubleshooting settings, as described in Table 7-8. Step 5 Step 6 Click Update. Click Reset Phone. Resetting phones causes active calls over the device to drop. Packet Capturing Phone Configuration Settings, page 7-47 Configuration Checklist for Packet Capturing, page

169 Chapter 7 Troubleshooting Troubleshooting Encryption Packet Capturing Phone Configuration Settings Use Table 7-8 in conjunction with the Configuring Packet Capturing in the Phone Configuration Window section on page Table 7-8 Packet Capturing Phone Configuration Settings Setting Signal Packet Capture Mode Packet Capture Duration Description Choose one of the following options from the drop-down list box: Real-Time Mode Cisco CallManager sends decrypted or nonencrypted messages over a secure channel to analyzing devices. A TLS connection opens between Cisco CallManager and the TAC debugging tool. After authentication occurs, Cisco CallManager sends the SCCP messages to all connected real-time debugging tools; this action occurs only for the chosen devices where you configured packet capturing. This mode eliminates sniffing over the network. The TAC debugging tool captures the SRTP packets and decrypts the packets by using the key material that is extracted from the encrypted SCCP messages. You must run the debugging tool on the debugging site. Batch Processing Mode Cisco CallManager writes the decrypted or nonencrypted messages to file, and the system encrypts each file. On a daily basis, the system creates a new file with a new encryption key. Cisco CallManager, which stores the file for seven days, also stores the keys that encrypt the file in a secure location. Cisco CallManager stores the file in C:\Program Files\Cisco\PktCap. A single file contains the time stamp, source IP address, destination IP address, SCCP message length, and the SCCP message.the debugging tool uses HTTPS, administrator username and password, and the specified day to request a single encrypted file that contains the captured packets. Likewise, the tool requests the key information to decrypt the encrypted compressed file. Before you contact TAC, you must capture the SRTP packets by using a sniffer trace between the affected devices. This field specifies the maximum number of minutes that is allotted for one session of packet capturing. The default equals

170 Troubleshooting Encryption Chapter 7 Troubleshooting Configuration Checklist for Packet Capturing, page 7-42 Analyzing Captured Packets, page 7-48 Configuring Packet Capturing in the Phone Configuration Window, page 7-45 Messages for Packet Capturing in Cisco CallManager Administration, page 7-49 Analyzing Captured Packets Cisco Technical Assistance Center (TAC) analyzes the packets by using a debugging tool. Before you contact TAC, capture SRTP packets by using a sniffer trace between the affected devices. Contact TAC directly after you gather the following information: Packet Capture File name or IP address>/pktcap/pktcap.asp?file=mm-dd-yyyy.pkt, where you browse into the server and locate the packet capture file by month, date, and year (mm-dd-yyyy) Key for the file name or IP address>pktcap/pktcap.asp?key=mm-dd-yyyy.pkt, where you browse into the server and locate the key by month, date, and year (mm-dd-yyyy) Administrative username and password for the Cisco CallManager server Configuration Checklist for Packet Capturing, page 7-42 Packet Capturing Phone Configuration Settings, page 7-47 Messages for Packet Capturing in Cisco CallManager Administration, page

171 Chapter 7 Troubleshooting Troubleshooting Encryption Messages for Packet Capturing in Cisco CallManager Administration Table 7-9 provides a list of messages that could display when you configure packet capturing in Cisco CallManager Administration. Table 7-9 Messages for Packet Capturing Message Packet Capture Duration contains one or more invalid characters. Valid characters for Packet Capture Duration are numbers. Invalid Packet Capture Duration. Packet Capture Duration should be between 0 and 300. Corrective Action The message provides the corrective action. Enter the appropriate information, as described in the message. Packet Capturing Phone Configuration Settings, page 7-47 Configuration Checklist for Packet Capturing, page 7-42 Message for Encryption and Barge Configuration Use the following information in conjunction with the Interactions and Restrictions section on page 1-5. When you attempt to configure barge for Cisco IP Phone models 7960 and 7940 that are configured for encryption, the following message displays: If you configure encryption for Cisco IP Phone models 7960 and 7940, those encrypted devices cannot accept a barge request when they are participating in an encrypted call. When the call is encrypted, the barge attempt fails. 7-49

172 Troubleshooting Secure SRST References Chapter 7 Troubleshooting The message displays when you perform the following tasks in Cisco CallManager Administration: In the Phone Configuration window, you choose Encrypted for the Device Security Mode (or System Default equals Encrypted), On for the Built In Bridge setting (or default setting equals On), and you click Insert or Update after you create this specific configuration. In the Enterprise Parameter window, you update the Device Security Mode parameter. In the Service Parameter window, you update the Built In Bridge Enable parameter. Tip For changes to take effect, you must reset the dependent Cisco IP devices. Interactions and Restrictions, page 1-5 Encryption Overview, page 1-18 Where to Find More Information, page 1-24 Troubleshooting Secure SRST References This section contains information on the following topics: Security Message That Displays During SRST Reference Configuration, page 7-51 Troubleshooting When the SRST Certificate Is Deleted From the Gateway, page 7-51 Deleting Security from the SRST Reference To make the SRST reference nonsecure after you configure security, uncheck the Is the SRTS Secure? check box in the SRST Configuration window in Cisco CallManager Administration. A message states that you must turn off the credential service on the gateway. 7-50

173 Chapter 7 Troubleshooting Troubleshooting Secure SRST References Configuring a Secure Survivable Remote Site Telephony (SRST) Reference, page 6-1 Cisco CallManager Administration Guide System administration documentation that supports the SRST-enabled gateway and this version of Cisco CallManager Security Message That Displays During SRST Reference Configuration The following message may display when you configure secure SRST references in Cisco CallManager Administration. The message reads, Port Numbers can only contain digits. This message displays if you enter an invalid port number when you configure the SRST Certificate Provider Port. The port number must exist in the range of 1024 and Configuring a Secure Survivable Remote Site Telephony (SRST) Reference, page 6-1 Cisco CallManager Administration Guide System administration documentation that supports the SRST-enabled gateway and this version of Cisco CallManager Troubleshooting When the SRST Certificate Is Deleted From the Gateway If the SRST certificate no longer exists in the SRST-enabled gateway, you must remove the SRST certificate from the Cisco CallManager database and the phone. To perform this task, uncheck the Is the SRST Secure? check box and click Update in the SRST Configuration window. Then, click Reset Devices. 7-51

174 Troubleshooting Secure SRST References Chapter 7 Troubleshooting Configuring a Secure Survivable Remote Site Telephony (SRST) Reference, page 6-1 Cisco CallManager Administration Guide System administration documentation that supports the SRST-enabled gateway and this version of Cisco CallManager 7-52

175 INDEX A authentication configuring devices for 3 device security mode configuration settings (table) 7 installation 13 interactions 5 overview 16 restrictions 5 authentication string 2 C Certificate Authority Proxy Function (CAPF) authentication string 2 authentication string entered incorrectly on phone 37 Cisco CallManager Serviceability configuration 5 Cisco CAPF service 6 configuration checklist (table) 7 configuration settings (table) 18 deleting locally significant certificate 16 entering authentication string on phone 22 enterprise parameter configuration settings (table) 14 finding phones that use CAPF 22 generating a report 21 installing/upgrading locally significant certificates 15 interactions and requirements 3 messages 36 migrating existing data 9 overview 2 service parameter configuration settings (table) 12 service parameter procedure 11 verifying CAPF certificate installation 38 verifying manufacture-installed certificate exists 40 verifying the locally significant certificate installation 39 certificates types 14 Cisco CTL client changing security token password 9 Cisco CAPF service 6 Cisco CTL Provider service 5 comparing CTL files 27 configuration checklist (table) 3 configuration settings (table) 19 IN-1