cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Jabber phone control stopped working following cucm upgrade.

MrStinch01
Beginner
Beginner

I upgrade our Callmanager 11.5 clusters to 14.0.1 at the weekend, which went well.

Users reported on Monday they could no longer control their Cisco desk phones via Jabber 14.0.3. The computer soft phone worked, and signing into Jabber worked. Logged a TAC case and from the Jabber logs it was identified as problem with LDAP authentication. Our LDAP authentication servers in cucm  use port 3269 and have TLS enabled. So as a test I disable TLS and changed the port to 3268. This allowed desk phone control straight away. Cisco TAC said I had to log another case adjust Callmanager. I've done done this but still awaiting an initial response.

Looking at the CTI logon callmanager I can see:- 

Failed Due To : error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate)
00028718.055 |06:54:12.594 |AppInfo |Authenticating with SSL enabled (1)-(ldaps://serverhostname:3269)
00028718.056 |06:54:12.594 |AppInfo |LDAP initialize with SSL Return Code (0)
00028718.057 |06:54:12.594 |AppInfo |setting LDAP option LDAP_OPT_X_TLS_HARD
00028718.058 |06:54:12.594 |AppInfo |authenticationLDAPConfig::getLDAPConnectionTimeout():enter
00028718.059 |06:54:12.595 |AppInfo |ldapConnectionTimeout = 5
00028718.060 |06:54:12.596 |AppInfo |LDAP set LDAP_OPT_NETWORK_TIMEOUT option set to 5 seconds
00028718.061 |06:54:12.596 |AppInfo |Setting the REBIND function
00028718.062 |06:54:12.597 |AppInfo |LDAP authentication bind failed. LDAP code: -1
00028718.063 |06:54:12.597 |AppInfo |Connection # (1): failed (-1) ((null))
00028718.064 |06:54:12.597 |AppInfo |Details :: serverhostname 3269
00028718.065 |06:54:12.597 |AppInfo |------------------------------------------------------------------------
00028718.066 |06:54:12.597 |AppInfo |Failed Due To : error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate)
00028718.067 |06:54:12.597 |AppInfo |authenticationLDAP::Authenticate():exit AUTH_NOT_INITIALIZED
00028718.068 |06:54:12.597 |AppInfo |authenticationLDAP.cpp: Error on authentication. LDAP error code: -1
00028718.069 |06:54:12.597 |AppInfo |authenticationLDAP::connect():Exit on Error
00028718.070 |06:54:12.597 |AppInfo |LDAP Connect: Returned from connect with rc: -1
00028718.071 |06:54:12.597 |AppInfo |Failure to initialize (connect) to LDAP server.
00028718.072 |06:54:12.597 |AppInfo |authenticationLDAP::authenticateUserWithPassword():Exit on LDAP error: -1
00028718.073 |06:54:12.597 |AppInfo |authenticationDB::login (Done Authenticating using LDAP)
00028718.074 |06:54:12.597 |AppInfo |authenticationDB::login (LDAP FAILED) (-1)

 

Any ideas what certificate is being used for phone control. Logging into Jabber, and 'Use my computer' for 'Device for calls' in Jabber work fine with the TLS setting enabled. As mentioned only a problem since upgrading from cucm 11.5 to 14.0.1. Even knowing what the process is for Device control authentication of a desk phone would help me with knowing where to look.

1 ACCEPTED SOLUTION

Accepted Solutions

MrStinch01
Beginner
Beginner

Cisco TAC found the answer. We were hitting https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa26458  based on similar behaviors and based on the error : Failed Due To : error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate)  , and we needed to regenerate the tomcat-ECDSA in the publisher node only followed by a server reboot . Though it did worked without the reboot, which I still did as part of my change.

View solution in original post

3 REPLIES 3

MrStinch01
Beginner
Beginner

Cisco TAC found the answer. We were hitting https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa26458  based on similar behaviors and based on the error : Failed Due To : error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate)  , and we needed to regenerate the tomcat-ECDSA in the publisher node only followed by a server reboot . Though it did worked without the reboot, which I still did as part of my change.

Thank you for your post, I can confirm that it is working without doing the reboot but I did it too just in case.

Thank you for posting this!   Hitting the exact same after upgrading to 14.0.1 SU1.  

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: