[RADIATOR] EAP TLS issues "routines:SSL3_READ_BYTES:tlsv1 alert access denied"
Jeffrey Smith
doc at neonova.net
Thu Feb 20 11:39:29 CST 2014
Garry,
Even combining them all in order into a single .pem on the RADIUS server
I get the following RADIUS debugs when connecting the windows laptop:
Thu Feb 20 08:36:31 2014: DEBUG: Handling request with Handler
'NAS-Port-Type = Wireless-IEEE-802-11', Identifier ''
Thu Feb 20 08:36:31 2014: DEBUG: internal Deleting session for
testuser at neonova.net, 137.118.48.15, 0
Thu Feb 20 08:36:31 2014: DEBUG: Handling with Radius::AuthMassGeneric:
Thu Feb 20 08:36:31 2014: DEBUG: Handling with EAP: code 2, 9, 47, 25
Thu Feb 20 08:36:31 2014: DEBUG: Response type 25
Thu Feb 20 08:36:31 2014: ERR: EAP PEAP TLS read failed: 5760: 1 -
error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied
Thu Feb 20 08:36:31 2014: DEBUG: EAP result: 1, EAP PEAP TLS read failed
Thu Feb 20 08:36:31 2014: DEBUG: AuthBy MassGeneric result: REJECT, EAP
PEAP TLS read failed
Thu Feb 20 08:36:31 2014: INFO: Access rejected for testuser at neonova.net:
EAP PEAP TLS read failed
Thanks,
Jeff Smith
Network Engineer
Neonova Network Services
(919) 460-3330
doc at neonova.net
On Thu, Feb 20, 2014 at 12:12 PM, Garry Shtern <Garry.Shtern at twosigma.com>wrote:
Try adding the entire chain to the server cert that Radiator presents.
Make sure to list certificates in proper order - server, intermediate, root.
Sent with Good (www.good.com)
-----Original Message-----
*From: *Jeffrey Smith [doc at neonova.net]
*Sent: *Thursday, February 20, 2014 05:03 PM Coordinated Universal Time
*To: *radiator at open.com.au
*Subject: *Re: [RADIATOR] EAP TLS issues "routines:SSL3_READ_BYTES:tlsv1
alert access denied"
Thanks for all the help so far, I did get ChromeOS connected. I tried
loading the full chain of CAs for the RapidSSl cert, from Geotrust on down,
into the CA file on the RADIUS server and that didn't change the behavior
for windows. Then, I loaded the RapidSSL cert onto the windows 7 laptop
that I'm testing with and still couldn't connect. Finally I told the
windows box not to verify the cert by setting up a manual connection to the
SSID and then could connect successfully. No idea what's up with that cert
but windows definitely doesn't like it for PEAP.
Thanks,
Jeff Smith
Network Engineer
Neonova Network Services
(919) 460-3330 <%28919%29%20460-3330>
doc at neonova.net
On Thu, Feb 20, 2014 at 8:31 AM, Sami Keski-Kasari <samikk at open.com.au>wrote:
Hello Jeff,
Most probably you have incorrect password in your ChromeOS configuration.
It seems that if you can't successfully authenticate, save identity and
password selection doesn't save your password.
It will show stars in the password field but it still tries to
authenticate with empty password.
Try to connect so that you write the password every time you try to
authenticate.
For windows you need to install and define your CA as trusted otherwise
windows PEAP/TTLS client doesn't work.
Best Regards,
Sami
On 02/20/2014 12:26 AM, Jeffrey Smith wrote:
> Sami,
> Thanks for the AutoMPPEKeys, that did in fact fix OSX and Android. I'm
> hoping that the cert doesn't need to be installed on the windows clients
as
> this is for a widespread WISP solution for end users.
>
> I did find one other oddity that may or may not also be certificate
> related. For ChromeOS it gets back an EAP MSCHAP-V2 Authentication
failure
> for the user:
>
> Wed Feb 19 13:12:28 2014: DEBUG: Handling request with Handler
> 'TunnelledByPEAP=1', Identifier ''
>
> Wed Feb 19 13:12:28 2014: DEBUG: internal Deleting session for
> testuser at neonova.net, 137.118.48.15, 0
>
> Wed Feb 19 13:12:28 2014: DEBUG: Handling with Radius::AuthMassGeneric:
>
> Wed Feb 19 13:12:28 2014: DEBUG: Handling with EAP: code 2, 20, 70, 26
>
> Wed Feb 19 13:12:28 2014: DEBUG: Response type 26
>
> Wed Feb 19 13:12:28 2014: DEBUG: Reading users file
> /usr/local/raddb/users/ppp/neonova.net
>
> Wed Feb 19 13:12:28 2014: DEBUG: Radius::AuthMassGeneric looks for match
> with testuser at neonova.net [testuser at neonova.net]
>
> Wed Feb 19 13:12:28 2014: DEBUG: Radius::AuthMassGeneric ACCEPT: :
> testuser at neonova.net [testuser at neonova.net]
>
> Wed Feb 19 13:12:28 2014: DEBUG: EAP Failure, elapsed time 0.115332
>
> Wed Feb 19 13:12:28 2014: DEBUG: EAP result: 1, EAP MSCHAP-V2
> Authentication failure
>
> Wed Feb 19 13:12:28 2014: DEBUG: AuthBy MassGeneric result: REJECT, EAP
> MSCHAP-V2 Authentication failure
>
> Wed Feb 19 13:12:28 2014: INFO: Access rejected for doc at neonova.net: EAP
> MSCHAP-V2 Authentication failure
>
> But I'm not seeing what is causing the Auth Failure. I'm at Trace level
> 6. Increasing that number doesn't appear to garner anymore data.
>
> Thanks,
> Jeff Smith
> Network Engineer
> Neonova Network Services
> (919) 460-3330
> doc at neonova.net
>
>
> On Wed, Feb 19, 2014 at 4:14 PM, Sami Keski-Kasari <samikk at open.com.au
>wrote:
>
> Hello Jeff,
>
> I think that Android and MACOSX problems will be solved if you add
> configuration parameter AutoMPPEKeys to outer handler.
>
> It is needed so that encryption keys to WLAN connection can be calculated.
>
> In windows case:
> Because client is sending that alert message it is hard to say exact
> reason without seeing your client configuration.
>
> Do you have your CA certificate installed in your windows machine?
> You probably need to go to the wireless settings and check what CA
> certificates are accepted for your connection.
>
> Best Regards,
> Sami
>
>
> On 02/19/2014 11:02 PM, Jeffrey Smith wrote:
>> Heikki,
>> Thanks for the links. I did come across that in my Googling. My
>> certificate reports:
>>
>> X509v3 Extended Key Usage:
>> TLS Web Server Authentication, TLS Web Client
> Authentication
>>
>> It doesn't mention the OID specifically just the text as given. The cert
>> is from RapidSSL as an aside. Other clients treat this differently as
>> well. An android device will successfully auth according to the debug
> logs
>> but never connects to the AP as it seems to timeout. And a Mac OSX device
>> just authenticates successfully over and over and over again, per the
> debug
>> logs, without connecting. Its really bothersome that all the devices
>> aren't behaving the same way, since I have the feeling if I can find a
way
>> to fix it for one the others will continue to fail.
>>
>> Given that, I'm at a loss on how to continue to debug this issue. Do you
>> have any other suggestions or can I provide any more logs?
>>
>> Alan,
>> To make sure I'm on the same page with you, I'm guessing by
"supplicant"
>> you mean the wireless client (in this case a Windows 7 laptop)? There's
no
>> configuration that pops up immediately on that one. I tell it to connect
>> to the network and it pops up a username / password dialog no other
> options
>> to set.
>>
>> I'm under the impression that no certs need to be installed on clients
for
>> this to function correctly, is that the case?
>>
>> Thanks,
>> Jeff Smith
>> Network Engineer
>> Neonova Network Services
>> (919) 460-3330
>> doc at neonova.net
>>
>>
>> On Wed, Feb 19, 2014 at 3:32 PM, Heikki Vatiainen <hvn at open.com.au>
wrote:
>>
>> On 02/19/2014 10:08 PM, Jeffrey Smith wrote:
>>
>>> Wed Feb 19 10:59:58 2014: ERR: EAP PEAP TLS read failed: 13601: 1 -
>>> error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied
>>
>> Here's one more possibility from the list archives:
>> http://www.open.com.au/pipermail/radiator/2004-August/009982.html
>>
>> I agree with Alan that the AP client probably does not care but the
>> other client does.
>>
>> In addition to what has already been suggested, I'd check the Radiator
>> certificate to see the Extended Key Usage (EKU) is there.
>>
>> http://support.microsoft.com/kb/814394
>>
>> Thanks,
>> Heikki
>>
>>
>> --
>> Heikki Vatiainen <hvn at open.com.au>
>>
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
>> NetWare etc.
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>>
>>
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>
>
> --
> Sami Keski-Kasari <samikk at open.com.au>
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
> NetWare etc.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
--
Sami Keski-Kasari <samikk at open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
_______________________________________________
radiator mailing list
radiator at open.com.au
http://www.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20140220/1c8bf267/attachment-0001.html
More information about the radiator
mailing list