Re: CUCM don't Send Intermediate Certificate to Cisco Jabber?

A_ · ‎05-11-2022

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

b.winter · ‎05-11-2022

No server sends the Root-CA and Intermediate CA's.

The servers only send its own cert.

The Root-CA and Intermediate CA's already have to be in place on the client.

So, Jabber has a problem with the cert validation, then you have to check, if the CA's are installed in the correct folder.

A_ · ‎05-11-2022

I'm not sure if I understand it correctly.

Shouldn't the server send the whole certificate chain (except root certificate)? Operating systems and libraries like openSSL don't have intermediate certificate preinstalled so they can't verify the certificate? What is then the purpose of officiall CA authority signed certificates when I have to install certificates on the clients nevertheless?

E. g. on nginx I put server certificate and intermediate certificate to one certificate file (bundled ca) so this certificate will be seen in the tls handshake.

We bought publicly trusted certificate authority certificates but have to upload certificates to the clients to trust manually?

b.winter · ‎05-11-2022

Think the other way:

If a server sends a client the whole chain and the client then uses CA certs of the chain to validate the server cert, wouldn't it break the whole concept of "chain of trust" and "public key infrastructure"?

If a server can dictate a client, which CA's the client should use, then anyone could act as a CA and therefore, every client would take every server cert as "valid".

Another example:

If you sign your CUCM certs with a private company root CA, you would need to install this CA cert on all clients beforehand.

If you wouldn't do that, you will get a certificate error message, when connecting via WebGUI or Jabber.

If CUCM has a signed cert from a well-known public CA, then you shouldn't need to do anything on the client, because the well-know public CA's and intermediate CA's are already pre-installed (through the OS, browser, ...).

Also keep in mind:

CUCM doesn't only present 1 cert to Jabber. He presents 2 certs: Tomcat and Callmanager

Also IMP presents 2 certs: Tomcat and CUP-XMPP

If you have Unity: also Tomcat

A_ · ‎05-11-2022

@b.winter wrote:
Think the other way:
If a server sends a client the whole chain and the client then uses CA certs of the chain to validate the server cert, wouldn't it break the whole concept of "chain of trust" and "public key infrastructure"?
If a server can dictate a client, which CA's the client should use, then anyone could act as a CA and therefore, every client would take every server cert as "valid".

My understanding is like following:

Client requests TLS. Server sends leaf/server, intermediate. Client checks hash values of the signer of the certificates and if the host name/san matches to connection server. So it's going the process: server name is ok, who's the signer? Intermediate is ok, who's the signer? And here it looks to own (client's) trust store and see: The signer is in my trust store. So it's protected regarding the trust store and don't use the root certificate of the server (this would be a security flaw).

@b.winter wrote:
Another example:
If you sign your CUCM certs with a private company root CA, you would need to install this CA cert on all clients beforehand.
If you wouldn't do that, you will get a certificate error message, when connecting via WebGUI or Jabber.

If CUCM has a signed cert from a well-known public CA, then you shouldn't need to do anything on the client, because the well-know public CA's and intermediate CA's are already pre-installed (through the OS, browser, ...).

To first example:

Yeah, this is ok. There is no way for the client to verify the certificate because this certificat can't be in the trust store (until it's manually installed).

To second example:

And here we go. We're using public CA. But the intermediate CA's are not pre-installed on OS/browser/libraries. Only root CAs are pre-installed. See: https://support.apple.com/en-us/HT202858, only root CAs are pre-installed. No intermediate.

E.g.

VeriSign is the root certificate of my server certificate.

Server's certificate signer: VeriSign Intermediate.

VeriSign Intermediate signer: VeriSign Root.

VeriSign Root signer: VeriSign Root. (it's in the trust store of the OS).

But intermediate is not in the trust store. So, how this works if server is not sending the intermediate certificate?

b.winter · ‎05-11-2022

My understanding is like following:
Client requests TLS. Server sends leaf/server, intermediate. Client checks hash values of the signer of the certificates and if the host name/san matches to connection server. So it's going the process: server name is ok, who's the signer? Intermediate is ok, who's the signer? And here it looks to own (client's) trust store and see: The signer is in my trust store. So it's protected regarding the trust store and don't use the root certificate of the server (this would be a security flaw).

