FR 1.1.6 EAP - TLS rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal bad_certificate
Hi, I just upgrade FR 1.1.4 to 1.1.6 on FreeBSD 6.1. And FR has always worked wonderfully for me in the past. I saw in the changelog something about terminating the SSL session in EAP on errors. What can I do to fix this error? Regards, Remy. --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 10.0.1.250:3072, id=1, length=256 User-Name = "monique@unix-asp.com" NAS-IP-Address = 10.0.1.250 Called-Station-Id = "0012176fb399" Calling-Station-Id = "0013022105d3" NAS-Identifier = "0012176fb399" NAS-Port = 55 Framed-MTU = 1400 State = 0x99e6bf386c1693ffe99cc51011c78c22 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0201006e0d8000000064160301005f0100005b030146338b7df93bc3ecee992b73b782861f b83b032ad4e5d0e367a50e96a5f4d07e00003400390038003500160013000a00330032002f00 6600050004006500640063006200610060001500120009001400110008000600030100 Message-Authenticator = 0xd1dcd23d54281665000ddf314423cf61 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 radius_xlat: '/var/log/radacct/10.0.1.250/auth-detail-20070428' rlm_detail: /var/log/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radacct/10.0.1.250/auth-detail-20070428 modcall[authorize]: module "auth_log" returns ok for request 1 modcall[authorize]: module "chap" returns noop for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: Looking up realm "unix-asp.com" for User-Name = "monique@unix-asp.com" rlm_realm: No such realm "unix-asp.com" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: EAP packet type response id 1 length 110 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 152 modcall[authorize]: module "files" returns ok for request 1 modcall: leaving 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/tls rlm_eap: processing type tls rlm_eap_tls: 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 005f], 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 02ca], Certificate TLS_accept: SSLv3 write certificate A rlm_eap_tls: >>> TLS 1.0 Handshake [length 00a9], CertificateRequest TLS_accept: SSLv3 write certificate request A TLS_accept: SSLv3 flush data TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode eaptls_process returned 13 modcall[authenticate]: module "eap" returns handled for request 1 modcall: leaving group authenticate (returns handled) for request 1 Sending Access-Challenge of id 1 to 10.0.1.250 port 3072 EAP-Message = 0x010203d60d80000003cc160301004a02000046030146338b7ad2b5446adeec2e4c5dbeebbf 060ca75333f41f2cd07136ceb4f1e16020c03cc6c37f378e3a121feb1d2b2ff0720a72311530 9f56d0f8db9efb1334024f00350016030102ca0b0002c60002c30002c0308202bc30820225a0 0302010202020122300d06092a864886f70d0101050500308196310b3009060355040613024e 4c3110300e06035504081307557472656368743110300e060355040713075574726563687431 153013060355040a130c554e49582d4153502e434f4d3110300e060355040b1307537570706f 7274311530130603550403130c756e69782d6173702e636f6d31 EAP-Message = 0x23302106092a864886f70d0109011614737570706f727440756e69782d6173702e636f6d30 1e170d3037303432383137343331325a170d3038303432373137343331325a308196310b3009 060355040613024e4c3110300e06035504081307557472656368743110300e06035504071307 5574726563687431153013060355040a130c554e49582d4153502e434f4d3110300e06035504 0b1307537570706f7274311530130603550403130c756e69782d6173702e636f6d3123302106 092a864886f70d0109011614737570706f727440756e69782d6173702e636f6d30819f300d06 092a864886f70d010101050003818d0030818902818100c4d9ff EAP-Message = 0x25696b959b20ce440ea32876f9083badb184a2a86c2269205ca4442c6c386546face2e2ec0 5b6a0af3d11094e0fe389198023ee39fafb456de6832483e99c29231034840334c91ccafeb80 f7bd019f3493977c03b7e8ed7824395ec401a2f5eb1540db144670038cc6ca8308c982ac3038 1da8228a479740e4049ef8870203010001a317301530130603551d25040c300a06082b060105 05070301300d06092a864886f70d010105050003818100741dcc0890f8e7cb9651648a76005c 9382030b41b9ac3d6d09fe32f7e0dedaa25c34e6a970a4c92666c3dc1a96096b824871a31b43 15d065bdcad0f8bf8d77a6e00afd76bf9c924b91741c36142c49 EAP-Message = 0x1c9aa8bd1665c0bda3edc5e3b9dd9c95c3d5d304204d55c2876cf0265837fd68c9c92a181a c73e0e208975d3bffa7a37c016030100a90d0000a103010240009b0099308196310b30090603 55040613024e4c3110300e06035504081307557472656368743110300e060355040713075574 726563687431153013060355040a130c554e49582d4153502e434f4d3110300e060355040b13 07537570706f7274311530130603550403130c756e69782d6173702e636f6d3123302106092a 864886f70d0109011614737570706f727440756e69782d6173702e636f6d0e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xcb376b4b0ff5456ba9300ec08c5b69aa Finished request 1 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 10.0.1.250:3072, id=1, length=163 User-Name = "monique@unix-asp.com" NAS-IP-Address = 10.0.1.250 Called-Station-Id = "0012176fb399" Calling-Station-Id = "0013022105d3" NAS-Identifier = "0012176fb399" NAS-Port = 55 Framed-MTU = 1400 State = 0xcb376b4b0ff5456ba9300ec08c5b69aa NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020200110d80000000071503010002022a Message-Authenticator = 0x73d8ae0eec89244e63a52fa4e5fc8e7f Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 modcall[authorize]: module "preprocess" returns ok for request 2 radius_xlat: '/var/log/radacct/10.0.1.250/auth-detail-20070428' rlm_detail: /var/log/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radacct/10.0.1.250/auth-detail-20070428 modcall[authorize]: module "auth_log" returns ok for request 2 modcall[authorize]: module "chap" returns noop for request 2 modcall[authorize]: module "mschap" returns noop for request 2 rlm_realm: Looking up realm "unix-asp.com" for User-Name = "monique@unix-asp.com" rlm_realm: No such realm "unix-asp.com" modcall[authorize]: module "suffix" returns noop for request 2 rlm_eap: EAP packet type response id 2 length 17 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 2 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 2 modcall: leaving group authorize (returns updated) for request 2 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 2 rlm_eap: Request found, released from the list rlm_eap: EAP/tls rlm_eap: processing type tls rlm_eap_tls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal bad_certificate TLS Alert read:fatal:bad certificate TLS_accept:failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails. eaptls_process returned 13 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 2 modcall: leaving group authenticate (returns reject) for request 2 auth: Failed to validate the user. Delaying request 2 for 1 seconds Finished request 2 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Sending Access-Reject of id 1 to 10.0.1.250 port 3072 EAP-Message = 0x04020004 Message-Authenticator = 0x00000000000000000000000000000000 Cleaning up request 2 ID 1 with timestamp 46338b7a Nothing to do. Sleeping until we see a request.
Hi Remy and everyone, In message <200704281849.l3SInfTu086460@mxdrop40.xs4all.nl>, Remy de Ruysscher <remy@unix-asp.com> writes
I just upgrade FR 1.1.4 to 1.1.6 on FreeBSD 6.1. And FR has always worked wonderfully for me in the past.
I'm the maintainer of the FreeBSD port. My 6.2-RELEASE-p2 i386 system uses EAP-TLS - and it works fine, so it is probably something with your setup. I'm assuming you're using the port - though you didn't say so specifically. I use the OpenSSL port - and suggest you do too, as the version of OpenSSL in the base system is rather old. If you've got the OpenSSL port installed, the FreeRADIUS port will notice and make use of it automatically. The package, meanwhile, uses the base OpenSSL. If you install the OpenSSL port, you'll need to rebuild the FreeRADIUS port for FreeRADIUS to use it. If you have portupgrade installed, and want to switch to using the OpenSSL port, try: portupgrade -N security/openssl portupgrade -f net/freeradius /usr/local/etc/rc.d/radius start I suggest you also rebuild any other ports that use OpenSSL if you've installed the OpenSSL port for the first time. Use portupgrade -f or similar. Of course, it could be that your server certificate is actually bad. Do the results of: openssl verify -CAfile demoCA/cacert.pem -verbose cert-srv.pem and openssl x509 -in cert-srv.pem -noout -text look OK? You may need to adjust the filenames according to your environment - I'm presuming that you're in your raddb certificates folder. If you have the OpenSSL port installed, I suggest you explicitly use /usr/local/bin/openssl instead of openssl in the commands above. The handling of raddb upgrading has changed significantly from version 1.1.4 of the port to 1.1.6. It's just possible that your certificates have got stomped on if they are in /usr/local/etc/raddb/certs (adjusted accordingly if you have a non-standard ${PREFIX}), but I can't think why, as the script is fairly careful in checking before overwriting anything in raddb. That said, the new behaviour on uninstallation is to check any files in raddb against the distribution, and delete unmodified files. On installation, it copies the distribution files to raddb unless there's already a file of the same name. It's possible that your upgrade to 1.1.6 has created mixed versions (new uncustomised files and your customisations based on a rather older version of FreeRADIUS) - and that's introduced a problem, though I feel this is unlikely. My favourite is either there's something wrong with your server certificate, or it's a problem with the base system OpenSSL that you can cure by moving to the OpenSSL port. I'd be interested to know how you get on, particularly if the problem turns out to be something different. If you want a tarball of the 1.1.4 port, email me - I can pull out the last version of 1.1.4 from my local Subversion repository before I upgraded the port to 1.1.5. There were a lot of fixes in the 1.1.4 timeframe - there was a 1.1.4 port on 15 January 2007, 1.1.4_1 on 18 January 2007, and a rewrap of 1.1.4_1 on 23 January 2007. The 15 January -> 18 January transition merely disabled rlm_sql_firebird (otherwise the port failed to build with experimental modules disabled). The 18 January -> 23 January 2007 update contained a bunch of fixes, including the first version of the revised raddb handling (the very first time that the port touched files other than those suffixed .sample in raddb). http://www.freshports.org/net/freeradius/ will walk you through the changes in more detail, though my local Subversion repository is more finely grained. There were two further changes before I upgraded to 1.1.5 - support for the freeradius-mysql slave port, and a change to the current version of raddb handling. However, I hope we can get the 1.1.6 port working on your machine, and I don't have to unravel the many changes made from the last version of 1.1.4_1 through 1.1.5 to 1.1.6. Best wishes, David -- David Wood david@wood2.org.uk
participants (2)
-
David Wood -
Remy de Ruysscher