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
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: 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
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