I would say, the following happens:

Client requests a TLS connection.

Client receives the cert of the server.

Client checks, if the requests FQDN is present in CN or SAN

If ok, Client checks, who is the signer and then if the client trusts the signer.

If the signer is a intermediate CA, the Client continues, to go up the chain and repeat the cert checks, until he reaches the CA.

But every cert in the chain (except the server cert) needs to be present in the client.

Which exact version are you using on the client? (is it iPhone / iPad or Mac?)

A_ · ‎05-11-2022

Cisco Jabber for Mac.

If every cert in the chain (also intermediate) needs to be present in the trust store of the client, what is the purpose of public CA signed certificates? Mac only has root certificates pre-installed and I also can't find any documentation about intermediate certificates.

Roger Kallberg · ‎05-11-2022

Please read up on how PKI works.

@b.winter has provided you with the answer, in a very detailed way I might add. Your problem is not CM related, it is on the Apple OS side as it doesn't have the complete information to have the chain of trust with the public well known CA's. For that it needs any intermediate and the root cert. It is as simple as that and there is no way CM can fix that for you.

Jaime Valencia · ‎05-11-2022

Never been a MAC user, so, can't answer in that regards, but Windows DO have intermediate certificates pre-installed.

I mean, this site we're at, is using a certificate, with an intermediate certificate, if you see that your connection is secure, you have the full chain of trust in either your MAC or your browser.

Firefox also has certificates pre-installed, and it actually shows the intermediate with no distinction of the root certificate in the list

Your understanding of how the TLS/SSL handshake / PKI certificates works is wrong, and that's what is confusing you.

The only certificate that is exchanged, is the certificate from the server, not the full chain of trust. As already mentioned, this would mean all this is meaningless as then they could use any CA they want and as it matches with the certificate they sent you, you trust them.

If that was the case, I could easily create a certificate in my private CA for cisco.com, put in on a web server and if I hijack the DNS to route traffic to my server, ask for users credentials and steal them, because I presented them a certificate that says cisco.com, and also the root CA I used to sign it, and they trusted it because it matched.

The whole purpose of using a public CA is that it is a pre-trusted entity, and that entity is going to validate that whoever asks them for a certificate, is actually who they say are and then other people who don't necessarily know that 3rd party, will trust it as an extension of you trusting that public CA. And that extends to intermediate CAs, root CA provides the intermediate CA a certificate with signing permissions and that extends the chain of trust until you reach the server certificate, and you need to trust everyone in between the server certificate and the root CA.

You use intermediate CAs as method to compartmentalize in case there's a security incident, you can google "why use intermediate certificates" for more information on the topic.

HTH

java

if this helps, please rate

A_ · ‎05-11-2022

@Jaime Valencia wrote:
The only certificate that is exchanged, is the certificate from the server, not the full chain of trust.

I'm not sure about that. I'm reading the contrary. See my other post.

@Jaime Valencia wrote:
If that was the case, I could easily create a certificate in my private CA for cisco.com, put in on a web server and if I hijack the DNS to route traffic to my server, ask for users credentials and steal them, because I presented them a certificate that says cisco.com, and also the root CA I used to sign it, and they trusted it because it matched.

You can't, because the user wouldn't have the root certificate you're using. The client would give a error message. The client must check the own trust store for the root certificate. This is not true for intermediate. But for root certificate it's a must.

Roger Kallberg · ‎05-11-2022

As stated earlier please read upon how PKI works. Your understanding of the topic is not accurate and that’s why you have the misconception of how this works.

A_ · ‎05-11-2022

I do read (see bottom post with sources). Also again about intermediate:

