Hi List, at work, I have the following requirements for IP phones which should be authenticated before joining the network: - Root CA --> Sub CA --> Device certificates - The phones have the Sub CA certificate locally installed as "trustworthy" (NOT the Root CA certificate!) - The RADIUS server must only send its server certificate (not the whole chain) - The phones only send their device certificate to the RADIUS server I tried to build this scenario with FreeRADIUS (2.1.10, on Debian), but got stuck at the following points: - I only put the RADIUS server certificate to certificate_file. But as soon as CA_path or CA_file are set, FreeRADIUS sends the whole certficiate chain to the phone. - As soon as I unset CA_path and CA_file, FreeRADIUS sends only the content of certificate_file to the phone, which is what I want. Of course, phone certificate checking then doesn't work anymore. - So I thought that I implement phone certificate checking using the "verify" block. But this only seems to work "on top" of the built-in certificate checking. Does anybody have a hint? Thanks, Sven
On 09/07/12 13:04, Sven Dreyer wrote:
Hi List,
at work, I have the following requirements for IP phones which should be authenticated before joining the network:
- Root CA --> Sub CA --> Device certificates - The phones have the Sub CA certificate locally installed as "trustworthy" (NOT the Root CA certificate!) - The RADIUS server must only send its server certificate (not the whole chain)
Why?
- I only put the RADIUS server certificate to certificate_file. But as soon as CA_path or CA_file are set, FreeRADIUS sends the whole certficiate chain to the phone.
I'm afraid the current TLS code works that way. You would need to patch the source if you want a different set of server CA and client CA objects.
On 09/07/12 13:18, Phil Mayers wrote:
On 09/07/12 13:04, Sven Dreyer wrote:
Hi List,
at work, I have the following requirements for IP phones which should be authenticated before joining the network:
- Root CA --> Sub CA --> Device certificates - The phones have the Sub CA certificate locally installed as "trustworthy" (NOT the Root CA certificate!) - The RADIUS server must only send its server certificate (not the whole chain)
Why?
- I only put the RADIUS server certificate to certificate_file. But as soon as CA_path or CA_file are set, FreeRADIUS sends the whole certficiate chain to the phone.
I'm afraid the current TLS code works that way. You would need to patch the source if you want a different set of server CA and client CA objects.
Just to expand on this; it would be very hard, since OpenSSL is the one adding the CA chain and doing the SSL. You would need to persuade OpenSSL to have the CA loaded for clients, but not for server use. I think this might even be impossible. You could use a different CA for the server and client.
Am 09.07.2012 14:18, schrieb Phil Mayers:
- The phones have the Sub CA certificate locally installed as "trustworthy" (NOT the Root CA certificate!) - The RADIUS server must only send its server certificate (not the whole chain)
Why?
Not my decision - our customer said something like "that's the way it works in our network". I suggested to send the whole chain, but their answer was like "no RFC forces anyone to send the whole chain, so it must work that way".
- I only put the RADIUS server certificate to certificate_file. But as soon as CA_path or CA_file are set, FreeRADIUS sends the whole certficiate chain to the phone.
I'm afraid the current TLS code works that way. You would need to patch the source if you want a different set of server CA and client CA objects.
Thanks for that, I already suspected something like this. Best regards, Sven
On 09/07/12 13:27, Sven Dreyer wrote:
Am 09.07.2012 14:18, schrieb Phil Mayers:
- The phones have the Sub CA certificate locally installed as "trustworthy" (NOT the Root CA certificate!) - The RADIUS server must only send its server certificate (not the whole chain)
Why?
Not my decision - our customer said something like "that's the way it works in our network". I suggested to send the whole chain, but their answer was like "no RFC forces anyone to send the whole chain, so it must work that way".
RFC 2246, section 7.4.2 says: certificate_list This is a sequence (chain) of X.509v3 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 which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. This intent of this paragraph seems plain. Send the server cert, followed by all intermediate certs, followed optionally by the root CA cert. Unfortunately, 2246 does not make use of RFC 2119 language to indicate this is mandatory in the usual way, and this text remains unchanged in 4346 (TLS 1.1); however it was updated in 5246 (TLS 1.2), and the wording is far clearer. In short, my reading of the TLS RFCs suggests that sending the server and all intermediate certs is mandatory. Clearly the OpenSSL authors agree. But "the customer is always right" ;o)
Hi Phil, Am 09.07.2012 14:38, schrieb Phil Mayers:
RFC 2246, section 7.4.2 says:
This intent of this paragraph seems plain. Send the server cert, followed by all intermediate certs, followed optionally by the root CA cert.
Thank you very much for this! I think this is enough "food" to make the customer notice that he's wrong. :-) Thanks and best regards, Sven
participants (2)
-
Phil Mayers -
Sven Dreyer