05-11-2022 02:53 AM
Hi,
we have a certificate issue where Cisco Jabber wants to verify the certificate chain but missing the intermediate certificate. It's a CA signed certificate so the root certificate is installed by most of the operating system vendors. The access with the browser to CUCM or IM&P also works fine without any error message (so the server sends the intermediate certificate).
But Cisco Jabber don't receive the intermediate certificate. How we can change this behaviour? How we tell UC server to send the intermediate certificate to Cisco Jabber's request?
Best regards
05-11-2022 11:55 PM
Checking the Wireshark traces of Expressway, it sends the full chain.
When I checked the TLS handshake with Expressway, which was also signed by Versign/Digicert, I saw 4 certs --> 1 Root-CA + 2 Intermediate + Server.
With CUCM, I also did a packet capture with Wireshark:
In my lab, I only have a Root-CA signing directly the server certs.
I don't have access to any CUCM's, which have Root-CA and Intermediate-CA chain.
But I assume, CUCM is also sending the whole chain, and not only it's server cert and the signer CA cert.
Maybe you could check this on your side.
05-12-2022 12:23 AM - edited 05-12-2022 12:33 AM
@A_: Honest opinion: Great discussion with you about the topic. Such things get my head scrambled and won't leave, until I dig deeper and do the "extra mile".
Searching the internet about how certificate validation works, learned me, that my understanding of the process was partly wrong.
Found this paragraph:
It's unlikely that the server's certificate is signed directly by a root certificate authority that is trusted by the client. However, the client can trust any number of intermediate certificate authorities, as long as the trust chain eventually leads back to one of the client's trusted root certificates, ...
For each intermediate certificate, the client completes the same process: it verifies the issuer's name matches the certificate owner's name, and uses the signature and public key to verify that the certificate is properly signed.
So, you are correct, that it should be enough to only trust the Root-CA.
Furthermore, my understanding is, that the client would already stop the chain validation, if the intermediate CA is already trusted by the client (=> installed in the trust store):
Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right—hand side of Figure 2–9. This list determines which server certificates the client accepts. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to the next step. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
Nonetheless, if you still get certificate warnings in Jabber, then maybe there is a service in CUCM / IMP / CUC, that still uses e.g. a self-signed cert.
As already mentioned, when Jabber connects to the UC-server, not only 1 certificate will be presented to Jabber.
05-12-2022 01:37 AM - edited 05-12-2022 02:12 AM
@b.winter wrote:@A_: Honest opinion: Great discussion with you about the topic. Such things get my head scrambled and won't leave, until I dig deeper and do the "extra mile".
Thank you. It really hit me yesterday. Perhaps I should have phrased it more nicely before. Sorry if it came across as arrogant and ignorant, this was not my intention and I just wanted a discussion because I wanted to understand.
Yes, I can upload the intermediate certificate of a public CA to all Macs but this would be just a workaround and in my opinion not works as intended. I also can't find any Cisco Documentation about Cisco Jabber certification to upload the intermediate certificate to the trust store of clients when using public CA certificates.
Cisco Jabber even seems to not using the intermediate trust store of Windows: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz19160
Don't know if this is true.
@b.winter wrote:Furthermore, my understanding is, that the client would already stop the chain validation, if the intermediate CA is already trusted by the client (=> installed in the trust store):
Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right—hand side of Figure 2–9. This list determines which server certificates the client accepts. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to the next step. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
Maybe because of this Windows is installing automatically intermediate certificates to trust store, so it can faster validate the certificates. But this is also new for me and don't know that before. Very interesting, thanks!
05-12-2022 01:21 AM - edited 05-12-2022 01:25 AM
Hi b.winter,
I also used WireShark and it's interesting:
On Windows I get all three certificates (server, intermediate, root). Unsurprisingly, without errors on the client.
On Mac OS I only get server certificate. And this is the issue here. I really don't know why. Yeah, the workaround would be to upload the intermediate certificate to all Macs... but this can't be the solution for a public CA in my opinion. The correct way should be that CUCM sends the chain so Macs can trust it. And sorry if I'm stubborn here. And fact is: If I access to CUCM with Safari Browser it works, the server sends all three certificates. Just the Cisco Jabber request seems lost.
Are there any log messages which I can activate on CUCM side to see which certificates are really sent to a Client Hello? Maybe something is blocking the other certificates on Macs?
05-12-2022 01:34 AM
But what I don't get is, on which basis should CUCM send a different amount of certificates in the packet?
I mean, we are way down the OSI layer, where no application specific details aren't presented. It's just a TCP packet exchange.
You could take a packet capture on CUCM and check it with Wireshark. But probably, you will see the same, like in the trace on Mac.
But it's worth a try.
05-12-2022 01:54 AM - edited 05-12-2022 01:56 AM
Yeah, I don't understand it, either. For CUCM it should be no difference if Windows or Mac OS.
Maybe there is an error on some trust certificates on CUCM. I will double check the certificate chain on CUCM for tomcat-trust and xmpp-trust. But why it's only affecting Mac OS?
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