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:
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 (
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
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:
- Is it legitimate that the public key is a chain consisting of the server/client certificate and the intermediate certificate?
- And if so, does this apply to both sides (server and client)?
- 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.