Re: [ttls] <<< Unknown TLS version [length 0002]
What about this part of the error: "TLS Alert read:fatal:access denied TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied SSL: SSL_read failed inside of TLS (-1), TLS session fails. TLS receive handshake failed during operation" ? This is not cosmetic for sure :) Dnia 20 maja 2015 16:28 Arran Cudbard-Bell <a.cudbardb@freeradius.org> napisał(a):
On 20 May 2015, at 10:02, Alan DeKok <aland@deployingradius.com> wrote:
On May 20, 2015, at 9:50 AM, gabriel_skupien <gabriel_skupien@o2.pl>> wrote:
Problem with TTLS setup. EAP clients negotiate TLSv1.2 but FR reports> "Unknown TLS version". Any idea? It's a TLS issue. Either OpenSSL doesn't understand TLSv1.2, or> FreeRADIUS was built using the wrong version of OpenSSL.I'm fairly sure this was a cosmetic issue that was fixed recently when we> were looking at tls 1.2 and wpa_supplicant.
OP will likely find it works as expected in v3.0.8, can't remember if it> was backported to v2.2.x.
If it wasn't, I vote nofix because v2.2.x is EOL and OP should upgrade to> v3.0.8.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org>
FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 20, 2015, at 10:45 AM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
What about this part of the error: "TLS Alert read:fatal:access denied TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied SSL: SSL_read failed inside of TLS (-1), TLS session fails. TLS receive handshake failed during operation" ?
This is not cosmetic for sure :)
No. But you're not saying what client you're using. That would help. FreeRADIUS works with ALL known EAP clients. It *is* the standard in the RADIUS space. OpenSSL is similarly the standard in the TLS space. If something doesn't work with FreeRADIUS and OpenSSL, my guess is: a) the client is broken b) FreeRADIUS and/or OpenSSL weren't built with the required features e.g. an old OpenSSL library won't do TLS 1.2, because the code was written before the standard was finalized. Alan DeKok.
No.> > But you're not saying what client you're using. That would help.> >
StrongsWAN xauth-eap with eap-ttls and eap-radius plugins. https://wiki.strongswan.org/projects/strongswan/wiki/XAuthEAP FreeRADIUS works with ALL known EAP clients. It *is* the standard in the> RADIUS space. OpenSSL is similarly the standard in the TLS space.> > If something doesn't work with FreeRADIUS and OpenSSL, my guess is:> > a) the client is broken> > I am not sure about that but Strongswan eap-ttls seems to be rather mature. b) FreeRADIUS and/or OpenSSL weren't built with the required features> e.g. an old OpenSSL library won't do TLS 1.2, because the code was> written before the standard was finalized.> > Not possible. Gabriel
On May 20, 2015, at 12:09 PM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
StrongsWAN xauth-eap with eap-ttls and eap-radius plugins. https://wiki.strongswan.org/projects/strongswan/wiki/XAuthEAP
That should work.
I am not sure about that but Strongswan eap-ttls seems to be rather mature.
I agree.
b) FreeRADIUS and/or OpenSSL weren't built with the required features> e.g. an old OpenSSL library won't do TLS 1.2, because the code was> written before the standard was finalized.> >
Not possible.
This isn't magic. There's a version mismatch. If it's not on the FreeRADIUS side, it's on the Strongswan side. Alan DeKok.
This isn't magic. There's a version mismatch. If it's not on the> FreeRADIUS side, it's on the Strongswan side.> > It should not be. Both Strongswan and FR were compiled on the same machine with OpenSSL v1.0.1f. See my last post regarding TLSv1.0.
gabriel_skupien wrote:
What about this part of the error: "TLS Alert read:fatal:access denied TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied
Not sure but I'd check first whether ownership/permissions of cert and key files are correct. Ciao, Michael.
Not sure but I'd check first whether ownership/permissions of cert and key files are correct.
I checked that, it is fine. Maybe the problem sits in the certificate itself? Tomorrow morning I will replace the default one and then check. Gabriel
Neither file permissions nor certificates will create an "unknown TLS version" error message. On May 20, 2015, at 12:13 PM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
Not sure but I'd check first whether ownership/permissions of cert and key files are correct.
I checked that, it is fine.
Maybe the problem sits in the certificate itself? Tomorrow morning I will replace the default one and then check.
Gabriel
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Neither file permissions nor certificates will create an "unknown TLS> version" error message.> >
Correct. I am talking about "TLS Alert read:fatal:access denied" issue that appears even when I forced TLS to v1.0 at the client side. Gabriel
On May 20, 2015, at 12:30 PM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
Neither file permissions nor certificates will create an "unknown TLS> version" error message.> >
Correct. I am talking about "TLS Alert read:fatal:access denied" issue that appears even when I forced TLS to v1.0 at the client side.
That's likely a related issue. Fix the MAIN problem first. Then, fix lesser problems. Alan DeKok.
That's likely a related issue.> > Fix the MAIN problem first. Then, fix lesser problems.> > I do not think that's related. There is not "Unknown TLS version" error messages when I use TLSv1.0. Gabriel
Alan DeKok wrote:
Neither file permissions nor certificates will create an "unknown TLS version" error message.
You stripped the actual error message "tlsv1 alert access denied" I responded to, which seemed to me to come from OpenSSL (at least the message is defined in OpenSSL's source ssl/ssl_err.c). Anyway the original poster checked permissions. Ciao, Michael.
On May 20, 2015, at 12:13 PM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
Not sure but I'd check first whether ownership/permissions of cert and key files are correct.
I checked that, it is fine.
Maybe the problem sits in the certificate itself? Tomorrow morning I will replace the default one and then check.
Gabriel
Problem on the client side. Ticket to be closed. Gabriel
On May 21, 2015, at 7:26 AM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
Problem on the client side. Ticket to be closed.
Perhaps you could explain what the problem is, so that other people don't have to go through the same suffering to get a solution. Alan DeKok.
Answer from Strongswan developers: "to keep it simple: EAP-TTLS currently won't work as an xauth-eap backend."
participants (3)
-
Alan DeKok -
gabriel_skupien -
Michael Ströder