Re: EAP/TLS authentication in 2050
why? really, why? wat purpose does testing these dates have - you really think your current infrastructure, and techologies such as 802.1X are going to be around in the same format in even 20 years time? No, of course not:) This is my curiosity led me to test such date. anywayI'm guessing these are 32 bit server and client OS ? you may find, in that case, that your tests will work until you set the date beyond 2037 - 32bit OS have problems with dates after 2038 so, try this with KNOWN parameters - eg 2020 , within the 2038 timeframe and things should work. The server is running SLES 11 SP1 (x86_64), a workstation running Windows XP SP3 (32bit). Authentication is successful until February 1, 2050, ie for example if you logged in December 31, 2049, then the authentication is successful. A little later, try the client computer under the control of 64bit. the results announced later. I tried on a 64 bit computer. The same result. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS authentication in 2050
Victor Guk wrote: I tried on a 64 bit computer. The same result. Ask the OpenSSL people why their library can't handle dates after 2050. FreeRADIUS can't handle dates after 2038, due to 32-bit limitations of the timestamp in RADIUS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP/TLS authentication in 2050
Hello
I have SLES 11 SP1(64bit), freeradius 2.1.12 and openssl 0.9.8r.
I set up authentication with EAP/TLS.
Server and client certificates are valid until 3011 year. Here they are:
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Dec 5 07:05:02 2011 GMT
Not After : Apr 7 07:05:02 3011 GMT
Subject:
countryName = AU
stateOrProvinceName = Some-State
organizationName = Internet Widgits Pty Ltd
commonName = Root
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication
Certificate is to be certified until Apr 7 07:05:02 3011 GMT (365000 days)
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Dec 5 07:06:57 2011 GMT
Not After : Apr 7 07:06:57 3011 GMT
Subject:
countryName = AU
stateOrProvinceName = Some-State
organizationName = Internet Widgits Pty Ltd
commonName = testuser
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Client Authentication
Certificate is to be certified until Apr 7 07:06:57 3011 GMT (365000 days)
Now client like authentication is successful. About this show freeradius:
Login OK: [host/testuser] (from client private-network port 33566721 cli
0022-15ef-ab87)
# Executing section post-auth from file /etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 67 to 10.2.2.240 port 5002
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 3
MS-MPPE-Recv-Key =
0xca7449798f0f957fe8e03542d1b9a5ef6291756644f4e392a60f078a3c858cba
MS-MPPE-Send-Key =
0xcfffb577e162ba2111b253f1f969e46e39521626f4669704e367502640f368a7
EAP-Message = 0x03050004
Message-Authenticator = 0x
User-Name = host/testuser
Finished request 3.
After that, I wanted to check as to be the case in 2050, as we recall
certificates are valid until 3011. Set the time on the server freeradius
August 1, 2050 (01/08/2050) and the same thing on a client running on
Windows XP SP3. Authentication fails (slightly below records cite the
radius).
I have a question for all who can help, this is the mistake of
freeradius, which can not correctly identify the validity of the
certificate. Or somewhere I made a mistake when setting up. Maybe this
one is already experienced. I'll be glad for your help.
test#radiusd -X
..
rad_recv: Access-Request packet from host 10.2.2.240 port 5002, id=68,
length=221
User-Name = host/testuser
EAP-Message = 0x0202001201686f73742f7465737475736572
Message-Authenticator = 0xe394bda2df7b6ff808bd0079cb5620cd
NAS-IP-Address = 10.2.2.240
NAS-Identifier = 001ac1d4d442
NAS-Port = 33566721
NAS-Port-Id = unit=2;subslot=0;port=3;vlanid=1
NAS-Port-Type = Ethernet
Service-Type = Framed-User
Framed-Protocol = PPP
Calling-Station-Id = 0022-15ef-ab87
H3C-Connect_Id = 18
H3C-Product-ID = 5500-EI
H3C-Ip-Host-Addr = 0.0.0.0 00:22:15:ef:ab:87
H3C-NAS-Startup-Timestamp = 954640520
# Executing section authorize from file /etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = host/testuser, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] EAP packet type response id 2 length 18
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry DEFAULT at line 152
[files] users: Matched entry host/testuser at line 234
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No known good password found for the user.
Authentication may fail because of this.
++[pap] returns noop
Found Auth-Type = EAP
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type tls
[tls] Requiring client certificate
[tls] Initiate
[tls] Start returned 1
++[eap] returns handled
Sending Access-Challenge of id 68 to 10.2.2.240 port 5002
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 3
EAP-Message = 0x010300060d20
Message-Authenticator = 0x
State = 0x905a520890595f1e7244e69c58c3b630
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 10.2.2.240 port 5002, id=69,
length=301
User-Name = host/testuser
EAP-Message =
0x020300500d8000461603010041013d030198387b2b15bc66925793a2b08aec38827730edb90a98238b1f8967ad5b0e5a301600040005000a000900640062000300060013001200630100
Message-Authenticator = 0x57f352efbff4566bed7422e481a95c1e
NAS-IP-Address = 10.2.2.240
NAS-Identifier = 001ac1d4d442
NAS-Port = 33566721
NAS-Port-Id = unit=2;subslot=0;port=3;vlanid=1
NAS-Port-Type = Ethernet
Service-Type = Framed-User
Framed-Protocol = PPP
Calling-Station-Id = 0022-15ef-ab87
State = 0x905a520890595f1e7244e69c58c3b630
H3C-Connect_Id = 18
H3C-Product-ID = 5500-EI
H3C-Ip-Host-Addr = 0.0.0.0 00:22:15:ef:ab:87
Re: EAP/TLS authentication in 2050
On 12/05/2011 08:25 AM, Victor Guk wrote: [tls] TLS 1.0 Handshake [length 0249], Certificate -- verify error:num=9:certificate is not yet valid [tls] TLS 1.0 Alert [length 0002], fatal bad_certificate TLS Alert write:fatal:bad certificate This error comes from within OpenSSL. FreeRADIUS just does what OpenSSL tells it. Can you verify the cert with the openssl verify ... test command? e.g. try this: openssl verify -CAfile ca.pem -purpose sslserver server.pem If this fails as well, then it's either a problem in OpenSSL or your system libraries with dates 2050. If it succeeds (which I doubt) then FreeRADIUS should work too. I sort of admire your effort to future-proof your certs though! ;o) Cheers, Phil - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS authentication in 2050
hi, why? really, why? wat purpose does testing these dates have - you really think your current infrastructure, and techologies such as 802.1X are going to be around in the same format in even 20 years time? anywayI'm guessing these are 32 bit server and client OS ? you may find, in that case, that your tests will work until you set the date beyond 2037 - 32bit OS have problems with dates after 2038 so, try this with KNOWN parameters - eg 2020 , within the 2038 timeframe and things should work. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS authentication in 2050
Hi, why? really, why? wat purpose does testing these dates have - you really think your current infrastructure, and techologies such as 802.1X are going to be around in the same format in even 20 years time? To be honest, I'm thinking of a similar thing. Given how painful a CA rollover can be, I'm planning to rollover to a CA with validity somewhere beyond Stefan's retirement date, which is unfortunately later than 2037. Given that the extra effort to extend the lifetime of a CA is *zero* (just enter a different date in openssl.cnf) and the pain to eventually stumble over an expiring CA is non-zero - I prefer to do the zero work. Of course things might change, my CA keys might get too short, and I might be forced to roll over anyway - there is at least a *chance* that I can prevent a need to rollover, and so I'll do it. 3011 is stretching it though, admitted. Stefan anywayI'm guessing these are 32 bit server and client OS ? you may find, in that case, that your tests will work until you set the date beyond 2037 - 32bit OS have problems with dates after 2038 so, try this with KNOWN parameters - eg 2020 , within the 2038 timeframe and things should work. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS authentication in 2050
This error comes from within OpenSSL. FreeRADIUS just does what OpenSSL tells it. Can you verify the cert with the openssl verify ... test command? e.g. try this: openssl verify -CAfile ca.pem -purpose sslserver server.pem freeradius:/usr/local/CA # openssl verify -CAfile cacert.pem -purpose sslserver cert-srv.pem cert-srv.pem: OK If this fails as well, then it's either a problem in OpenSSL or your system libraries with dates2050. If it succeeds (which I doubt) then FreeRADIUS should work too. I sort of admire your effort to future-proof your certs though! ;o) why? really, why? wat purpose does testing these dates have - you really think your current infrastructure, and techologies such as 802.1X are going to be around in the same format in even 20 years time? No, of course not :) This is my curiosity led me to test such date. anywayI'm guessing these are 32 bit server and client OS ? you may find, in that case, that your tests will work until you set the date beyond 2037 - 32bit OS have problems with dates after 2038 so, try this with KNOWN parameters - eg 2020 , within the 2038 timeframe and things should work. The server is running SLES 11 SP1 (x86_64), a workstation running Windows XP SP3 (32bit). Authentication is successful until February 1, 2050, ie for example if you logged in December 31, 2049, then the authentication is successful. A little later, try the client computer under the control of 64bit. the results announced later. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