During SSL negotiation the server should send the end entity SSL certificate and the intermediate certificate to the client (browser), if the intermediate certificate is properly installed on the server;

Source: https://kb.wisc.edu/sslservercerts/page.php?id=20264

This is contrary to the posts here.

In my other post (at the bottom) I also posted rfc 5246.

I‘m really confused right now.

Roger Kallberg · ‎05-11-2022

Not saying that you don’t, but again your understanding of this is inaccurate and we’re multiple people saying so, yet you persist.

In simply terms a server certificate is signed by a CA, in most cases it will be signed by the intermediate certificate of the CA as the root CA server is for the most actually not active and as such is not signing anything per see. This gives this chain of trust.

1. Server certificate, signed by the CA (by the intermediate certificate)

2. Intermediate certificate of the CA that signed the server certificate

3. Root certificate of the CA that signed the intermediate certificate

When a client contacts the server it will present its server certificate and the client will check in its trust store if it has the certificates of the CA that signed the server certificate.

As you can see if your client does not have the intermediate CA certificate in its trust store , but only the root CA certificate, there is a gap in the chain of trust.

No matter how much you pursue it does make you be more right. Take the information given and go with it or disregard it. It’s your prerogative.

A_ · ‎05-11-2022

Sorry to follow up like this. But it's an interesting general topic.

How is the problem solvable then? We bought a public CA signed certificate. This certificate is signed by an intermediate and the intermediate by an root. That's the usual way of a server certificate (server -> intermediate -> root).

The root certificate is already installed on Mac. No problems there. But the intermediate certificate is missing. So, everyone is installing intermediate certificates on their systems for every root certificate? I also tested it now on a Virtual Machine of Windows 11: The intermediate trust store is empty on a fresh installation until I call a Website with an intermediate certificate and then I can see it there (Windows seems to save the certificate). I'm using Edge because there I'm sure it uses Windows' trust store. But where the system is getting it from if not from the server?

I found this documentation from DigiCert:

If the Intermediate Certificate is not installed on the server (where the SSL/TLS certificate is installed) it may prevent some browsers, mobile devices, applications, etc. from trusting the SSL/TLS certificate.
In order to make the SSL/TLS certificate compatible with all clients, it is necessary that the Intermediate Certificate be installed.

Source: https://knowledge.digicert.com/solution/SO16297.html

So, why the server should even install the intermediate certificate if it's not necessary and just client side?

And this:

The client may already have the root certificate installed, but probably not the certificates of the intermediate CAs.
Therefore certificates are often provided as part of a certificate bundle.

This bundle would consist of all of the CA certificates in the chain in a single file, usually called CA-Bundle.crt.

Source: http://www.steves-internet-guide.com/ssl-certificates-explained/

Even in the RFC 5246 (TLS) this is mentioned:

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

Source: https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2

A "chain of certificates" and the "root certificate may be omitted from the chain" (so server just needs server -> intermediate) because the client possess it already (trusted public root CAs).
So, RFC 5246 tells me, that it's the server's responsibility to send the intermediate certificate. It's not guaranteed that a client have intermediate certificates. Cisco Jabber is cleary not, it's accessing trust store of OS I think. Mac just have root certs (see Apple documentation).

This is also mentioned here:

In contrast, non-root certificates are implicitly trusted and are not required to be shipped with an OS, web browser, or certificate-aware application.

Source: https://www.keyfactor.com/blog/certificate-chain-of-trust/

And another site:

For a server's TLS certificate to be trusted by a client, the client must be configured to trust the Certificate Authority (CA) that signed the server certificate. Many CAs do not sign with their root certificate, but instead with an intermediate certificate. Clients, however, may only trust the root CA. Therefore the server (...) is often required to present a full certificate chain along with their TLS server certificate.

Source: https://docs.pexip.com/admin/certificate_management.htm

Roger Kallberg · ‎05-11-2022

Not sure where you got that you don’t need to have the intermediate certificate on the server. You need to install the intermediate and root certificates of the CA on the server in the applicable trust store(s) as well.