Re: cert bootstrap bug? (was Re: definitely, I have a problem with eap-tls)
I hate to resurrect this long thread from July 22-28, but I have the same problem and never saw a resolution. I'm using FreeRadius 2.0.5 on CentOS 5.2 with wpa_supplicant 0.6.4 (latest to date). I'm using the bootstrap script to generate example certificates. I also created a client certificate using make client.pem. I configured wpa_supplicant with ca.pem, client.pem and client.key. EAP-TLS authentication fails with the "fatal unknown ca" message. If I hack the Makefile like Sergio mentioned last month to sign the client certificate with the CA key, then authentication succeeds. In last month's thread, Alan DeKok posted:
You need to follow the documentation in eap.conf.
# If CA_file (below) is not used, then the # certificate_file below MUST include not # only the server certificate, but ALSO all # of the CA certificates used to sign the # server certificate. certificate_file = ${certdir}/server.pem
Have you done that?
In my case, CA_file does indeed refer to ca.pem as created by the bootstrap script. So I'm assuming that I don't need to touch the server.pem file as created. I'd really like to understand what's wrong. Could wpa_supplicant be somehow incompatible with the bootstrap certificate chain? Thanks
William Hegardt wrote:
EAP-TLS authentication fails with the "fatal unknown ca" message.
The server cert may need to be marked with "CA:true"
If I hack the Makefile like Sergio mentioned last month to sign the client certificate with the CA key, then authentication succeeds.
That can work, too.
I'd really like to understand what's wrong. Could wpa_supplicant be somehow incompatible with the bootstrap certificate chain?
It's OpenSSL on both ends. wpa_supplicant && FreeRADIUS are just wrappers to get the SSL data back and forth. Alan DeKok.
Alan DeKok wrote:
William Hegardt wrote:
EAP-TLS authentication fails with the "fatal unknown ca" message.
The server cert may need to be marked with "CA:true"
If I hack the Makefile like Sergio mentioned last month to sign the client certificate with the CA key, then authentication succeeds.
That can work, too.
I'd really like to understand what's wrong. Could wpa_supplicant be somehow incompatible with the bootstrap certificate chain?
It's OpenSSL on both ends. wpa_supplicant && FreeRADIUS are just wrappers to get the SSL data back and forth.
Pardon me if I've missed something, but as far as I can tell the server cert isn't authorised to sign client certs, so I can't see how it could work. The CA can sign client certs. -- REALITY.SYS not found: Universe halted.
Andrew Hood wrote:
Pardon me if I've missed something, but as far as I can tell the server cert isn't authorised to sign client certs, so I can't see how it could work. The CA can sign client certs.
There can be multiple levels of CA's. Verisign, your company, the local division, etc. This is all specifically allowed, and required, by SSL. My suggestion was that maybe what's needed was to mark the server cert with the CA properties. The server cert would then be an intermediate CA, which is Just Fine. Alan DeKok.
Alan DeKok wrote:
Andrew Hood wrote:
Pardon me if I've missed something, but as far as I can tell the server cert isn't authorised to sign client certs, so I can't see how it could work. The CA can sign client certs.
There can be multiple levels of CA's. Verisign, your company, the local division, etc. This is all specifically allowed, and required, by SSL.
No argument there.
My suggestion was that maybe what's needed was to mark the server cert with the CA properties. The server cert would then be an intermediate CA, which is Just Fine.
That's what Sergio seemed to be getting at in changing with the Makefile to have a CA rather than the server sign the client cert. Is that the better way? Is the answer to give the server the right to sign the cert, and if so how you do it so as to complete the root CA->server->client chain? However, there may be multiple servers, each with its own cert. Why should a client cert be signed by one server when it may be used with other servers? -- REALITY.SYS not found: Universe halted.
However, there may be multiple servers, each with its own cert. Why should a client cert be signed by one server when it may be used with other servers?
(radius) Server certificate doesn't have to be unique. You can copy the same certificate to all the radius servers that will be accepting clients issued by that certificate. Ivan Kalik Kalik Informatika ISP
Ivan Kalik escribió:
However, there may be multiple servers, each with its own cert. Why should a client cert be signed by one server when it may be used with other servers?
(radius) Server certificate doesn't have to be unique. You can copy the same certificate to all the radius servers that will be accepting clients issued by that certificate.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I was thinking, in this pki A trust in B only if A certified B. There maybe better solutions, responding to real life, like A trust in B only if B give credentials accepted by A. By this way, the general certification architecture is more dynamic. Server administrator only are worried about serverside pki but, he must have crl's from clientside pki, and can accept whatever he wants. It's only an opinion, i think freeradius is a great job :) for example with its modular behavior and configuration possibilities.
Andrew Hood escribió:
Alan DeKok wrote:
Andrew Hood wrote:
Pardon me if I've missed something, but as far as I can tell the server cert isn't authorised to sign client certs, so I can't see how it could work. The CA can sign client certs.
There can be multiple levels of CA's. Verisign, your company, the local division, etc. This is all specifically allowed, and required, by SSL.
No argument there.
My suggestion was that maybe what's needed was to mark the server cert with the CA properties. The server cert would then be an intermediate CA, which is Just Fine.
That's what Sergio seemed to be getting at in changing with the Makefile to have a CA rather than the server sign the client cert. Is that the better way?
Is the answer to give the server the right to sign the cert, and if so how you do it so as to complete the root CA->server->client chain?
However, there may be multiple servers, each with its own cert. Why should a client cert be signed by one server when it may be used with other servers?
I wonder the same questions, but nobody wants to reply. I think that issuing certs with server private key is better for crl managing, because each server manage its own crl. If somebody sign client certs with ca private key, the authority must provide the crl to the servers. First solution is more comfortable i think, but really i don't know sure. I'm not the developer, just a newbie thinking. Thinking is good.
Andrew Hood wrote:
That's what Sergio seemed to be getting at in changing with the Makefile to have a CA rather than the server sign the client cert. Is that the better way?
It's a different way. The question you want to ask is if the *CA* issues client certificates, or if the *server* does. e.g. If all RADIUS servers in your organization are managed by the same administrators, and authenticate the same people, then the client certs should be signed by the CA. If the RADIUS servers are managed by different administrators, and authenticate different sets of people, then the client certs should be signed by the server cert.
Is the answer to give the server the right to sign the cert, and if so how you do it so as to complete the root CA->server->client chain?
See the ca.cnf file for how to mark a certificate as a CA.
However, there may be multiple servers, each with its own cert. Why should a client cert be signed by one server when it may be used with other servers?
It all depends on your local configuration and needs. See above. Alan DeKok.
participants (5)
-
Alan DeKok -
Andrew Hood -
Ivan Kalik -
Sergio -
William Hegardt