07-11-2014 10:26 AM - edited 03-17-2019 04:19 PM
Hi all, Looking for some help regarding a Jabber issue we are having. Currently have a UC 9 environment running and Jabber is fully operational; once you accept the certificates on the device. Our issue is that we are using publicly trusted certificates, with the entire chain loaded on the all the servers and in the PC's. As I understand it a public certificate should not need accepting, the Cisco documentation states "Note: In the case of a Public CA, the root certificate should already be in the client trust store."
I have checked everything is in place, the certificate chain is correct within the Windows PC's, the trusted root certificate is in the store as well as the intermediary. When I view the certificate from my Windows Jabber client it says the certificate is ok, but still asks me to accept? Is this the default behaviour? I can't see any way around it. Adding more complexity, from my web browser I do not have to accept the certificate, the site is coming through as trusted! Which makes me think this is a Jabber specific issue and not my certificates
On a side note, when we try to login via Jabber for iphone we are not even getting prompted to accept a certificate. We are just being told the certificate is not trusted. Any input on this would be appreciated
CUCM version 9.1.2.11900-12
IM&P version 9.1.1.41900-1
Thanks, Jamie
07-11-2014 11:20 AM
If you open the cert you need to accept, does it look OK? does it find the root cert in your PC?
07-11-2014 11:38 AM
Yep the entire chain is there and looking all the way through all are ok
07-11-2014 01:51 PM
Hi Jamie,
Did you confirm that the name on the certificate(s) matches the name(s) configured for those services on the CUP (Jabber) server? If you go to the Jabber main window and navigate to Help > Show Connection Status, you'll see the name or IP address of each service listed in the "Address" field. The string in this field must match the string in the certificates, otherwise they will not be trusted by the client. You can either update the service addresses on the CUP server to match the existing certificates, or you can request from your CA to get an alias (subject alternative name) added to the certificates that matches the names used on the CUP server.
For example, if your domain is domain.com, and your CM server name is CMSERVER, your CM tomcat certificate may only have "CMSERVER" as the name. Then, if your CUP server is configured to use "CMSERVER.domain.com" for phone control services, that doesn't match the name on the certificate and now Jabber will throw the error on logon.
Fyi: You can view the name on the cert by hitting the server from a web browser (since these are tomcat certs we're talking about) and then viewing the certificate via the browser when it prompts you to accept it. I hope this helps, best of luck.
-Cal
07-14-2014 02:18 AM
Hi Cal
All the services are configured to point to the FQDN, we have used the FQDN throughout the entire implementation. All certificates are signed to the FQDN
I don't understand why Jabber refuses to see the certificate as valid when a browser will show everything as OK...
Thanks
07-14-2014 07:18 AM
Who is your public CA?
07-15-2014 01:10 AM
We are using Terena SSL certificates. These should be ok?
07-15-2014 08:38 AM
Well, I do not believe Terena is a trusted root CA by Windows natively, so I would treat this as an internal CA and follow the reccommendations for that configuration. Do not assume the CA will be trusted by the client as would be the case for say, GoDaddy or VeriSign or Entrust, for example.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide