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:

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

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.

  • I would say this question is in the grey area for the Information Security site. It seems more like something for ServerFault since it seems to me that it regards configuration more than security. But, since you asked "should be able..." it might fit here too.
    – Bob Ortiz
    Commented Jul 7, 2017 at 9:14
  • Ah ok, maybe I should ask my question there too. Thanks. Commented Jul 7, 2017 at 10:02

2 Answers 2


Not a complete answer (yet?), but:

Yes OpenSSL library called (directly or as here via libssl) by a program like FreeRADIUS can verify a received chain; no your commandline openssl verify does not verify a chain. This is covered in https://stackoverflow.com/questions/44375300/openssl-verify-with-chained-ca-and-chained-cert (mine) but that is downvoted and suggested offtopic, so I'll copy the relevant part here:

openssl commandline verify reads only one certificate, the first one, from the file given as operand, or from each file if more than one is given. This differs from the files specified with the -CAfile -trusted -untrusted options which can (and typically do) contain multiple certs.

Your file clientcert_intermediatecert_chain.pem contains the client cert and the intermediate cert in that order. Only the client cert is used, the intermediate cert is ignored, and as a result you do not have a valid chain to verify.

To use commandline to mimic/test the validation done by a receiver (for a client cert chain, the server) supply the leaf cert as the operand and all other transmitted (chain) certs (here the one intermediate) with -untrusted, and the anchor(s) plus any 'known' intermediates in the truststore either explicit or defaulted (your -CAfile root is fine, although there are other valid ways).

As to the real problem (Y) with FreeRADIUS: Are you sure the client is sending the chain? Do you have a trace?

As an alternative: if the client (or in general peer) doesn't send the needed chain certs, but they are in the local truststore which is arguably a spurious thing to do, OpenSSL will use those. You might try adding at least temporarily the intermediate cert to either the file you use for CA_file or the hashnamed directory you use for CA_path.

  • Thank you very much for this answer. I am pretty sure the client sent the full client-intermediate certificate chain, but I will check that again tomorrow (maybe I'll see that using AirPcap and WireShark). And I will try what happens if I add the intermediate-root chain to my trust store (not only the root one) and see what happens. Commented Jul 9, 2017 at 13:00
  • I finally managed to test the setup again using Wireshark to analyze the communication. And you were right. In my case, the client didn't send the complete client-intermediate chain, but only the first part of it (the client certificate). Commented Aug 2, 2017 at 9:57

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .