Freeradius2 and OSX clients no TLS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues. I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients. When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert: Sat Mar 5 16:21:28 2011 : Error: --> verify error:num=19:self signed certificate in certificate chain Sat Mar 5 16:21:28 2011 : Error: TLS Alert write:fatal:unknown CA Sat Mar 5 16:21:28 2011 : Error: TLS_accept:error in SSLv3 read client certificate B Sat Mar 5 16:21:28 2011 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned Sat Mar 5 16:21:28 2011 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Sat Mar 5 16:21:28 2011 : Auth: Login incorrect: [guy/<via Auth-Type = EAP>] (from client extreme port 0 cli 00-19-E3-E1-BA-C5) However if I do change the 802.1x settings on the mac to not try and to TLS then I'm able to connect just fine. either by PEAP, or TTLS.. So finally my question... How can I reconfigure Radius to not try and offer TLS or if it does offer TLS to not die if a cert is not presented?? I have tried some suggestions such as commenting out the CA in the eap.conf file, but still I fail to pass the TLS. Thanks - ---Guy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk1yaQcACgkQDc8ue1+sfKEcAQCfYRVtzNb1UcRa9hf+PM3ipToT zCgAn2TGSTOAjigyWLYwTm4HDcy12l9L =JyX7 -----END PGP SIGNATURE-----
FR just does what its told. I think the settings need to be changed on your wireless gear. ----- Original Message ----- From: Guy [mailto:guy@britewhite.net] Sent: Saturday, March 05, 2011 10:46 AM To: freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org> Subject: Freeradius2 and OSX clients no TLS -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues. I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients. When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert: Sat Mar 5 16:21:28 2011 : Error: --> verify error:num=19:self signed certificate in certificate chain Sat Mar 5 16:21:28 2011 : Error: TLS Alert write:fatal:unknown CA Sat Mar 5 16:21:28 2011 : Error: TLS_accept:error in SSLv3 read client certificate B Sat Mar 5 16:21:28 2011 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned Sat Mar 5 16:21:28 2011 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Sat Mar 5 16:21:28 2011 : Auth: Login incorrect: [guy/<via Auth-Type = EAP>] (from client extreme port 0 cli 00-19-E3-E1-BA-C5) However if I do change the 802.1x settings on the mac to not try and to TLS then I'm able to connect just fine. either by PEAP, or TTLS.. So finally my question... How can I reconfigure Radius to not try and offer TLS or if it does offer TLS to not die if a cert is not presented?? I have tried some suggestions such as commenting out the CA in the eap.conf file, but still I fail to pass the TLS. Thanks - ---Guy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk1yaQcACgkQDc8ue1+sfKEcAQCfYRVtzNb1UcRa9hf+PM3ipToT zCgAn2TGSTOAjigyWLYwTm4HDcy12l9L =JyX7 -----END PGP SIGNATURE----- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
Just a side question, how did you get Freedradius to give you a login window? i tried this and couldn't see how to get it to work.. so had to use another portal for this. On 5/03/2011 2:10 PM, Gary Gatten wrote:
FR just does what its told. I think the settings need to be changed on your wireless gear.
----- Original Message ----- From: Guy [mailto:guy@britewhite.net] Sent: Saturday, March 05, 2011 10:46 AM To: freeradius-users@lists.freeradius.org<freeradius-users@lists.freeradius.org> Subject: Freeradius2 and OSX clients no TLS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues.
I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients.
When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert:
Sat Mar 5 16:21:28 2011 : Error: --> verify error:num=19:self signed certificate in certificate chain Sat Mar 5 16:21:28 2011 : Error: TLS Alert write:fatal:unknown CA Sat Mar 5 16:21:28 2011 : Error: TLS_accept:error in SSLv3 read client certificate B Sat Mar 5 16:21:28 2011 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned Sat Mar 5 16:21:28 2011 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Sat Mar 5 16:21:28 2011 : Auth: Login incorrect: [guy/<via Auth-Type = EAP>] (from client extreme port 0 cli 00-19-E3-E1-BA-C5)
However if I do change the 802.1x settings on the mac to not try and to TLS then I'm able to connect just fine. either by PEAP, or TTLS..
So finally my question... How can I reconfigure Radius to not try and offer TLS or if it does offer TLS to not die if a cert is not presented??
I have tried some suggestions such as commenting out the CA in the eap.conf file, but still I fail to pass the TLS.
Thanks
- ---Guy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
iEYEARECAAYFAk1yaQcACgkQDc8ue1+sfKEcAQCfYRVtzNb1UcRa9hf+PM3ipToT zCgAn2TGSTOAjigyWLYwTm4HDcy12l9L =JyX7 -----END PGP SIGNATURE-----
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
<font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
it wasn't Freeradius providing the login window, it was OSX... trying to logon to the WiFi Network --Guy On 5 Mar 2011, at 17:26, Luke Hammond wrote:
Just a side question, how did you get Freedradius to give you a login window? i tried this and couldn't see how to get it to work.. so had to use another portal for this.
FR just does what its told. I think the settings need to be changed on your wireless gear.
----- Original Message ----- From: Guy [mailto:guy@britewhite.net] Sent: Saturday, March 05, 2011 10:46 AM To: freeradius-users@lists.freeradius.org<freeradius-users@lists.freeradius.org> Subject: Freeradius2 and OSX clients no TLS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues.
I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients.
When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert:
Sat Mar 5 16:21:28 2011 : Error: --> verify error:num=19:self signed certificate in certificate chain Sat Mar 5 16:21:28 2011 : Error: TLS Alert write:fatal:unknown CA Sat Mar 5 16:21:28 2011 : Error: TLS_accept:error in SSLv3 read client certificate B Sat Mar 5 16:21:28 2011 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned Sat Mar 5 16:21:28 2011 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Sat Mar 5 16:21:28 2011 : Auth: Login incorrect: [guy/<via Auth-Type = EAP>] (from client extreme port 0 cli 00-19-E3-E1-BA-C5)
However if I do change the 802.1x settings on the mac to not try and to TLS then I'm able to connect just fine. either by PEAP, or TTLS..
So finally my question... How can I reconfigure Radius to not try and offer TLS or if it does offer TLS to not die if a cert is not presented??
I have tried some suggestions such as commenting out the CA in the eap.conf file, but still I fail to pass the TLS.
Thanks
- ---Guy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
iEYEARECAAYFAk1yaQcACgkQDc8ue1+sfKEcAQCfYRVtzNb1UcRa9hf+PM3ipToT zCgAn2TGSTOAjigyWLYwTm4HDcy12l9L =JyX7 -----END PGP SIGNATURE-----
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
<font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 5/03/2011 2:10 PM, Gary Gatten wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ahh ok. thanks. THought you were talking about a captive portal. On 5/03/2011 2:39 PM, Guy wrote:
it wasn't Freeradius providing the login window, it was OSX... trying to logon to the WiFi Network
--Guy
On 5 Mar 2011, at 17:26, Luke Hammond wrote:
Just a side question, how did you get Freedradius to give you a login window? i tried this and couldn't see how to get it to work.. so had to use another portal for this.
FR just does what its told. I think the settings need to be changed on your wireless gear.
----- Original Message ----- From: Guy [mailto:guy@britewhite.net] Sent: Saturday, March 05, 2011 10:46 AM To: freeradius-users@lists.freeradius.org<freeradius-users@lists.freeradius.org> Subject: Freeradius2 and OSX clients no TLS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues.
I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients.
When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert:
Sat Mar 5 16:21:28 2011 : Error: --> verify error:num=19:self signed certificate in certificate chain Sat Mar 5 16:21:28 2011 : Error: TLS Alert write:fatal:unknown CA Sat Mar 5 16:21:28 2011 : Error: TLS_accept:error in SSLv3 read client certificate B Sat Mar 5 16:21:28 2011 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned Sat Mar 5 16:21:28 2011 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Sat Mar 5 16:21:28 2011 : Auth: Login incorrect: [guy/<via Auth-Type = EAP>] (from client extreme port 0 cli 00-19-E3-E1-BA-C5)
However if I do change the 802.1x settings on the mac to not try and to TLS then I'm able to connect just fine. either by PEAP, or TTLS..
So finally my question... How can I reconfigure Radius to not try and offer TLS or if it does offer TLS to not die if a cert is not presented??
I have tried some suggestions such as commenting out the CA in the eap.conf file, but still I fail to pass the TLS.
Thanks
- ---Guy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
iEYEARECAAYFAk1yaQcACgkQDc8ue1+sfKEcAQCfYRVtzNb1UcRa9hf+PM3ipToT zCgAn2TGSTOAjigyWLYwTm4HDcy12l9L =JyX7 -----END PGP SIGNATURE-----
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
<font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 5/03/2011 2:10 PM, Gary Gatten wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
That comes later! :) --Guy On 5 Mar 2011, at 17:56, Luke Hammond wrote:
Ahh ok. thanks. THought you were talking about a captive portal.
it wasn't Freeradius providing the login window, it was OSX... trying to logon to the WiFi Network
--Guy
On 5 Mar 2011, at 17:26, Luke Hammond wrote:
Just a side question, how did you get Freedradius to give you a login window? i tried this and couldn't see how to get it to work.. so had to use another portal for this.
FR just does what its told. I think the settings need to be changed on your wireless gear.
----- Original Message ----- From: Guy [mailto:guy@britewhite.net] Sent: Saturday, March 05, 2011 10:46 AM To: freeradius-users@lists.freeradius.org<freeradius-users@lists.freeradius.org> Subject: Freeradius2 and OSX clients no TLS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues.
I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients.
When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert:
Sat Mar 5 16:21:28 2011 : Error: --> verify error:num=19:self signed certificate in certificate chain Sat Mar 5 16:21:28 2011 : Error: TLS Alert write:fatal:unknown CA Sat Mar 5 16:21:28 2011 : Error: TLS_accept:error in SSLv3 read client certificate B Sat Mar 5 16:21:28 2011 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned Sat Mar 5 16:21:28 2011 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Sat Mar 5 16:21:28 2011 : Auth: Login incorrect: [guy/<via Auth-Type = EAP>] (from client extreme port 0 cli 00-19-E3-E1-BA-C5)
However if I do change the 802.1x settings on the mac to not try and to TLS then I'm able to connect just fine. either by PEAP, or TTLS..
So finally my question... How can I reconfigure Radius to not try and offer TLS or if it does offer TLS to not die if a cert is not presented??
I have tried some suggestions such as commenting out the CA in the eap.conf file, but still I fail to pass the TLS.
Thanks
- ---Guy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
iEYEARECAAYFAk1yaQcACgkQDc8ue1+sfKEcAQCfYRVtzNb1UcRa9hf+PM3ipToT zCgAn2TGSTOAjigyWLYwTm4HDcy12l9L =JyX7 -----END PGP SIGNATURE-----
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
<font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 5/03/2011 2:10 PM, Gary Gatten wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 5/03/2011 2:39 PM, Guy wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cool, well if you need that part, i have Coovachilli running quite nicely.. I thought that Freeradius had its own captive portal, but couldnt see any way to get it working On 5/03/2011 3:08 PM, Guy wrote: > That comes later! :) > > --Guy > > On 5 Mar 2011, at 17:56, Luke Hammond wrote: > >> Ahh ok. thanks. THought you were talking about a captive portal. >> >> On 5/03/2011 2:39 PM, Guy wrote: >>> it wasn't Freeradius providing the login window, it was OSX... trying to logon to the WiFi Network >>> >>> --Guy >>> >>> On 5 Mar 2011, at 17:26, Luke Hammond wrote: >>> >>>> Just a side question, how did you get Freedradius to give you a login window? i tried this and couldn't see how to get it to work.. so had to use another portal for this. >>>> >>>> >>>> On 5/03/2011 2:10 PM, Gary Gatten wrote: >>>>> FR just does what its told. I think the settings need to be changed on your wireless gear. >>>>> >>>>> ----- Original Message ----- >>>>> From: Guy [mailto:guy@britewhite.net] >>>>> Sent: Saturday, March 05, 2011 10:46 AM >>>>> To: freeradius-users@lists.freeradius.org<freeradius-users@lists.freeradius.org> >>>>> Subject: Freeradius2 and OSX clients no TLS >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Hi, >>>>> >>>>> I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues. >>>>> >>>>> I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients. >>>>> >>>>> When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert: >>>>> >>>>> Sat Mar 5 16:21:28 2011 : Error: --> verify error:num=19:self signed certificate in certificate chain >>>>> Sat Mar 5 16:21:28 2011 : Error: TLS Alert write:fatal:unknown CA >>>>> Sat Mar 5 16:21:28 2011 : Error: TLS_accept:error in SSLv3 read client certificate B >>>>> Sat Mar 5 16:21:28 2011 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned >>>>> Sat Mar 5 16:21:28 2011 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. >>>>> Sat Mar 5 16:21:28 2011 : Auth: Login incorrect: [guy/<via Auth-Type = EAP>] (from client extreme port 0 cli 00-19-E3-E1-BA-C5) >>>>> >>>>> >>>>> However if I do change the 802.1x settings on the mac to not try and to TLS then I'm able to connect just fine. either by PEAP, or TTLS.. >>>>> >>>>> So finally my question... How can I reconfigure Radius to not try and offer TLS or if it does offer TLS to not die if a cert is not presented?? >>>>> >>>>> I have tried some suggestions such as commenting out the CA in the eap.conf file, but still I fail to pass the TLS. >>>>> >>>>> Thanks >>>>> >>>>> - ---Guy >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >>>>> >>>>> iEYEARECAAYFAk1yaQcACgkQDc8ue1+sfKEcAQCfYRVtzNb1UcRa9hf+PM3ipToT >>>>> zCgAn2TGSTOAjigyWLYwTm4HDcy12l9L >>>>> =JyX7 >>>>> -----END PGP SIGNATURE----- >>>>> >>>>> - >>>>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> <font size="1"> >>>>> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> >>>>> </div> >>>>> "This email is intended to be reviewed by only the intended recipient >>>>> and may contain information that is privileged and/or confidential. >>>>> If you are not the intended recipient, you are hereby notified that >>>>> any review, use, dissemination, disclosure or copying of this email >>>>> and its attachments, if any, is strictly prohibited. If you have >>>>> received this email in error, please immediately notify the sender by >>>>> return email and delete this email from your system." >>>>> </font> >>>>> >>>>> >>>>> - >>>>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html >>>> - >>>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html >>> - >>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html >> - >> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 03/05/2011 04:46 PM, Guy wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues.
I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients.
When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert:
EAP-TLS *requires* a client cert. If you want to use EAP-TLS, you will have to do something on the clients. If you want to use PEAP or something, there are two things to consider - the default eap type in eap.conf: eap { default_eap_type = peap ... } ...and the default EAP type on MacOS. PEAP & TTLS require the "tls" EAP type to be configured I think; I'm not sure you can disable EAP-TLS, as this will break PEAP & TTLS. The best you can do is change the default types. If changing it on the server doesn't accomplish it, then I think you're going to have to do some config on the clients.
On 6 Mar 2011, at 13:03, Phil Mayers wrote:
On 03/05/2011 04:46 PM, Guy wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues.
I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients.
When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert:
EAP-TLS *requires* a client cert. If you want to use EAP-TLS, you will have to do something on the clients.
If you want to use PEAP or something, there are two things to consider - the default eap type in eap.conf:
eap { default_eap_type = peap ... }
...and the default EAP type on MacOS.
PEAP & TTLS require the "tls" EAP type to be configured I think; I'm not sure you can disable EAP-TLS, as this will break PEAP & TTLS. The best you can do is change the default types.
If changing it on the server doesn't accomplish it, then I think you're going to have to do some config on the clients. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yup that was it... I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!! Cheers, --Guy
--On 6 March 2011 16:31:54 +0000 Guy <guy@britewhite.net> wrote:
On 6 Mar 2011, at 13:03, Phil Mayers wrote:
On 03/05/2011 04:46 PM, Guy wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm setting up Freeradius2 (FreeRADIUS Version 2.1.7) for WPA Enterprise 2, and I have it basically working. my iPhone/iPad are able to authenticate and connect via the base station. However my Mac (OSX 10.6 Snow leopard) Laptops are having issues.
I do not want to push out Client certificates to the laptops. I also do not want people to have to perform any customisations on the clients.
When the laptop attempts to join the network I get a nice login window, with username/password. This is fine. However without playing with the network settings (802.1x settings). I'm not able to join the network because I do not have a client Cert:
...
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!!
...remember though that working != secure [necessarily]. Clients defaulting to accept any radius server cert, or those that default to prompt the user, are vulnerable to rogue AP/credential stealing attacks etc. This may be acceptable in your environment, but if not, you'll still need to actively configure the client. -James -- James J J Hooper Network Specialist, University of Bristol http://www.wireless.bristol.ac.uk --
Hi,
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!!
I'm guessing that MD5 isnt a valid 'ready ticked' EAP type by default. you would probably be okay putting eg default_eap_type=peap too I'd also agree with James too - you really dont want to just allow a dumb 'click and go' configuration to be valid on a client - otherwise a malicious person could spoof your SSID and your RADIUS server and then clients could try authenticating against the bad RADIUS server with no warnings for the user. if using TTLS/PAP that could be very bad alan
Yes I understand and agree.. However in this environment I think we'll be ok. Thanks --Guy On 6 Mar 2011, at 19:22, Alan Buxey wrote:
Hi,
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!!
I'm guessing that MD5 isnt a valid 'ready ticked' EAP type by default. you would probably be okay putting eg default_eap_type=peap too
I'd also agree with James too - you really dont want to just allow a dumb 'click and go' configuration to be valid on a client - otherwise a malicious person could spoof your SSID and your RADIUS server and then clients could try authenticating against the bad RADIUS server with no warnings for the user. if using TTLS/PAP that could be very bad
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!!
...remember though that working != secure [necessarily]. Clients defaulting to accept any radius server cert, or those that default to prompt the user, are vulnerable to rogue AP/credential stealing attacks etc. This may be acceptable in your environment, but if not, you'll still need to actively configure the client.
I've seen statements on this list in the past asserting that if you have a server cert signed by a public CA (e.g. a CA the client is preconfigured to trust) it is a security vulnerability because clients will blindly trust they are connecting to server they expect when in fact it could be a rouge server impersonating the server. The above comment seems to fall into the same category. I have never understood this advice or it's rationale. I was hoping someone could explain it because it does not match my understanding of PKI, here's why: When a client negotiates a SSL/TLS session it's supposed to validate the server cert. In simplicity this is a 2 step process. 1) It validates the server cert to assure it's signed by a CA it trusts (possibly via a cert chain). 2) It then validates the certificate subject to make sure the server it thought it was connecting to appears in the certificate (either as the certificate subject or one of the certificate subject alternate names). If either 1 or 2 fails it should abort the connection. If it were possible on an SSL/TLS connection to impersonate another server then most of PKI would be a complete failure. So why does this group think PKI doesn't work? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
1) It validates the server cert to assure it's signed by a CA it trusts (possibly via a cert chain).
2) It then validates the certificate subject to make sure the server it thought it was connecting to appears in the certificate (either as the certificate subject or one of the certificate subject alternate names).
If either 1 or 2 fails it should abort the connection.
If it were possible on an SSL/TLS connection to impersonate another server then most of PKI would be a complete failure.
So why does this group think PKI doesn't work?
check the supplicant configuration. note the parts where the client can be told to validate that the server has a particular CN. thats the issue. if the client knows the CA then it can be happily duped...one of the causes of this is with eg HTTPS, the client is told to connect to a particular host name entry...and there are A records to check etc. with 802.1X its just EAP. layer 2 physical, no way of doing anything else. alan
On Mar 7, 2011, at 3:57 PM, Alan Buxey wrote:
Hi,
1) It validates the server cert to assure it's signed by a CA it trusts (possibly via a cert chain).
2) It then validates the certificate subject to make sure the server it thought it was connecting to appears in the certificate (either as the certificate subject or one of the certificate subject alternate names).
If either 1 or 2 fails it should abort the connection.
If it were possible on an SSL/TLS connection to impersonate another server then most of PKI would be a complete failure.
So why does this group think PKI doesn't work?
check the supplicant configuration. note the parts where the client can be told to validate that the server has a particular CN.
thats the issue. if the client knows the CA then it can be happily duped...one of the causes of this is with eg HTTPS, the client is told to connect to a particular host name entry...and there are A records to check etc. with 802.1X its just EAP. layer 2 physical, no way of doing anything else.
Uhuh relying on a for profit organisation to properly verify the information provided for every CSR that comes its way seems like a bad idea to me too. -Arran
On Mar 7, 2011, at 4:03 PM, Arran Cudbard-Bell wrote:
On Mar 7, 2011, at 3:57 PM, Alan Buxey wrote:
Hi,
1) It validates the server cert to assure it's signed by a CA it trusts (possibly via a cert chain).
2) It then validates the certificate subject to make sure the server it thought it was connecting to appears in the certificate (either as the certificate subject or one of the certificate subject alternate names).
If either 1 or 2 fails it should abort the connection.
If it were possible on an SSL/TLS connection to impersonate another server then most of PKI would be a complete failure.
So why does this group think PKI doesn't work?
check the supplicant configuration. note the parts where the client can be told to validate that the server has a particular CN.
thats the issue. if the client knows the CA then it can be happily duped...one of the causes of this is with eg HTTPS, the client is told to connect to a particular host name entry...and there are A records to check etc. with 802.1X its just EAP. layer 2 physical, no way of doing anything else.
Uhuh relying on a for profit organisation to properly verify the information provided for every CSR that comes its way seems like a bad idea to me too.
Though I guess there's probably no box saying 'I promise not to use this certificate to harvest credentials from another one of your customers'... and I guess that should be 3rd party...
On 07/03/2011 21:42, John Dennis wrote:
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!!
...remember though that working != secure [necessarily]. Clients defaulting to accept any radius server cert, or those that default to prompt the user, are vulnerable to rogue AP/credential stealing attacks etc. This may be acceptable in your environment, but if not, you'll still need to actively configure the client.
I've seen statements on this list in the past asserting that if you have a server cert signed by a public CA (e.g. a CA the client is preconfigured to trust) it is a security vulnerability because clients will blindly trust they are connecting to server they expect when in fact it could be a rouge server impersonating the server. The above comment seems to fall into the same category.
I have never understood this advice or it's rationale. I was hoping someone could explain it because it does not match my understanding of PKI, here's why:
When a client negotiates a SSL/TLS session it's supposed to validate the server cert. In simplicity this is a 2 step process.
1) It validates the server cert to assure it's signed by a CA it trusts (possibly via a cert chain).
2) It then validates the certificate subject to make sure the server it thought it was connecting to appears in the certificate (either as the certificate subject or one of the certificate subject alternate names).
If either 1 or 2 fails it should abort the connection.
If it were possible on an SSL/TLS connection to impersonate another server then most of PKI would be a complete failure.
So why does this group think PKI doesn't work?
Hi John, Ok, first your (1) - matching a presented server cert to a pre-trusted CA cert on the client. This "works" and does exactly that. Consider this: * The client will validate my cert against the CA I signed it with. * The client will also validate a cert that "badPerson" has purchased from e.g. verisign Why - because an unconfigured EAP client will likely trust *all* root CAs (~like your web browser does by default). So, to mitigate this I can set my EAP client to only trust my CA e.g. verisign. ... but "badPerson" bought their cert from verisign too! ... so we have to move to the next level - your step (2), the CN. So how do we configure the client to trust the appropriate CN.... just that *configure it* ...an unconfigured/default config client will likely trust any CN. It is this step that is very different from the web. In the web world, the client can check the cert CN matches the DNS name that the user typed, and that this matches the reverse DNS of the IP that the cert came from. In the EAP world, there is no DNS, no IP, no way to determine the source of the cert at all. ...which is why there is nothing wrong with the mechanism, as long as you configure it properly. Some EAP clients do not let you specify a CN to match, so using a self-signed cert, and setting the client just to trust that CA mitigates the public CA vector. -James -- James J J Hooper Network Specialist, University of Bristol http://www.wireless.bristol.ac.uk --
On Mar 7, 2011, at 4:05 PM, James J J Hooper wrote:
On 07/03/2011 21:42, John Dennis wrote:
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!!
...remember though that working != secure [necessarily]. Clients defaulting to accept any radius server cert, or those that default to prompt the user, are vulnerable to rogue AP/credential stealing attacks etc. This may be acceptable in your environment, but if not, you'll still need to actively configure the client.
I've seen statements on this list in the past asserting that if you have a server cert signed by a public CA (e.g. a CA the client is preconfigured to trust) it is a security vulnerability because clients will blindly trust they are connecting to server they expect when in fact it could be a rouge server impersonating the server. The above comment seems to fall into the same category.
I have never understood this advice or it's rationale. I was hoping someone could explain it because it does not match my understanding of PKI, here's why:
When a client negotiates a SSL/TLS session it's supposed to validate the server cert. In simplicity this is a 2 step process.
1) It validates the server cert to assure it's signed by a CA it trusts (possibly via a cert chain).
2) It then validates the certificate subject to make sure the server it thought it was connecting to appears in the certificate (either as the certificate subject or one of the certificate subject alternate names).
If either 1 or 2 fails it should abort the connection.
If it were possible on an SSL/TLS connection to impersonate another server then most of PKI would be a complete failure.
So why does this group think PKI doesn't work?
Hi John,
Ok, first your (1) - matching a presented server cert to a pre-trusted CA cert on the client. This "works" and does exactly that. Consider this:
* The client will validate my cert against the CA I signed it with.
* The client will also validate a cert that "badPerson" has purchased from e.g. verisign
Why - because an unconfigured EAP client will likely trust *all* root CAs (~like your web browser does by default).
So, to mitigate this I can set my EAP client to only trust my CA e.g. verisign.
... but "badPerson" bought their cert from verisign too! ... so we have to move to the next level - your step (2), the CN.
So how do we configure the client to trust the appropriate CN.... just that *configure it* ...an unconfigured/default config client will likely trust any CN.
That's not really true, even windows requires the user confirm that they trust the CN in the certificate unless the CA has been *explicitly* trusted, and none are by default. The CA would have to fail to verify that the domain used in the CN of the CSR was actually owned by the entity requesting the certificate or the user would have to fail to manually validate the CN presented to them by the supplicant. -Arran
On 07/03/2011 22:18, Arran Cudbard-Bell wrote:
On Mar 7, 2011, at 4:05 PM, James J J Hooper wrote:
On 07/03/2011 21:42, John Dennis wrote:
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the Macs are able to authenticate without Certs or any configuration on their side!!
...remember though that working != secure [necessarily]. Clients defaulting to accept any radius server cert, or those that default to prompt the user, are vulnerable to rogue AP/credential stealing attacks etc. This may be acceptable in your environment, but if not, you'll still need to actively configure the client.
I've seen statements on this list in the past asserting that if you have a server cert signed by a public CA (e.g. a CA the client is preconfigured to trust) it is a security vulnerability because clients will blindly trust they are connecting to server they expect when in fact it could be a rouge server impersonating the server. The above comment seems to fall into the same category.
I have never understood this advice or it's rationale. I was hoping someone could explain it because it does not match my understanding of PKI, here's why:
When a client negotiates a SSL/TLS session it's supposed to validate the server cert. In simplicity this is a 2 step process.
1) It validates the server cert to assure it's signed by a CA it trusts (possibly via a cert chain).
2) It then validates the certificate subject to make sure the server it thought it was connecting to appears in the certificate (either as the certificate subject or one of the certificate subject alternate names).
If either 1 or 2 fails it should abort the connection.
If it were possible on an SSL/TLS connection to impersonate another server then most of PKI would be a complete failure.
So why does this group think PKI doesn't work?
Hi John,
Ok, first your (1) - matching a presented server cert to a pre-trusted CA cert on the client. This "works" and does exactly that. Consider this:
* The client will validate my cert against the CA I signed it with.
* The client will also validate a cert that "badPerson" has purchased from e.g. verisign
Why - because an unconfigured EAP client will likely trust *all* root CAs (~like your web browser does by default).
So, to mitigate this I can set my EAP client to only trust my CA e.g. verisign.
... but "badPerson" bought their cert from verisign too! ... so we have to move to the next level - your step (2), the CN.
So how do we configure the client to trust the appropriate CN.... just that *configure it* ...an unconfigured/default config client will likely trust any CN.
That's not really true, even windows requires the user confirm that they trust the CN in the certificate unless the CA has been *explicitly* trusted, and none are by default.
The CA would have to fail to verify that the domain used in the CN of the CSR was actually owned by the entity requesting the certificate
Of course, that is true (on windows and mac) ... but Android? some linux? Windows Mobile? ...
or the user would have to fail to manually validate the CN presented to them by the supplicant.
I forgive my cynicism, but users click 'yes connect me', for one of two reasons: 1) they don't read the popup, and 'yes' usually means 'make it work' 2) they have no clue what the CN should be, so bristol.com, bristol.wifi.com, uni-wifi.co.uk, eduroam.wireless.bris.ac.uk are all just as good. (2) isn't the end user's fault ...the admin or the setup wizard should configure the CN validation for the end user. ...or the user gets "popup panic" and call IT support. Which comes full-circle: just configure it right in the first place ;-) -James -James
John Dennis <jdennis@redhat.com> writes:
So why does this group think PKI doesn't work?
PKI works. gnupg is an example of that. SSL doesn't work. Faulty design: Single trust anchor, black or white trust only, and large commercial interests are all reasons for that. Bjørn
participants (9)
-
Alan Buxey -
Arran Cudbard-Bell -
Bjørn Mork -
Gary Gatten -
Guy -
James J J Hooper -
John Dennis -
Luke Hammond -
Phil Mayers