2

I am trying to test the following setup:

A RADIUS server works with the EAP-TLS protocol. The client and the server have the following certificates:

Client
Public Key: clientcert_intermediatecert_chain.pem
CA-certificate: rootcert.pem

Server
Public Key: servercert_intermediatecert_chain.pem
CA-certificate: rootcert.pem

Both, the client certificate (clientcert.pem) and the server certificate (servercert.pem) are signed by the same intermediate certificate (intermediatecert.pem), which is signed by the root certificate (rootcert.pem).
Both chains, which are set to be the public keys are put together like this (via Shell command):
cat servercert.pem intermediatecert.pem > servercert_intermediatecert_chain.pem
cat clientcert.pem intermediatecert.pem > clientcert_intermediatecert_chain.pem

Now, the client tries to connect to the server. Both sides send their public keys and try to verify the received public keys with rootcert.pem

I know that the "normal" way would be, that the public key was only the server or client certificate. And the CA-certificate would be the imcert-rootcert-chain, but I have to know if this would work too.

Now my questions:

  1. Is it legitimate that the public key is a chain consisting of the server/client certificate and the intermediate certificate?
  2. And if so, does this apply to both sides (server and client)?
  3. Should a server (like FreeRADIUS) or a client be able to verify chains like these with the root certificate, if they receive them from the counter part?

Based on my experience, FreeRADIUS doesn't verify such a certificate chain right. If I'm not mistaken FreeRADIUS uses the OpenSSL library and does the same thing as the following command in the situation shown above:

openssl verify -CAfile rootcert.pem clientcert_intermediatecert_chain.pem

And I'm pretty sure this does not work. OpenSSL cannot verify a chain like this with the root certificate. It fails when trying to put the chain of trust together.
Is this correct?

By the way, FreeRADIUS returns the same error as the verify command: error 20 at 0 depth: cannot find issuer certificate which means it cannot put the chain of trust together.

Jannis Kappertz
  • 47
  • 7
  • Partially answered at your previous posting https://security.stackexchange.com/questions/163577/should-a-server-or-a-client-be-able-to-verify-a-client-server-certificate-inte – dave_thompson_085 Jul 09 '17 at 05:33

2 Answers2

2
  1. Yes it's fine to use chains with a common intermediary CA.
  2. Yes.
  3. Yes and it does. You need to post the debug output from FreeRADIUS. Saying it returns "error 20" is not helpful. That's likely not a FreeRADIUS error, but output from OpenSSL.
Arran Cudbard-Bell
  • 1,514
  • 1
  • 9
  • 18
  • Thank you for your answer, but I'm not sure if you understood the question right (but maybe I don't understand your answer right :-) ). I know, that it is legit to use the same intermediate cert for both sides. But my question was, if the public key, that is sent to the other side, can be a **chain**. – Jannis Kappertz Jul 07 '17 at 14:57
  • I didn't want to send the complete debug message, because I didn't want the error to be solved. I think I will rephrase that part. – Jannis Kappertz Jul 07 '17 at 15:25
  • Yes, the supplicant can send multiple certificates to the server, and the server can send multiple certificates to the supplicant. You have to watch this on some access points though, as they don't like the massive chunks of EAP coming back from the supplicant. Seen this in the wild with cisco APs. On the server side cat'ing all the certs into a single file is correct way to set this up. – Arran Cudbard-Bell Jul 07 '17 at 16:33
  • For that error, sounds like you need to cat the intermediary CA into the file set here: https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/mods-available/eap#L219 Or you need to convince the supplicant to send more of the certificate chain. – Arran Cudbard-Bell Jul 07 '17 at 16:35
  • Thank you very much. Yeah, I guess I still did something wrong then with FreeRadius. I just thought it would be like this, that you can have one part of the chain in the public key (no matter how far this part goes, as long as it doesn't contain the root cert) and on the other side the part completing the chain of trust, with the self signed root certificate at the end. – Jannis Kappertz Jul 07 '17 at 17:02
0

It seems like the problem of my setup was, that the client did not send the complete client-intermediate chain, but only the client certificate (Figured it out using Wireshark). The other way around, the radius server sending a server-intermediate chain, works fine.

So, to answer my question: Yes, this setup should work, in both directions.

Jannis Kappertz
  • 47
  • 7