@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.
