Welcome Message

Hello my dear reader,

Welcome to my blog, which is dedicated to Cisco technologies. On its pages we will talk about the limitless world of telephony and networking.

We will focus mostly on Cisco collaboration solutions and technologies. These are IP PBX based on Cisco Unified Communications Manager and Cisco Unified Communications Manager Express, Cisco contact centers, Cisco Voice Gateways, etc. Also, I will introduce you the education news: Cisco authorized courses, my own developed training programs, our upcoming events, online learning.

If you have any questions regarding my posts, job or activities, please feel free to ask your questions. I will try to answer them when I have time.

If you are satisfied with the content of my blog, isn’t that worth a beer or coffee? Donations help me to continue supporting the blog and creating new posts here — things for which I spend hours of my free time! Thank you very much!

Sincerely, Dmytro Benda

Monday, September 24, 2018

SSL Issue (CVP OAMP to Call Server Connection)

Recently, one of our customers complained to us about the "unusual" problem from his point of view, which he met in the Cisco Voice Portal (CVP). When he tried to save changes for the Call Server configuration, the Web Management Console (OAMP) returned the following error:

Call Server device with IP Address: <x.x.x.x> and Hostname: <server1> operation failed. Device could not be reached because of a failure in negotiating security certificates. Please refer to documentation for configuring security before trying the operation again.
On the OAMP console it looked like this:


The error message itself indicates the reason of the problem: all this happens because of incorrect certificate exchange. In addition, the message shows that the Call Server can not be reached by the management console. With further investigation of the problem, it was found that the administrator checked the secure connection mode check-box to enable secure sessions between the Call Server and the OAMP console:



However, before enabling the secure connection mode, it was necessary to exchange the appropriate security certificates between the CVP components. The procedure for exchanging certificates is described in detail here:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/cvp10_5/configuration/guide/CCVP_BK_1A06EB0D_00_1005-cvp-configuration-and-administration/CCVP_BK_1A06EB0D_00_1005-cvp-configuration-and-administration_chapter_01111.pdf


The exchange of certificates had not been performed before the security connection mode was enabled. Because of this reason, the error mentioned also occurred, since, indeed, the management console "did not see" the Call Server (connection to it is impossible due to the lack of the required certificate). An attempt to disable the secure connection setting checkbox did not fix the problem, because the system can not apply the changes from OAMP.

The solution to the problem was found on Cisco's docwiki:

http://docwiki.cisco.com/wiki/Call_Server:_SSL_Recovery


To restore communication between the management console and Call Server, you need to do the following:

1. Open the desktop of the Call Server via RDP.

2. Open the folder with configuration files of the Call Server (C:\Cisco\CVP\conf) and find the file orm_jmx.properties


3. In this file have a look to the property named com.sun.management.jmxremote.ssl. As you can see from the following screenshot, it was set to true after the administrator checked the secure connection checkbox.


Change this property to false. This will cancel the secure connection enabled earlier. Having restored the connection to the normal mode, the administrator can then install the required certificates and then enable the required safe mode, or continue working in the normal mode.
   

4. The modified file must be saved and then the Call Server must be restarted in order for the changes to take effect.

After a reboot, the connection between the management console and Call Server returns to the usual unsecure mode. Next, you can work with the system in the usual way: make settings, save and apply them without having an SSL error.

This is how the problem was solved and our customer was really satisfied. Well, we received additional useful experience and recorded another row to our knowledge base)

No comments:

Post a Comment