Jabber Certificate invalid on MAC OSX

[chino.galaz]

Anyone know how to fix this issue with certificates not being trusted on MAC OS for Cisco Jabber? Specifically the Unity Connection certificate. I have a TAC case opened and have been told several times that the Unity certificate needs to be installed manually. I find this to be a bit awkward given CUCM and IM&P are not giving me the same certificate invalid prompt.

[Jaime Valencia]

That has been the case for a very long time and is well documented in the Jabber docs

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/12_8/cjab_b_planning-guide-cisco-jabber-128/cjab_b_planning-guide-cisco-jabber-128_chapter_0110.html#CJAB_RF_C47367A0_00

Either you tell the users to accept the certificates so they're added to the trust store from their machine, or you distribute them via a GPO. If the certs are not present in the trust store, you get the message, and that is working as designed.

If you're not getting the certificate warning for CUCM/IM&P, that's because those certs are already in your trust store, look in there and you should see them. And if you were to renew those certs on your servers, then you would get the certificate warning once again because you don't have those new certs in your machine.

[Sankar Voleti]

Hi,

  If you are still experiencing this issue, some of the possible causes could be:

1. UCxN's Tomcat certificate is either self-signed or not signed by a well known public CA that is trusted by MAC OS.

2. UCxN is not presenting the whole certificate chain (server certificate + Root certificate) to the Jabber client. It must be sending its own (server) certificate instead.

Do you know if the Tomcat certificate of CUCM, IM&P and UCxN are signed by the same certificate authority? If they are signed by different CAs, then perhaps the root certificate the CA that signed CUCM and Presence is there in the keychain but not that of the one UCxN's signer. Also, do you have a chance to test the same behaviour with Jabber Windows client?

If you would like to troubleshoot this issue, just take a Wireshark capture on the MAC when you're signing-in into the Jabber client. Then, filter it with port 8443 that the client uses for its https requests to the UC servers. You should be able to locate the TLS handshake between Jabber and UCxN on the above port during which the server sends its certificate in the 'Server Hello' message. You can easily check if it sent the whole chain as I said above or just its certificate alone.

Note - If you have already accepted the certificate manually when prompted by the Jabber client, you will not see the pop-up anymore unless the certificate is deleted manually from the keychain.

Hope this helps!

-Sankar

[chino.galaz]

Hello Sankar,

My Unity cluster is signed by a well known CA (InCommon) and all my Cisco UC apps are signed by InCommon as well. My Windows customers are not experiencing the same certificate prompt as MAC users. I had actually taken a wireshark capture on my MAC Jabber client and I can see what certificate it doesn't trust. I opened a TAC case and the engineer tried uploading the certificate in question then in the end, came back and stated that the certificate needed to be uploaded manually for MAC clients. I wasn't feeling to confident in that response, so I decided to reopen and re-queue but the other TAC engineer who took on the case came back with the same response and provided documentation on how MAC certificates needed to be uploaded manually. This is quite the opposite of what they talked about at CiscoLive. We shouldn't have our customers seeing certificate trust warnings/exceptions and to get our certificates signed by a well known CA and properly exchanged.

[Sankar Voleti]

Hello Chino,

        The recommendation from the TAC team that worked with you is relevant from Jabber application's perspective :). But I agree with you on the fact that no manual intervention should be required especially if the deployment base is huge. What version of UCxN are you running? If it is 12.5, was it upgraded from a previous version like 11.X? I worked on a case not so long ago in which the symptom was exactly the same as you are experiencing - UCxN's Tomcat certificate is not trusted by the Jabber MAC client while it worked just fine on the Windows platform.

Apparently, the underlying OS platform behaves differently. Windows OS platform might have a mechanism to build the chain even if the server is not sending the entire chain which is why you don't experience this issue. But, Jabber as an application relies on the trust store of the OS (Windows/MAC) to validate any server certificate. So, it obviously checks the Trusted Root Certificate Authorities store incase of Windows or Keychain in case of MAC. If the OS says that it can't find the issuer/signer of the server certificate, Jabber client prompts the user to accept it manually. Hence, it is always advisable to ensure that the platform's trust certificate store has got the CA's root certificate added to it. Most of the well known public CA certificates are pre-loaded into the OS platform if i am not wrong.

As far as your issue is concerned, if the Jabber application is unable to trust only the Tomcat certificate of the Unity Connection server on MAC platform, then please check if the server has sent the whole chain (leaf + intermediate + root). If it is not, that's when you experience this issue. You can filter the packet capture with port 8443 and source ip as that of the unity connection, click on the 'Server Hello' message that has the actual certificate it presented to the client, expand the certificate and see if it's a whole chain or just the server's own certificate. If it's not the entire chain, then the problem is on the UCxN server and not with Jabber.

Did you say that you don't see such prompts for CUCM or IM&P Tomcat certificates on the same MAC machine? If you don't, then you can filter the packet capture with the same port and IPs of CUCM and IM&P to check how they sent their Tomcat certificates.

Hope this helps!

-Sankar