client certs signed by server certs

2009-09-15 Thread Piotr Honik


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

2008-12-11 Thread Andrew Hood
[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

2008-12-11 Thread tnt
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

2008-12-10 Thread Craig White
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

2008-12-10 Thread tnt
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

2008-12-10 Thread Craig White
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

2008-12-10 Thread Jason Wittlin-Cohen
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

2008-12-10 Thread tnt
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

2008-12-10 Thread Craig White
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

2008-12-10 Thread Jason Wittlin-Cohen
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

2008-12-10 Thread Craig White
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

2008-12-10 Thread tnt
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

2008-12-10 Thread tnt
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

2008-12-10 Thread Craig White
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

2008-12-10 Thread Jason Wittlin-Cohen
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

2008-12-10 Thread Craig White
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?)

2008-08-19 Thread Sergio

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?)

2008-08-18 Thread Sergio

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

2006-10-10 Thread devel



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

2006-10-10 Thread Alan DeKok
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

2006-10-10 Thread devel
   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

2006-10-10 Thread Alan DeKok
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

2006-10-10 Thread devel
   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

2006-02-27 Thread Norbert Wegener

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

2006-02-24 Thread Dave Huff
.
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

2006-02-24 Thread Phil Mayers

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

2006-02-24 Thread Dave Huff
 
 
 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

2006-02-23 Thread Dave Huff
 

 -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

2006-02-23 Thread Alan DeKok
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

2006-02-23 Thread Robert Myers

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

2006-02-22 Thread Dave Huff
 
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

2006-02-22 Thread Robert Myers
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

2006-02-22 Thread 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?

 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

2006-02-22 Thread Dave Huff
 

 -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

2006-02-22 Thread 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.

  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

2005-03-16 Thread Jon Franklin
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

2005-03-15 Thread Michael Riviera
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

2005-03-15 Thread Alan DeKok
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

2005-03-15 Thread David Duchscher
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

2005-03-15 Thread Jon Franklin
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

2005-03-14 Thread Jon Franklin
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

2005-03-14 Thread Jon Franklin
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