解决IP电话不能访问企业/个人目录的最佳实践

下载选项

PDF (160.6 KB)
在各种设备上使用 Adobe Reader 查看
ePub (41.5 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (61.1 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2012 年 1 月 18 日

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

当地语言翻译版本说明

思科可能会在某些地方提供本内容的当地语言翻译版本。请注意，翻译版本仅供参考，如有任何不一致之处，以本内容的英文版本为准。

技术领域

CUCM 8.X, IP phone 7945, 7965, 7975

问题描述

用户最近完成了CUCM到8.X的升级，从此访问企业目录或者个人目录时，电话上显示主机不能被找到 (host not found)。此类问题只发生在7945等第三代电话上，而IP communicator不受影响。

背景介绍

从CUCM 8.X开始，CUCM引入了security by default的特性，通过https来加密IP电话和CUCM之间的通讯，从而用户在IP电话上输入的敏感信息不再担心被破解。

IP电话基于证书的信任关系来建立会话，但由于IP phone本身不存储https 服务器端的证书，所以他第一次建立会话时会向 CUCM上的 TVS (Trust Verification Service)请求证书验证，如果TVS信任当前的https服务器端的证书，IP phone就会信任此证书从而成功建立https会话，反之则会话建立失败。

问题分析

1. 从IP电话端的日志，我们可以确认IP Phone是否向TVS发起了证书验证请求，并且获得TVS认证的结果。

4166: NOT 14:52:33.535327 SECD: tvsBldMsg: The request id in the TVS request sent out is 1016
4167: NOT 14:52:33.537241 SECD: initiateTvsCertAuth: Successfully sent the certificate
Authentication request to TVS server, bytes written : 694
4168: NOT 14:52:33.539301 SECD: initiateTvsCertAuth: Done sending Certificate Validation request
4169: NOT 14:52:33.542561 SECD: sendTvsClientReqToSrvr: Authenticate Certificate : request sent to TVS server - waiting for
response
4174: NOT 14:52:33.558630 SECD: processTvsSrvrResponse: Success reading the message from the TVS server, len : 14
4175: NOT 14:52:33.559513 SECD: tvsDecodeSrvrResponse: messageType : 2, requestid : 1016,messageLen : 4
4176: NOT 14:52:33.563023 SECD: tvsDecodeSrvrResponse: status : 1, certLen : 0
4178: NOT 14:52:33.564833 SECD: processTvsSrvrResponse: Authentication Response received,status : 1
4179: ERR 14:52:33.565741 SECD: EROR:processTvsSrvrResponse: Authentication Response received with status failure

上面的错误表明TVS不信任当前IP phone发送过来的证书，此证书即当前CUCM的tomcat 证书，文件名 tomcat.pem

2. 其次，我们从TVS的日志分析入手，查看为什么此证书不被信任

14:52:33.917 |-->debug
14:52:33.917 |   debug CertificateDBCache::getCertificateInformation - Looking up the certificate cache using Unique MAP ID : 53F15E319C7734063566E7BCFF370AC BCN=UCMA;OU=SJC;O=SJC;L=SJC;ST=SJC;C=US
14:52:33.917 |<--debug
14:52:33.917 |-->debug
14:52:33.917 |   debug ERROR:CertificateDBCache::getCertificateInformation - Cannot find the certificate in the cache

上面的错误表明当前的CUCM数据库中并不存在此证书。

3. 通过重新生成tomcat.pem和重新启动tomcat service，此问题得以解决。

最佳实践

1. 检查当前CUCM的TVS 是否正常运行。

2. 如果曾经更新过tomcat证书，重新启动相应CUCM服务器的Tomcat服务以确保服务器端使用的是最新的证书。（在CUCM的OS administration, Security, certificate management菜单下）

3. 如果当前Tomcat证书不被TVS信任，可重启TVS服务或重新生成tomcat证书并重新启动tomcat. （在CUCM的命令行下可以重启Tomcat服务，admin: utils service restart Cisco Tomcat）