client certs signed by server certs
Hi, I found a problem with a client cert in Windows certificate store, after all three certs have been installed. The server cert is considered invalid, because it lacks the privilege to sign further certs. I hacked the Makefile a little bit, to generate client certs signed by CA cert, not by the server certs. This way, CA signs both certs and only the CA and client certs are required for Windows systems, and after successful installation both are considered valid. I do understand that eliminating server cert has a security impact, but where should it be installed? __ Informacja programu ESET Smart Security, wersja bazy sygnatur wirusow 4425 (20090914) __ Wiadomosc zostala sprawdzona przez program ESET Smart Security. http://www.eset.pl lub http://www.eset.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
[EMAIL PROTECTED] wrote: Try attached Makefile. It has been altered so client certificates are signed by the ca and not server certificate. I was unable to persuade up-to-date Windows PCs to accept server certificate as an Intermediate CA. Changing the issuer resolved the problem. Shouldn't that be: $ diff Makefile.20081211 Makefile 92c92 openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(PASSWORD_SERVER) -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf --- openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(PASSWORD_CA) -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf -- REALITY.SYS not found: Universe halted. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
Shouldn't that be: $ diff Makefile.20081211 Makefile 92c92 openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(PASSWORD_SERVER) -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf --- openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(PASSWORD_CA) -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf It should. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
client certs
freeradius-2.1.1-2 (rebuild SRPM from Fedora on CentOS 5) followed instructions in certs/README perfectly - so I believe. server certs seem fine but generated client cert in Windows shows Windows does not have enough information to verify and yes, I have loaded the 'ca.der' file generated by the instructions on the Windows client and that installs in 'Trusted Root Authorities'. The 'client' cert seems to install in 'Other People', and does include the XPextensions stuff. So I'm trying to verify the client certificate... # openssl verify -CAfile ca.pem [EMAIL PROTECTED] [EMAIL PROTECTED]: /C=US/ST=Arizona/O=MyOrg/[EMAIL PROTECTED]/[EMAIL PROTECTED] error 20 at 0 depth lookup:unable to get local issuer certificate so I figured I would try to verify it against the server file... # openssl verify -CAfile server.pem [EMAIL PROTECTED] [EMAIL PROTECTED]: /C=US/ST=Arizona/O=MyOrg/CN=Radius Server Certificate/[EMAIL PROTECTED] error 2 at 1 depth lookup:unable to get issuer certificate but indeed the server file verifies... # openssl verify -CAfile ca.pem server.crt server.crt: OK # openssl verify -CAfile ca.pem server.pem server.pem: OK This would seem pretty simple (the directions make it seem simple) edited client.cnf changed input/output password values to the same, simple value changed the e-mail address and cn to the same value as shown above What am I doing wrong? Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
freeradius-2.1.1-2 (rebuild SRPM from Fedora on CentOS 5) followed instructions in certs/README perfectly - so I believe. server certs seem fine but generated client cert in Windows shows Windows does not have enough information to verify and yes, I have loaded the 'ca.der' file generated by the instructions on the Windows client and that installs in 'Trusted Root Authorities'. The 'client' cert seems to install in 'Other People', and does include the XPextensions stuff. So I'm trying to verify the client certificate... # openssl verify -CAfile ca.pem [EMAIL PROTECTED] [EMAIL PROTECTED]: /C=US/ST=Arizona/O=MyOrg/[EMAIL PROTECTED]/[EMAIL PROTECTED] error 20 at 0 depth lookup:unable to get local issuer certificate so I figured I would try to verify it against the server file... # openssl verify -CAfile server.pem [EMAIL PROTECTED] [EMAIL PROTECTED]: /C=US/ST=Arizona/O=MyOrg/CN=Radius Server Certificate/[EMAIL PROTECTED] error 2 at 1 depth lookup:unable to get issuer certificate but indeed the server file verifies... # openssl verify -CAfile ca.pem server.crt server.crt: OK # openssl verify -CAfile ca.pem server.pem server.pem: OK This would seem pretty simple (the directions make it seem simple) edited client.cnf changed input/output password values to the same, simple value changed the e-mail address and cn to the same value as shown above What am I doing wrong? Try attached Makefile. It has been altered so client certificates are signed by the ca and not server certificate. I was unable to persuade up-to-date Windows PCs to accept server certificate as an Intermediate CA. Changing the issuer resolved the problem. Ivan Kalik Kalik Informatika ISP Makefile Description: Binary data - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
On Thu, 2008-12-11 at 01:13 +0100, [EMAIL PROTECTED] wrote: freeradius-2.1.1-2 (rebuild SRPM from Fedora on CentOS 5) followed instructions in certs/README perfectly - so I believe. server certs seem fine but generated client cert in Windows shows Windows does not have enough information to verify and yes, I have loaded the 'ca.der' file generated by the instructions on the Windows client and that installs in 'Trusted Root Authorities'. The 'client' cert seems to install in 'Other People', and does include the XPextensions stuff. So I'm trying to verify the client certificate... # openssl verify -CAfile ca.pem [EMAIL PROTECTED] [EMAIL PROTECTED]: /C=US/ST=Arizona/O=MyOrg/[EMAIL PROTECTED]/[EMAIL PROTECTED] error 20 at 0 depth lookup:unable to get local issuer certificate so I figured I would try to verify it against the server file... # openssl verify -CAfile server.pem [EMAIL PROTECTED] [EMAIL PROTECTED]: /C=US/ST=Arizona/O=MyOrg/CN=Radius Server Certificate/[EMAIL PROTECTED] error 2 at 1 depth lookup:unable to get issuer certificate but indeed the server file verifies... # openssl verify -CAfile ca.pem server.crt server.crt: OK # openssl verify -CAfile ca.pem server.pem server.pem: OK This would seem pretty simple (the directions make it seem simple) edited client.cnf changed input/output password values to the same, simple value changed the e-mail address and cn to the same value as shown above What am I doing wrong? Try attached Makefile. It has been altered so client certificates are signed by the ca and not server certificate. I was unable to persuade up-to-date Windows PCs to accept server certificate as an Intermediate CA. Changing the issuer resolved the problem. OK - question... I only re-generated the 'client' certificate but in doing a diff, it appears that every level of cert generation has changed...do I have to start over? Windows is still complaining with new client certificate and yes, system is XP Service Pack 3 so it's pretty much up-to-date Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
server certs seem fine but generated client cert in Windows shows Windows does not have enough information to verify and yes, I have loaded the 'ca.der' file generated by the instructions on the Windows client and that installs in 'Trusted Root Authorities'. The 'client' cert seems to install in 'Other People', and does include the XPextensions stuff. Craig Craig, You have to install the root certificate and client certificate to the correct certificate store. You have two options - the machine store or the personal certificate store of your current Windows user. The personal certificate store is probably what you want. Double click the client certificate, select install certificate and choose Place the certificate in the following store. Select the Personal certificate store. That should solve your problem. Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
I only re-generated the 'client' certificate but in doing a diff, it appears that every level of cert generation has changed...do I have to start over? You should. Original Makefile was creating ca certificate that was valid only for 30 days. This one will use value from ca.cnf. Windows is still complaining with new client certificate and yes, system is XP Service Pack 3 so it's pretty much up-to-date Then you haven't got the (correct) ca.der certificate in your trusted root certificate store. Ivan Kalik Kalik informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
On Wed, 2008-12-10 at 19:32 -0500, Jason Wittlin-Cohen wrote: server certs seem fine but generated client cert in Windows shows Windows does not have enough information to verify and yes, I have loaded the 'ca.der' file generated by the instructions on the Windows client and that installs in 'Trusted Root Authorities'. The 'client' cert seems to install in 'Other People', and does include the XPextensions stuff. Craig Craig, You have to install the root certificate and client certificate to the correct certificate store. You have two options - the machine store or the personal certificate store of your current Windows user. The personal certificate store is probably what you want. Double click the client certificate, select install certificate and choose Place the certificate in the following store. Select the Personal certificate store. That should solve your problem. Thanks...I sort of thought so but this has been a frustrating experience and I'm not that dumb. Is it normal for this 'client' certificate to show Windows does not have enough information to verify this certificate when you view it? I did take the 'ca.der' and that is loaded in 'Trusted Root Authorities' and seems to be happy there but the client certificate, even newly generated from the scripts and the new Makefile from Ivan still shows that warning. It seems possible to me that the certificate provided by the server should provide the link between the CA certificate and the client certificate installed on the Windows client and make it happy but I haven't gotten this to work right - at least consistently. Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
Craig, Apparently Windows automatically sends non-CA certificates in DER or PEM format to the Other People' certificate store. More importantly, the wireless supplicant in Windows XP \will not work with PEM or DER formatted client certificates. It'll complain that you have no certificate. You must convert to pkcs12 as the documentation states. openssl pkcs12 -export -in certname.pem \ -inkey keyname.key -out name.p12 -clcerts* * Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
On Thu, 2008-12-11 at 01:49 +0100, [EMAIL PROTECTED] wrote: I only re-generated the 'client' certificate but in doing a diff, it appears that every level of cert generation has changed...do I have to start over? You should. Original Makefile was creating ca certificate that was valid only for 30 days. This one will use value from ca.cnf. Windows is still complaining with new client certificate and yes, system is XP Service Pack 3 so it's pretty much up-to-date Then you haven't got the (correct) ca.der certificate in your trusted root certificate store. I was afraid you were gonna say that... I am honing by BOFH chops...each time I make new certs, I chase the iPhone users through their setup to accept the new cert. ;-) Though I was pretty certain that the certs I was making through my own scripts were right, I thought if I used the cert creation scripts from freeradius, things would just work... OK - I'll look at the cnf options because it would be nice to have more than 30 days anyway Thanks Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
Is it normal for this 'client' certificate to show Windows does not have enough information to verify this certificate when you view it? No. Click on the details and see who is the issuer - server or ca. You should give users .p12 certificates which can't be installed without a password used to create them. They can be viewed once they are installed. I did take the 'ca.der' and that is loaded in 'Trusted Root Authorities' and seems to be happy there but the client certificate, even newly generated from the scripts and the new Makefile from Ivan still shows that warning. It seems possible to me that the certificate provided by the server should provide the link between the CA certificate and the client certificate installed on the Windows client and make it happy but I haven't gotten this to work right - at least consistently. Link between them exists when ca is the issuer. It is listed in client certificate details. In theory, it is better for server certificate ti issue client certificates. In practice, Windows won't recongnize intermediate CA role for server certificate. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
Apparently Windows automatically sends non-CA certificates in DER or PEM format to the Other People' certificate store. More importantly, the wireless supplicant in Windows XP \will not work with PEM or DER formatted client certificates. It'll complain that you have no certificate. You must convert to pkcs12 as the documentation states. openssl pkcs12 -export -in certname.pem \ -inkey keyname.key -out name.p12 -clcerts* * Jason No need to convert. make client.pem creates client.p12 as well. He just has to import it. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
On Wed, 2008-12-10 at 19:51 -0500, Jason Wittlin-Cohen wrote: Craig, Apparently Windows automatically sends non-CA certificates in DER or PEM format to the Other People' certificate store. More importantly, the wireless supplicant in Windows XP \will not work with PEM or DER formatted client certificates. It'll complain that you have no certificate. You must convert to pkcs12 as the documentation states. openssl pkcs12 -export -in certname.pem \ -inkey keyname.key -out name.p12 -clcerts Jason Thanks for the help. Last week when I was generating certificates my own way, I was doing that and yes, as Ivan points out, the 'scripted' way that make client.pem does make the p12 cert for the client. My issue now - and obviously sh*t happens as I change things around is that with the certificates newly generated and radiusd restarted in 'debug' mode, the newly minted ca.der and client.p12 certificates installed in their proper homes in 'certificates' following the instructions here... http://wiki.freeradius.org/WPA_HOWTO#Step_4:_Configure_the_Client I 'repair' or 'refresh' Network Connection (obviously the repair is for the Wireless) and it hems/haws and finally says Authentication failed but the wireless AP never makes an effort to connect to the radius server. Just rebooted the laptop and checked for stale info in regedit HKCU\Software\Microsoft\EAPOL (none) This AP has been talking to the radius server for weeks now (and all day today) and authenticating Macintosh and iPhone clients but Windows is making me absolutely nuts. The radius server is also authenticating for my RRAS server on a Windows server on the LAN...my only issue has been Windows laptops ;-( At least earlier with my otherwise generated certificates, I could get through the AP and to the radius server but now...it's like no one is home. The Wireless AP does show my connection but that's it. I'm very frustrated Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
Craig, Have you tried authenticating with the same certificate from a different computer, or using a different supplicant? The XP supplicant is pretty awful. If you have an Intel card, you can download the Intel PROset software for free which has more features than XP's supplicant, supports more authentication options, and tends to work better. My personal favorite is Juniper's Open Access client. Juniper has a 30-day trial if you want to test to see if that solves your problems. In addition, I find that if the sever is down while a client tries to connect, I have to refresh the settings on the AP, restarting the wireless, or the RADIUS server will show no activity at all. Restarting Windows or repairing the wireless connection doesn't help as it appears to be an issue with the AP. So, if you had the the RADIUS server down for even a short while, try restarting the AP. You can also see if there's a valid certificate chain. Start Run mmc. File Add Snap-In. Add Certificates. Choose My User. You should see a Certificates - Current User tree. Expand it, then open Personal Certificates. You should see your certificate in the list. Double click the certificate and check the Certificate Path tab. Certificate Status should be OK, and you should see both your client cert and the CA. If your certificate was signed by the server key and not the CA key, certificate verification will fail. Also, run freeradius with freeradius -X to check to see whether Windows is even communicating with the RADIUS server. I was having problems with my Ubuntu laptop and found it was timing out before even attempting to authenticate with the RADIUS server due to a driver issue. Jason On Wed, Dec 10, 2008 at 9:17 PM, Craig White [EMAIL PROTECTED] wrote: On Wed, 2008-12-10 at 19:51 -0500, Jason Wittlin-Cohen wrote: Craig, Apparently Windows automatically sends non-CA certificates in DER or PEM format to the Other People' certificate store. More importantly, the wireless supplicant in Windows XP \will not work with PEM or DER formatted client certificates. It'll complain that you have no certificate. You must convert to pkcs12 as the documentation states. openssl pkcs12 -export -in certname.pem \ -inkey keyname.key -out name.p12 -clcerts Jason Thanks for the help. Last week when I was generating certificates my own way, I was doing that and yes, as Ivan points out, the 'scripted' way that make client.pem does make the p12 cert for the client. My issue now - and obviously sh*t happens as I change things around is that with the certificates newly generated and radiusd restarted in 'debug' mode, the newly minted ca.der and client.p12 certificates installed in their proper homes in 'certificates' following the instructions here... http://wiki.freeradius.org/WPA_HOWTO#Step_4:_Configure_the_Client I 'repair' or 'refresh' Network Connection (obviously the repair is for the Wireless) and it hems/haws and finally says Authentication failed but the wireless AP never makes an effort to connect to the radius server. Just rebooted the laptop and checked for stale info in regedit HKCU\Software\Microsoft\EAPOL (none) This AP has been talking to the radius server for weeks now (and all day today) and authenticating Macintosh and iPhone clients but Windows is making me absolutely nuts. The radius server is also authenticating for my RRAS server on a Windows server on the LAN...my only issue has been Windows laptops ;-( At least earlier with my otherwise generated certificates, I could get through the AP and to the radius server but now...it's like no one is home. The Wireless AP does show my connection but that's it. I'm very frustrated Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
On Wed, 2008-12-10 at 21:36 -0500, Jason Wittlin-Cohen wrote: Craig, Have you tried authenticating with the same certificate from a different computer, or using a different supplicant? The XP supplicant is pretty awful. If you have an Intel card, you can download the Intel PROset software for free which has more features than XP's supplicant, supports more authentication options, and tends to work better. My personal favorite is Juniper's Open Access client. Juniper has a 30-day trial if you want to test to see if that solves your problems. yes, this laptop has Intel ProSet and I've been using that but with this latest round of certs, I've been unable get from Laptop to Radius, even with Intel ProSet. ;-( In addition, I find that if the sever is down while a client tries to connect, I have to refresh the settings on the AP, restarting the wireless, or the RADIUS server will show no activity at all. Restarting Windows or repairing the wireless connection doesn't help as it appears to be an issue with the AP. So, if you had the the RADIUS server down for even a short while, try restarting the AP. I did that about an hour ago but it never hurts and I'll do that when I start my next go 'round after dinner You can also see if there's a valid certificate chain. Start Run mmc. File Add Snap-In. Add Certificates. Choose My User. You should see a Certificates - Current User tree. Expand it, then open Personal Certificates. You should see your certificate in the list. Double click the certificate and check the Certificate Path tab. Certificate Status should be OK, and you should see both your client cert and the CA. there is and I've been checking that very thing all along - looks good - If your certificate was signed by the server key and not the CA key, certificate verification will fail. check Also, run freeradius with freeradius -X to check to see whether Windows is even communicating with the RADIUS server. I was having problems with my Ubuntu laptop and found it was timing out before even attempting to authenticate with the RADIUS server due to a driver issue. that's what I was referring to 'debug' mode I have enough hours logged in Radius configuration (first 1.1.2 and now 2.1.1) to know where all the bodies are buried and have googled and looked at the wiki.freeradius.org till I'm blind. Macintosh and iPhone's were easy because they just ask you to accept certificate(s) presented by server. Windows RRAS authentication against Radius server was simple. LDAP authentication seemed to be easy WinXP laptops - argh... Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: final question about client certs using eap-tls (was: cert bootstrap bug?)
Sergio escribió: Hi, also was so many others. At this time i have got one eap module which authenticates users under a PKI. My client certs are issued by root ca (ca.pem) and everything works. I can manage the crl, because it is public, and authenticate any user against any server. So my question is, what's the final goal of signing certificates with server's? The only difference (i think) is about the crl managing, because in my case, the authority should provide the crl to the server administrators. I don't see any more difference. Thanks Any more goal? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
final question about client certs using eap-tls (was: cert bootstrap bug?)
Hi, also was so many others. At this time i have got one eap module which authenticates users under a PKI. My client certs are issued by root ca (ca.pem) and everything works. I can manage the crl, because it is public, and authenticate any user against any server. So my question is, what's the final goal of signing certificates with server's? The only difference (i think) is about the crl managing, because in my case, the authority should provide the crl to the server administrators. I don't see any more difference. Thanks - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
disable FreeRadius checking of client certs
Is it possible to disable FreeRadius's checking of client certificates using EAP-TLS-PEAP? Certs can be quick a bother and a huge maintenance over-head. Thanks. FreeRadius 1.1.3 Travis J. WeaverSoftware EngineerOberon, Inc.1315 S. Allen St.Suite 405State College, PA 16801phone: (814)867-2312 ext. 210fax: (814)867-2314http://www.oberonwireless.com[EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: disable FreeRadius checking of client certs
devel [EMAIL PROTECTED] wrote: Is it possible to disable FreeRadius's checking of client certificates using EAP-TLS-PEAP? Certs can be quick a bother and a huge maintenance over-head. Thanks. Huh? Client certs are used for PEAP only when you deploy client certs to the end-user machines. Once they're deployed, they should really be checked. Perhasp you can explain why you've deployed client certs, but now don't want to use them. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: disable FreeRadius checking of client certs
Well, I have not issued certs to clients. Some of my clients have the option to log in with a username OR a cert. However, there are a few random Linksys cards (I guess I should have mentioned this was for Wifi/WPA) that I MUST provide a username and a cert. If there are no certs on the client machine, Linksys fills the cert in with Trust Any, so I assume it may be attempting with a blank? cert or another cert on the machine, such as VeriSign or the like.So this client is attempting to authenticate, I believe, with other certs on its machine because the radius log looks like below: Tue Oct 10 11:16:16 2006 : Error: TLS_accept:error in SSLv3 read client certificate A Tue Oct 10 11:16:16 2006 : Error: rlm_eap: SSL error error::lib(0):func(0):reason(0) Tue Oct 10 11:16:16 2006 : Error: TLS Alert read:fatal:unknown CA Tue Oct 10 11:16:16 2006 : Error: TLS_accept:failed in SSLv3 read client certificate A Tue Oct 10 11:16:16 2006 : Error: rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca Tue Oct 10 11:16:16 2006 : Error: rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails. Tue Oct 10 11:16:16 2006 : Error: rlm_eap: SSL error error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure Tue Oct 10 11:16:16 2006 : Error: rlm_eap_tls: BIO_read failed in a system call (-1), TLS session fails. I am not a FreeRadius expert so I may be misinterpreting the logs. Thanks. Travis - Original Message - From: Alan DeKok [EMAIL PROTECTED] To: devel [EMAIL PROTECTED]; FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Tuesday, October 10, 2006 10:27 AM Subject: Re: disable FreeRadius checking of client certs devel [EMAIL PROTECTED] wrote: Is it possible to disable FreeRadius's checking of client certificates using EAP-TLS-PEAP? Certs can be quick a bother and a huge maintenance over-head. Thanks. Huh? Client certs are used for PEAP only when you deploy client certs to the end-user machines. Once they're deployed, they should really be checked. Perhasp you can explain why you've deployed client certs, but now don't want to use them. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: disable FreeRadius checking of client certs
devel [EMAIL PROTECTED] wrote: Well, I have not issued certs to clients. Some of my clients have the option to log in with a username OR a cert. However, there are a few random Linksys cards (I guess I should have mentioned this was for Wifi/WPA) that I MUST provide a username and a cert. Ok... If there are no certs on the client machine, Linksys fills the cert in with Trust Any, so I assume it may be attempting with a blank? cert or another cert on the machine, such as VeriSign or the like.So this client is attempting to authenticate, I believe, with other certs on its machine because the radius log looks like below: Then your solution would be to actually install a client cert on those machines. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: disable FreeRadius checking of client certs
Thanks guys for your post. First off, I have tried using the WinXP supplicant and I have no problems authenticating with the Linksys wifi cards. I just wish the Linksys utility was like Cisco where I can tell it do provide either/or username/cert. The Cisco cards have no problem with this as where using the Linksys with its utility does not provide me with what I want. No big deal. Using the Linksys client utitliy, a username, password, and certificate must be provided (the certificate is a combo box so I can't even leave it blank). I have always preferred to use the utility that came with wifi cards for configuration. They typically provide more information and are more user friendly than the Windows supplicant. This problem does pertain to the Linksys software more than FreeRadius. I was just hoping there was a way in the FreeRadius config files to help solve the problem Travis - Original Message - From: Artur Hecker [EMAIL PROTECTED] To: devel [EMAIL PROTECTED]; FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Tuesday, October 10, 2006 12:42 PM Subject: Re: disable FreeRadius checking of client certs Hi Travis Excuse me for top-posting, but just as Alan I'm a bit surprised by your post. If your authentication system is based on certificates, you need certificates and you really should not say anything like certificates bother me since that is the only expression of your trust, so without that verification no authentication will ever be reasonable or complete. If it is not, you do not have certificates. Allowing both for the same client (same machine) is discouraged. Personally I am not familar with a supplicant which tries one and then another for the same username. Thus, per user if you are using EAP-PEAP-MSCHAPv2 (passwords), then you are not using EAP-TLS. And vice versa. The good news is: the authentication method has strictly nothing to do with the WiFi card; it is completely virtualized, in software. EAP is only a transporter protocol, it does not say how to authenticate, it only says how to transport data. Thus, if EAP is supported by the card, then *every* EAP method is supported. That's magic about 802.1X and that's why it's supported in the operating system rather than being supported by a network card. Now if you are saying that you use a special Linksys 802.1X client, then I would first suggest that you use the standard WinXP client. Sorry, but the Linksys client is fairly unknown. Practically, it's difficult to guess from what you provided, but I think that you do use the WinXP supplicant (i.e. 802.1X client - I do not know of any linksys supplicant) and that you probably want to use EAP-PEAP-MSCHAPv2. That involves one server certificate (obviously one common trust anker - a self signed CA certificate) and some username/passwords on clients. What probably happened is that in the two cases where the Linksys card is used, you did not correctly configure EAP-PEAP (called Protected EAP in WinXP or similar), but you let it be Smartcard or Certificate. Thus, the card tries to do TLS with some available pub/priv key combination, but Freeradius rejects it. Reconfigure the WinXP supplicant to do EAP-PEAP and it will ask you for passwords. Do not forget to deploy the server certificate on user machines... Well, I have not issued certs to clients. Some of my clients have the option to log in with a username OR a cert. However, there are a few random Linksys cards (I guess I should have mentioned this was for Wifi/WPA) that I MUST provide a username and a cert. Strictly speaking, every EAP session will take a Username and the AAA server will derive from it the authentication method to use. When used in EAP-TLS, Windows XP typically fills it out with the CN from the certificate (if available) but that is of course insufficient and it would be more correct to give an identifier and then to start a TLS authentication session for that id. (How exactly the username compares to the certified information is an open question, since the username can be altered by different means). If there are no certs on the client machine, Linksys fills the cert in with Trust Any, so I assume it may be attempting with a blank? cert or another cert on the machine, such as VeriSign or the like.So this client is attempting to authenticate, I believe, with other certs on its machine because the radius log looks like below: hmmm??? you can't just use any certificate for authentication. What you need is a pair: certificate/private key. Nobody except Verisign has their private key. The only option for your Linksys 802.1X client would be to spontaneously create a CA and to issue one user certificate for EAP authentication signed by the latter. That can be done by XP, but there is no interest in doing so. I would suggest you deploy passwords
re: Client certs with MSCHAPV2 in PEAP
Dave Huff dbhuff at yahoo.com http://lists.freeradius.org/mailman/listinfo/freeradius-users wrote: / For EAP-TLS to work, the client certs have to be // signed by the server cert. // Signed by the server cert or by the CA cert? I have a CA that signed the // server and client certs, and the eap.conf file knows where server and CA // certs are. / If you're using 1.0.x, that won't work. It doesn't do certificate chains. The client cert MUST be signed by the server cert. Using a CA to sign them, both won't work. I'm not even sure it will work in 1.1.0, to be honest. Alan DeKok In 1.1.0 I have chained client certificates and for me EAP-TLS works, if the client does not require the server to authenticate itself. The client cert is not signed by the server cert. It seems to be neccessary,that if you have a root ca and an issuing ca, the CA_file must contain the certificates of both of them. If the client requires the server to authenticate itself, the whole process fails. Norbert Wegener - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client certs with MSCHAPV2 in PEA
. From: Alan DeKok [EMAIL PROTECTED] Robert Myers [EMAIL PROTECTED] wrote: The reason I ask, is that I'm using a client cert signed by my CA to do eap/tls, and it's working. I have not implemented the server cert as of yet. Then it *should* work with PEAP. But I don't know of many people that use client certs with PEAP. I suspect no one has tested that, and that the client may be doing something different than with EAP-TLS. My suggestion is don't use client certs with PEAP. Alan DeKok. Ah well, I'm trying to authenticate both a machine (cert) and a user (password) to prevent people from using unchecked machines on the network. PEAP sort of does that I guess since the internal CA isn't set up on a client, but that's not a very secure method. Any suggestions appreciated and thanks for your help. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client certs with MSCHAPV2 in PEA
Dave Huff wrote: . From: Alan DeKok [EMAIL PROTECTED] Robert Myers [EMAIL PROTECTED] wrote: The reason I ask, is that I'm using a client cert signed by my CA to do eap/tls, and it's working. I have not implemented the server cert as of yet. Then it *should* work with PEAP. But I don't know of many people that use client certs with PEAP. I suspect no one has tested that, and that the client may be doing something different than with EAP-TLS. My suggestion is don't use client certs with PEAP. Alan DeKok. Ah well, I'm trying to authenticate both a machine (cert) and a user (password) to prevent people from using unchecked machines on the network. PEAP sort of does that I guess since the internal CA isn't set up on a client, but that's not a very secure method. Any suggestions appreciated and thanks for your help. Interesting. What client is this? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Client certs with MSCHAPV2 in PEA
Dave Huff wrote: . From: Alan DeKok [EMAIL PROTECTED] Robert Myers [EMAIL PROTECTED] wrote: The reason I ask, is that I'm using a client cert signed by my CA to do eap/tls, and it's working. I have not implemented the server cert as of yet. Then it *should* work with PEAP. But I don't know of many people that use client certs with PEAP. I suspect no one has tested that, and that the client may be doing something different than with EAP-TLS. My suggestion is don't use client certs with PEAP. Alan DeKok. Ah well, I'm trying to authenticate both a machine (cert) and a user (password) to prevent people from using unchecked machines on the network. PEAP sort of does that I guess since the internal CA isn't set up on a client, but that's not a very secure method. Any suggestions appreciated and thanks for your help. Interesting. What client is this? FC4/2.6.15-1.1831 Freeradius 1.0.4 Intel PROset 9.0.3.0 Is there a debug mode that would show me exactly which certs are being exchanged? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Client certs with MSCHAPV2 in PEAP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Dave Huff [EMAIL PROTECTED] wrote: rlm_eap_tls: TLS 1.0 Alert [length 0002], fatal certificate_unknown TLS Alert read:fatal:certificate unknown SSL is telling FreeRADIUS that the certificate sent by the client is bad. That's what I thought too, but I configured the CA, server, and client certs all on Openssl pretty much like http://www.cisco.com/en/US/products/ps6379/products_configuration_guide_chap ter09186a00805ac269.html Windows is using the cert I installed from the linux box, at least I have a choice in ProSET. If Windows overrides for some reason, I wouldn't know...can I set a debug mode that would tell me? You're probably doing EAP-TLS where the server has one cert, and the client has cert signed by someone else entirely. For EAP-TLS to work, the client certs have to be signed by the server cert. Signed by the server cert or by the CA cert? I have a CA that signed the server and client certs, and the eap.conf file knows where server and CA certs are. Dan Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client certs with MSCHAPV2 in PEAP
Dave Huff [EMAIL PROTECTED] wrote: For EAP-TLS to work, the client certs have to be signed by the server cert. Signed by the server cert or by the CA cert? I have a CA that signed the server and client certs, and the eap.conf file knows where server and CA certs are. If you're using 1.0.x, that won't work. It doesn't do certificate chains. The client cert MUST be signed by the server cert. Using a CA to sign them, both won't work. I'm not even sure it will work in 1.1.0, to be honest. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client certs with MSCHAPV2 in PEAP
Does this only apply if the supplicant uses a server cert during eap/tls? The reason I ask, is that I'm using a client cert signed by my CA to do eap/tls, and it's working. I have not implemented the server cert as of yet. -Bob Alan DeKok wrote: Dave Huff [EMAIL PROTECTED] wrote: For EAP-TLS to work, the client certs have to be signed by the server cert. Signed by the server cert or by the CA cert? I have a CA that signed the server and client certs, and the eap.conf file knows where server and CA certs are. If you're using 1.0.x, that won't work. It doesn't do certificate chains. The client cert MUST be signed by the server cert. Using a CA to sign them, both won't work. I'm not even sure it will work in 1.1.0, to be honest. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Client certs with MSCHAPV2 in PEAP
I would like to configure this setup using Freeradius. My WinXP client (Intel ProSET) supports this, but FR chokes on it when enabled. I've got PEAP-EAP-MSCHAPV2 working with just password authentication. I noted this http://www.opensubscriber.com/message/freeradius-users@lists.freeradius.org/ 1873393.html but was unable to figure out where the DEFAULT EAP-TLS-Require-Client-Cert := Yes should be set. Relative Linux/Freeradius noob, FC4/2.6.15-1.1831 Freeradius 1.0.4 Thanks, Dan H - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client certs with MSCHAPV2 in PEAP
Looks like that's set in the users file. As the entry for that email says DEFAULT. Dave Huff wrote: I would like to configure this setup using Freeradius. My WinXP client (Intel ProSET) supports this, but FR chokes on it when enabled. I've got PEAP-EAP-MSCHAPV2 working with just password authentication. I noted this http://www.opensubscriber.com/message/freeradius-users@lists.freeradius.org/ 1873393.html but was unable to figure out where the DEFAULT EAP-TLS-Require-Client-Cert := Yes should be set. Relative Linux/Freeradius noob, FC4/2.6.15-1.1831 Freeradius 1.0.4 Thanks, Dan H - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client certs with MSCHAPV2 in PEAP
Dave Huff [EMAIL PROTECTED] wrote: I would like to configure this setup using Freeradius. My WinXP client (Intel ProSET) supports this, but FR chokes on it when enabled. Would you be willing to run the serve rin debugging mode, as suggested in the FAQ, README, INSTALL, and daily on this list? I noted this http://www.opensubscriber.com/message/freeradius-users@lists.freeradius.org/ 1873393.html but was unable to figure out where the DEFAULT EAP-TLS-Require-Client-Cert := Yes should be set. In the users file. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Client certs with MSCHAPV2 in PEAP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Dave Huff [EMAIL PROTECTED] wrote: I would like to configure this setup using Freeradius. My WinXP client (Intel ProSET) supports this, but FR chokes on it when enabled. Would you be willing to run the serve rin debugging mode, as suggested in the FAQ, README, INSTALL, and daily on this list? Sure, thought my question needed a quick answer, but here I've included the log AFTER inserting the line in the users file, and turning on the client cert part of MSCHAPV2 in ProSET: snip auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Requiring client certificate rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module eap returns handled for request 0 modcall: group authenticate returns handled for request 0 Sending Access-Challenge of id 71 to 192.168.0.1:1201 EAP-Message = 0x010200061920 Message-Authenticator = 0x State = 0xd4448443a5823bb9ceffabd590f27721 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 71 with timestamp 43fcc0a4 Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 192.168.0.1:1201, id=72, length=243 User-Name = [EMAIL PROTECTED] NAS-IP-Address = 192.168.0.1 NAS-Port = 0 Called-Station-Id = 00-0f-3d-3f-49-92 Calling-Station-Id = 00-0e-35-60-27-1f NAS-Identifier = HomeAP Framed-MTU = 1380 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0202006a19800060160301005b0157030143fcc0c5eb46025dd5e3662940ba6406 6bed01df2be7d94eb754c77da12672c33000390038003500160013000a00330032002f00 66000500040065006400630062006000150012000900140011000800030100 State = 0xd4448443a5823bb9ceffabd590f27721 Message-Authenticator = 0xdcd7050a2c3750c9314d44818cf15867 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module preprocess returns ok for request 1 modcall[authorize]: module mschap returns noop for request 1 rlm_realm: Looking up realm b.com for User-Name = [EMAIL PROTECTED] rlm_realm: No such realm b.com modcall[authorize]: module suffix returns noop for request 1 rlm_eap: EAP packet type response id 2 length 106 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 1 users: Matched entry DEFAULT at line 75 modcall[authorize]: module files returns ok for request 1 modcall: group authorize returns updated for request 1 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 (other): before/accept initialization TLS_accept: before/accept initialization rlm_eap_tls: TLS 1.0 Handshake [length 005b], ClientHello TLS_accept: SSLv3 read client hello A rlm_eap_tls: TLS 1.0 Handshake [length 004a], ServerHello TLS_accept: SSLv3 write server hello A rlm_eap_tls: TLS 1.0 Handshake [length 0780], Certificate TLS_accept: SSLv3 write certificate A rlm_eap_tls: TLS 1.0 Handshake [length 0074], CertificateRequest TLS_accept: SSLv3 write certificate request A TLS_accept: SSLv3 flush data TLS_accept:error in SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED modcall[authenticate]: module eap returns handled for request 1 modcall: group authenticate returns handled for request 1 Sending Access-Challenge of id 72 to 192.168.0.1:1201 EAP-Message = 0x0103040a19c0084d160301004a0246030143fcc0c6b503405d5825db4720dc2d66 93c9570afd72cd19086b5e9d890c2f4f2010fa22c781d6954b8b8a8a8d1e7c1f3fc0d5bbf96b c540e87c90018c4636459f00350016030107800b00077c00077900035d3082035930820241a0 03020102020102300d06092a864886f70d01010405003063310b300906035504061302555331 1530130603550408130c50656e6e73796c76616e69613112301006035504071309576f726365 7374657231153013060355040a130c4944205761746368646f67733112301006035504031309 54726f6f7065724341301e170d3036303231393033313332325a EAP-Message = 0x170d3037303231393033313332325a3064310b300906035504061302555331153013060355 0408130c50656e6e73796c76616e69613112301006035504071309576f726365737465723115 3013060355040a130c4944205761746368646f6773311330110603550403130a54726f6f7065
Re: Client certs with MSCHAPV2 in PEAP
Dave Huff [EMAIL PROTECTED] wrote: rlm_eap_tls: TLS 1.0 Alert [length 0002], fatal certificate_unknown TLS Alert read:fatal:certificate unknown SSL is telling FreeRADIUS that the certificate sent by the client is bad. You're probably doing EAP-TLS where the server has one cert, and the client has cert signed by someone else entirely. For EAP-TLS to work, the client certs have to be signed by the server cert. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS: limiting client certs to a select group
On Wed, 16 Mar 2005 00:27:03 -0600, Jon Franklin [EMAIL PROTECTED] wrote: On Wed, 16 Mar 2005 00:09:09 -0600, David Duchscher [EMAIL PROTECTED] wrote: I am a little behind you at the moment so really hoping this helps you. Have you set CA_path in the configuration file to point somewhere else? From the code, it looks like CA_path is set to default if you don't set it in the configuration file. I haven't. I may have misunderstood the comments in the eap.conf file, but my take on it was that CA_path is used for crl checking. So the only time I had that variable set to something meaningful was when I also set check_crl = yes. And that caused all client certificate validation to die horribly. I'll definitely check it out tomorrow, though, and post here with the results. Looks like this was exactly what I needed. I set CA_path to the directory where my CA cert is, and only certificates issued by my local CA are accepted. Here's that portion of the eap.conf: tls { private_key_password = dont-you-wish private_key_file = ${raddbdir}/certs/radiusSrvprivkey.pem certificate_file = ${raddbdir}/certs/radiusSrvprivkey.pem CA_file = ${raddbdir}/certs/demoCA/radiusRootcert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1024 include_length = yes CA_path=${raddbdir}/certs/demoCA #check_crl = no check_cert_cn = %{User-Name} } Thank you so much for the tip! -- Jon Franklin [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS: limiting client certs to a select group
Jon Franklin wrote: I tried using my own hand-generated SSL certs, as well as a set generated by the certs.sh script, and get the same type of problem. Question: if the CA_file certificate contains a private key, would this cause my problem? I don't think it has one, but can't say with certainty until I get in to work tomorrow and check it out. It does not _need_ the private key, I have not tried it with one. One clue I've been seeing is if I check_crl = yes, no certificate gets validated at all; set it to no and any client cert will allow the client into my network. The check_crl is for certificate revocation and unless you have things explicitly setup for that it should be set to no. Thanks! Could you please post the debug log? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS: limiting client certs to a select group
Jon Franklin [EMAIL PROTECTED] wrote: On a follow-up to this, I found that the certificate I was using (Thawte Freemail Member) was being validated against a set of root certs in /usr/share/ssl/certs/ca-bundle.crt (I'm using Fedora Core 3, btw). There's probably some global OpenSSL config somewhere So I'm getting much closer to a solution. I don't want to get rid of all the CA certs in /usr/share/ssl, and only want freeradius to use the root cert I specify in the CA_file line. Can anyone tell me how that's done? Or is it even possible? It should be possible. I don't know how to convince OpenSSL to do that, though. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS: limiting client certs to a select group
On Mar 15, 2005, at 11:46 PM, Jon Franklin wrote: On Tue, 15 Mar 2005 18:59:02 -0500, Alan DeKok [EMAIL PROTECTED] wrote: Jon Franklin [EMAIL PROTECTED] wrote: On a follow-up to this, I found that the certificate I was using (Thawte Freemail Member) was being validated against a set of root certs in /usr/share/ssl/certs/ca-bundle.crt (I'm using Fedora Core 3, btw). There's probably some global OpenSSL config somewhere Does anyone here use EAP-TLS? How are you limiting the client certificates that freeradius will allow through? I guess if I can have a whitelist of clients in an sql database (or something to that effect) that can be checked _after_ EAP-TLS does its thing, that would work... Would it? I can't be the first person to have stumbled over this problem, can I? I am a little behind you at the moment so really hoping this helps you. Have you set CA_path in the configuration file to point somewhere else? From the code, it looks like CA_path is set to default if you don't set it in the configuration file. Dave - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS: limiting client certs to a select group
On Wed, 16 Mar 2005 00:09:09 -0600, David Duchscher [EMAIL PROTECTED] wrote: I am a little behind you at the moment so really hoping this helps you. Have you set CA_path in the configuration file to point somewhere else? From the code, it looks like CA_path is set to default if you don't set it in the configuration file. I haven't. I may have misunderstood the comments in the eap.conf file, but my take on it was that CA_path is used for crl checking. So the only time I had that variable set to something meaningful was when I also set check_crl = yes. And that caused all client certificate validation to die horribly. I'll definitely check it out tomorrow, though, and post here with the results. -- Jon Franklin [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TLS: limiting client certs to a select group
I've managed to get freeradius 1.0.1 working with EAP-TTLS, PEAP, and TLS (mostly), but I found that with EAP-TLS, I can use any client certificate I want, and freeradius will allow the client through. This presents a major security hole in my configuration, and I can't seem to figure out how to lock it down. Is there a way to configure freeradius to only accept client certs issued by a specific CA? Either that or only allow a specific set of certs (say, copies of the certs in a directory, for example), either way would be fine for my purposes. -- Jon Franklin [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS: limiting client certs to a select group
I tried using my own hand-generated SSL certs, as well as a set generated by the certs.sh script, and get the same type of problem. Question: if the CA_file certificate contains a private key, would this cause my problem? I don't think it has one, but can't say with certainty until I get in to work tomorrow and check it out. One clue I've been seeing is if I check_crl = yes, no certificate gets validated at all; set it to no and any client cert will allow the client into my network. Thanks! On Tue, 15 Mar 2005 00:21:19 +0100, Michael Riviera [EMAIL PROTECTED] wrote: Use this in eap.conf: CA_file = /path/to/certs/ca-cert.pem ca-cert.pem should contain the certificate, but not private key, of your CA. Michael Jon Franklin wrote: I've managed to get freeradius 1.0.1 working with EAP-TTLS, PEAP, and TLS (mostly), but I found that with EAP-TLS, I can use any client certificate I want, and freeradius will allow the client through. This presents a major security hole in my configuration, and I can't seem to figure out how to lock it down. Is there a way to configure freeradius to only accept client certs issued by a specific CA? Either that or only allow a specific set of certs (say, copies of the certs in a directory, for example), either way would be fine for my purposes. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Jon Franklin [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html