definitively, I have a problem with eap-tls
HI, continuing with Reveal MAP problem with unknown ca's under eap-tls using default configuration.... private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem freeradius tell me this: rlm_eap_tls: <<< TLS 1.0 Handshake [length 0bdb], Certificate --> verify error:num=24:invalid CA certificate rlm_eap_tls: >>> TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert write:fatal:unknown CA well, it isn't a problem: cp server.pem root.pem cat ca.pem >> root.pem then I change CA_file = ${cadir}/root.pem ......and.....eureka!!!! authentication succesfully ....but now there is a problem to check the CRL because root.pem then, something is wrong before making root.pem. ....well, just tell freeradius how to find certificates.... c_rehash /usr/local/etc/raddb/certs also doesn't works I think Reveal had the same problem and I have read about this on mailing list but nothing. Also I've tried to install ca.pem on /etc/ssl/certs using "ln -s". Has somebody encountered problems with this apart from Reveal MAP and me? P.D. route certification into windows isn't a problem, only tell xp_supplicant who is root authority (It was logical)
Sergio escribió:
HI, continuing with Reveal MAP problem with unknown ca's under eap-tls using default configuration....
private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem
freeradius tell me this:
rlm_eap_tls: <<< TLS 1.0 Handshake [length 0bdb], Certificate --> verify error:num=24:invalid CA certificate rlm_eap_tls: >>> TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert write:fatal:unknown CA
well, it isn't a problem:
cp server.pem root.pem cat ca.pem >> root.pem then I change CA_file = ${cadir}/root.pem
......and.....eureka!!!! authentication succesfully ....but
now there is a problem to check the CRL because root.pem then, something is wrong before making root.pem.
....well, just tell freeradius how to find certificates....
c_rehash /usr/local/etc/raddb/certs also doesn't works I think Reveal had the same problem and I have read about this on mailing list but nothing.
Also I've tried to install ca.pem on /etc/ssl/certs using "ln -s". Has somebody encountered problems with this apart from Reveal MAP and me?
P.D. route certification into windows isn't a problem, only tell xp_supplicant who is root authority (It was logical)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Also me, sergio restarting: private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem portatil:/usr/local/etc/raddb/certs# ln -s server.pem $(openssl x509 -hash -noout -in server.pem).0 portatil:/usr/local/etc/raddb/certs# ln -s ca.pem $(openssl x509 -hash -noout -in ca.pem).0 portatil:/usr/local/etc/raddb/certs# ls -l|grep lrw lrwxrwxrwx 1 root root 6 2008-07-23 02:47 16593b28.0 -> ca.pem lrwxrwxrwx 1 root root 10 2008-07-23 02:49 7d18a7eb.0 -> server.pem portatil:/usr/local/etc/raddb/certs# openssl verify -CApath . server.pem server.pem: OK portatil:/usr/local/etc/raddb/certs# openssl verify -CApath . client.crt client.crt: OK and then, the user is rejected. The other configuration files are ok, also wpa_supplicant. look at this Reveal, be brave jejeje. am I forgetting something? I have two other eap modules working ok with a diferent authority than the server's and I'm really intrigue about this. somebody joins? jeje regards :)
Sergio escribió:
Sergio escribió:
HI, continuing with Reveal MAP problem with unknown ca's under eap-tls using default configuration....
private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem
freeradius tell me this:
rlm_eap_tls: <<< TLS 1.0 Handshake [length 0bdb], Certificate --> verify error:num=24:invalid CA certificate rlm_eap_tls: >>> TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert write:fatal:unknown CA
well, it isn't a problem:
cp server.pem root.pem cat ca.pem >> root.pem then I change CA_file = ${cadir}/root.pem
......and.....eureka!!!! authentication succesfully ....but
now there is a problem to check the CRL because root.pem then, something is wrong before making root.pem.
....well, just tell freeradius how to find certificates....
c_rehash /usr/local/etc/raddb/certs also doesn't works I think Reveal had the same problem and I have read about this on mailing list but nothing.
Also I've tried to install ca.pem on /etc/ssl/certs using "ln -s". Has somebody encountered problems with this apart from Reveal MAP and me?
P.D. route certification into windows isn't a problem, only tell xp_supplicant who is root authority (It was logical)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Also me, sergio
restarting:
private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem
portatil:/usr/local/etc/raddb/certs# ln -s server.pem $(openssl x509 -hash -noout -in server.pem).0 portatil:/usr/local/etc/raddb/certs# ln -s ca.pem $(openssl x509 -hash -noout -in ca.pem).0
portatil:/usr/local/etc/raddb/certs# ls -l|grep lrw lrwxrwxrwx 1 root root 6 2008-07-23 02:47 16593b28.0 -> ca.pem lrwxrwxrwx 1 root root 10 2008-07-23 02:49 7d18a7eb.0 -> server.pem
portatil:/usr/local/etc/raddb/certs# openssl verify -CApath . server.pem server.pem: OK
portatil:/usr/local/etc/raddb/certs# openssl verify -CApath . client.crt client.crt: OK
and then, the user is rejected. The other configuration files are ok, also wpa_supplicant. look at this Reveal, be brave jejeje. am I forgetting something? I have two other eap modules working ok with a diferent authority than the server's and I'm really intrigue about this. somebody joins? jeje
regards :)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Please, any suggestion? I'm going insane. I can do a new installation and to tell what I'm doing (only proxy_request = no, put my ap into clients.conf and put user@example.com into users file)... Also I've tried to install ca.pem and server.crt into /etc/ssl/certs (then openssl verify client.pem returns OK, without -CApath) Thanks
Sorry, I'll do the things right jeje Log using default configuration except: -default_eap_type = tls into eap.conf -client 192.168.0.0/24 { secret = testing123 shortname = kely } into clients.conf, and ap configuration ok (still not in the garbage) -wpa_supplicant with cert user@example.com.pem private key pass whatever ca cert ca.pem Identity = user, because if I put Identity = "user@example.com" I got rlm_eap: Identity does not match User-Name, setting from EAP Identity. rlm_eap: Failed in handler from radius debug go! Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.0.3 port 3072, id=0, length=223 Cleaning up request 0 ID 0 with timestamp +6 User-Name = "user" NAS-IP-Address = 192.168.0.3 Called-Station-Id = "0014c145956f" Calling-Station-Id = "001cf01294dd" NAS-Identifier = "0014c145956f" NAS-Port = 27 Framed-MTU = 1400 State = 0x8bca9aca8bcb976abb82dcb4bf9a7d57 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0201005d0d0016030100520100004e0301488881454c2a2c04490a119ee1bb01bef71f545786cfb41f565c94aa2fbc5c3b00002600390038003500160013000a00330032002f0005000400150012000900140011000800060003020100 Message-Authenticator = 0xe217e8279c4d42c9d30581d3ac0869a1 +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "user", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: EAP packet type response id 1 length 93 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[unix] returns notfound ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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 eaptls_verify returned 7 rlm_eap_tls: Done initial handshake (other): before/accept initialization TLS_accept: before/accept initialization rlm_eap_tls: <<< TLS 1.0 Handshake [length 0052], 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 085e], Certificate TLS_accept: SSLv3 write certificate A rlm_eap_tls: >>> TLS 1.0 Handshake [length 020d], ServerKeyExchange TLS_accept: SSLv3 write key exchange A rlm_eap_tls: >>> TLS 1.0 Handshake [length 00a8], 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 ++[eap] returns handled Sending Access-Challenge of id 0 to 192.168.0.3 port 3072 EAP-Message = 0x010204000dc000000b71160301004a02000046030148888145e969e014c8d53d557333896438fb1df53b86d7e20c01469331a3648020f970bd1fb576a0d44b1165ead8575f867d7090de73650f60ce84182204f7f555003901160301085e0b00085a0008570003a6308203a23082028aa003020102020101300d06092a864886f70d0101040500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d3126302406035504 EAP-Message = 0x03131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3038303732343131343934305a170d3039303732343131343934305a307c310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e312330210603550403131a4578616d706c65205365727665722043657274696669636174653120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a0282010100c7fc7dd827525278ce75a5ee68879408cd1f69f6d592986a78ad710e3220 EAP-Message = 0xb24cfc219249e8d7fe66b34fd4de5960084cb2e4a30acd37b7332566b6eb936573a2d67d62518b625f042483d352fbebae8e7c3e44bcaa5ca9da6e514f2e7bd98c0093d85a1de29109cb810d9e25d7f9fc6870da8374f7149a843e9b17bed9999a237e3a54b89d1ae47c6101efe4f1e0e929423e123db4a41b98129e6aa2ba04843cdbe9a266dc6e5b19cfbd7bdeb3db3d120ed527b8d1c3715aeeb27608ae31850f62238ad36dc6b6444e59d80641a623c3d7aa0c5ec49bc7f196f76258c35a9b7ded30005f2d04d597e388664e48b8469d6baba1047b8a16f5895082e7c5bebcc90203010001a317301530130603551d25040c300a06082b06010505 EAP-Message = 0x070301300d06092a864886f70d0101040500038201010012b8ad972ae7e43f5dd55e42420bfff3bc475028193038f67e37d5f9de104ca8e2914ea5c379faae7594e724513f09ea84232f451e1efd18e5e584afdd45fae4354b3553ca62222cd3e2b3f45fa4f485de6f483c5d41eabcdc2159e47d339c8c715f9925c6543b618862a3a55078a3fde22cd650a4224ea53c262a7f275ebbae58f29425ed0915db5a2f789ed25639f55b322eb63c318b32facebed0fa1e45721e09701d243e18a68633112824d187d5e727fbbf1365861d0c9a42257532f305606983b5c740a95ba260ee740a57e40842309720424a14735ba8d3810303b4d25d9a0d82f4c4 EAP-Message = 0xf1b40b1df5d4a61c24bb3e3a Message-Authenticator = 0x00000000000000000000000000000000 State = 0x8bca9aca8ac8976abb82dcb4bf9a7d57 Finished request 1. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.0.3 port 3072, id=0, length=136 Cleaning up request 1 ID 0 with timestamp +6 User-Name = "user" NAS-IP-Address = 192.168.0.3 Called-Station-Id = "0014c145956f" Calling-Station-Id = "001cf01294dd" NAS-Identifier = "0014c145956f" NAS-Port = 27 Framed-MTU = 1400 State = 0x8bca9aca8ac8976abb82dcb4bf9a7d57 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020200060d00 Message-Authenticator = 0xf66421124f7ab71aa4c2cdf9f68f8db9 +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "user", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: EAP packet type response id 2 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[unix] returns notfound ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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: Received EAP-TLS ACK message rlm_eap_tls: ack handshake fragment handler eaptls_verify returned 1 eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 0 to 192.168.0.3 port 3072 EAP-Message = 0x010304000dc000000b7151eed34cf16269f70534e1565de80004ab308204a73082038fa003020102020900b302deb6f1c83c20300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3038303732343131343933395a170d3038303832333131343933395a308193310b EAP-Message = 0x3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f7269747930820122300d06092a864886f70d01010105000382010f003082010a0282010100e416bd9d2aa01540a7d8a85d7a09f0f45dc6424d902be0890a7baab4a800bb49981f1216ed86b54e75b86c677ce01beb805a4e9b7f36b5830dd1b6318ce20236120e1752d025b812f5971d EAP-Message = 0x30331172ba289b33d49885a4b65f4009392c761f3da60f5a46700e6ed5bc302440999240b1c82c083378aa4dd06f808bf74a349a64ff10827e1b7a98d9ffcac7ccd3279e25ad6cd638ed1e29a5300ff308f36b8d39c9f332466ddd06520f8bf33621f33f499b6ead5d42e81c3c1e66a536bb601beb3ebd802a457947cfff28c5bf30ac24ed26948724393a5a3a04a7518736167bd7fe4a1624c3f3995cd28745a30a95e84ec71dfcde5486cb0923db39aaca5d1c5b0203010001a381fb3081f8301d0603551d0e04160414893a714734387ee806de8ce1a45abed6a4bd94593081c80603551d230481c03081bd8014893a714734387ee806de8ce1a45a EAP-Message = 0xbed6a4bd9459a18199a48196308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479820900b302deb6f1c83c20300c0603551d13040530030101ff300d06092a864886f70d01010505000382010100885253ca15a18d7d6cd2a94b9903e77e336f22a9c2f238732075a1c7d13d725e8794f5a8c9e0de98cf1a03254788 EAP-Message = 0xb55e147be73c2ee0f93015ee Message-Authenticator = 0x00000000000000000000000000000000 State = 0x8bca9aca89c9976abb82dcb4bf9a7d57 Finished request 2. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.0.3 port 3072, id=0, length=136 Cleaning up request 2 ID 0 with timestamp +6 User-Name = "user" NAS-IP-Address = 192.168.0.3 Called-Station-Id = "0014c145956f" Calling-Station-Id = "001cf01294dd" NAS-Identifier = "0014c145956f" NAS-Port = 27 Framed-MTU = 1400 State = 0x8bca9aca89c9976abb82dcb4bf9a7d57 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020300060d00 Message-Authenticator = 0xb90ba7201e773b1c8e9fe8bf262a3446 +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "user", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: EAP packet type response id 3 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[unix] returns notfound ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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: Received EAP-TLS ACK message rlm_eap_tls: ack handshake fragment handler eaptls_verify returned 1 eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 0 to 192.168.0.3 port 3072 EAP-Message = 0x0104038f0d8000000b7130c8a9cfc463451f5e992a0487a44ee9eea2819542ab24ffeb0c0e7feb0db048d3d9f3eedb936ae88e4b0eec0f260b7aa34c587b7c3b77bb09494ad531013d0485f86bc28951289d679377cd76ccbe0b89e42e3d21bc9028789d504e1fef1f87b6b7e46e30370d8f6faee0c2d2f9236dfff49f3505e93284dedc71bc18f451e14b149b8f0ec220c104909cd7265b47504b4432897089a72522988d0c91c4ecd482fa6289470e2e113b477a4611688e0639d65b5ca8c9b35c56db76348cddda75360b0ff2c5c7160301020d0c0002090080faeb92a91f9b9df4b2ef96f804e5298874d2e63ebdb918d09052db9ff8ca63b9b28e EAP-Message = 0x7fea52a6db605debd220be2b3794aded8c5fec94e158bea0d7d77b625d16741efd3acd552e087bc434804d276ff1c0beb844510e65e0895c91f0e8e81d47a0ccaa06644e5190e1499946b87e4c0235ee4dad6308b4370857c029c6ee688b00010200806f51f7bf7295a6f5910bc57efaa01b6cd339ca2f909941557a361b55f1930b4cac69b8e8e41cc49ffbd9d82f9829f7b1ee33a1dd5fe9c52445a2f7e38b0e2a37f4a7dd544edb7ed3a5aedb678a44f581c16362407ecceed85251d6075e938641259458624fde58f67d86dd0a76d6c0629cf7f482f00c9859a5589179241e7fae01007a2cdcac643fafb6fe0696d646946eb604ebaa32e3bfcd93 EAP-Message = 0xb668e64ef8d88fec3919184dd7c0976122044221d2482ce50678e4871735ba85ec1dc249370c1ac3d16ac7cd60934d94c32e412885846599f24583028a9a85365fe37ee51103f61cb79831105b0f667129af9eaf5b98be1221b2a111ced7a1bcecdaa00830246687a4acf0d6cc228784c05efbc2caa4a270abe5d0b5d9475cd2e26a7c56e7fd5af8e145a45e8935d3d408653320d44624d24711758bd1d8f646c7e222a7bf4b3296315e7ea9d5f047e6f540684aa157ac5e9e710b45eb820902531182ecef3b5ef20c450d16cfe6e22b685cccc5eb1d11c05916c31da03257acfc7f19aab05369bc16030100a80d0000a0050304010240009800963081 EAP-Message = 0x93310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f726974790e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x8bca9aca88ce976abb82dcb4bf9a7d57 Finished request 3. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.0.3 port 3072, id=0, length=1525 Cleaning up request 3 ID 0 with timestamp +6 User-Name = "user" NAS-IP-Address = 192.168.0.3 Called-Station-Id = "0014c145956f" Calling-Station-Id = "001cf01294dd" NAS-Identifier = "0014c145956f" NAS-Port = 27 Framed-MTU = 1400 State = 0x8bca9aca88ce976abb82dcb4bf9a7d57 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020405690d00160301038d0b0003890003860003833082037f30820267a003020102020102300d06092a864886f70d0101040500307c310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e312330210603550403131a4578616d706c65205365727665722043657274696669636174653120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d301e170d3038303732343131353332345a170d3039303732343131353332345a3071310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c EAP-Message = 0x4578616d706c6520496e632e311930170603550403141075736572406578616d706c652e636f6d311f301d06092a864886f70d010901161075736572406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a02820101009eb86188bd2e67a49fae5a2c75c7278642c3981d7d7ba0b0cc41ef52f63e0d29036ca61f214150bc95931e771ff8366191f2de4bc2382bfada1ed68ccbbb2becc04bb195edde3ab9f86b87aabe375833c407874da4bb26f70b11977aea5b83736f7a8177604b7bc860dcfc840c425592d8eee81ffeaecc4dd968896212485949232a9db0c66e630b888aafd1ba0bc8fd5d2c56c4 EAP-Message = 0x58514999bb1afbab4fe5c2ac5dfc7cf21784540db7ed3a336b8f2f0c4e4ec1fe6b639c0b6d94fc6bc544b1719d7b42ecffd271dfc8cbd1e2ca0b147d5b07b08b9e164186c7abbf531065786630627cab0206e32ff5f77829d41dd56bb90818c2a4314385f3dd979e8ff2f4ff0203010001a317301530130603551d25040c300a06082b06010505070302300d06092a864886f70d010104050003820101003f6f7c340a11121502fcc7fdef4bb60f678b24f986fa1743f7e0c4cf5ee3e1fe08bcf8258e07c51d3747872d36fa0fcfbc136d9c7c500777fdc97f08cad2c19c7ac019f2cfdb35084613bf3b2cd3656d79b45c9d95554b8c86d6d28ef65f41 EAP-Message = 0x50907faf51dd75298c2a67bd7701d06d63243a61856ada03c573e35bdfc93edbc01d8bbd5b09c46965f29e888e131474f2db1fce8e62c0c52518841627182b52b6dd781f6c5c06a2c4fa25a28e2b131a90d37ae9e030611d8a013f70a11f15ca5ef937ae855cec35fd130f1162b4684935241f34d55c08169d141e8584712173b557fc12211b9636dc62f5dffdc07d6f322d115556a2809f9c56d3358eb4da0df016030100861000008200808a041cb1acfc4a9954e3b383e2ae5579de11ebcc32d1abe506b8d739368ef4e27ab35eb7980b2057b71849ed2944f587dcfab265c7c46a4205900337a63f49f032cc3b51b21f0518e156e57523e1ad8d20 EAP-Message = 0x7f7bbf3c13b43eca9009f11bc1965fdaa23a5e8027bb46a84ec013cd29d56ed4ab84e448813588693876ad240870ce16030101060f00010201004f57686585358767ea8e4971262ffc943760f649319bef89bce05860acb3e0936b3b3da4be59e98de106f6c9fc154d1e320c2b69f17de105fb86813953118dfd36646727e459a75fd20caa623719fa5fdc2a3bc0d4796545337e6baba1b8b031c9c3a44d55ae56c63c75eb7b90ed8027c01b11386137148b498fb5fd00796129ac1df15cf854cc5348fcd637ba30496510d299513d52dbf0a0e6cc9589f3a3f2f1f702725e52609f796b21ccfd50a559b53ff380af925ac87aa1b3844d577f287232da EAP-Message = 0xd7aebf722307110c324bd3700825cf9de1c6768664cd672a0b9dcd63e5ad2e11562e0327d9ede0166c0a672f9b5fe2e8abdd65e8803843d888f1a552af140301000101160301003038b7ab8120f120f897adee910f489b791be174a85ee6e91f1e2408daef058dd85fae99929570c3edd53c8add8128cba9 Message-Authenticator = 0x50e577726537b9d100f27111d53c10cb +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "user", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: EAP packet type response id 4 length 253 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[unix] returns notfound ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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 eaptls_verify returned 7 rlm_eap_tls: Done initial handshake rlm_eap_tls: <<< TLS 1.0 Handshake [length 038d], Certificate --> verify error:num=20:unable to get local issuer certificate rlm_eap_tls: >>> TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert write:fatal:unknown CA TLS_accept:error in SSLv3 read client certificate B rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails. eaptls_process returned 13 rlm_eap: Freeing handler ++[eap] returns reject auth: Failed to validate the user. Found Post-Auth-Type Reject +- entering group REJECT expand: %{User-Name} -> user attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Sending Access-Reject of id 0 to 192.168.0.3 port 3072 EAP-Message = 0x04040004 Message-Authenticator = 0x00000000000000000000000000000000 Finished request 4. Going to the next request Waking up in 4.9 seconds. Cleaning up request 4 ID 0 with timestamp +6 Ready to process requests. If I do "c_rehash ." into radius's certs dir It's unable to get local issuer also. I don't know what to do... Thanks
Sergio wrote:
Sorry, I'll do the things right jeje
I haven't been reading all your emails, but what I have read is very confusing. So I'm sorry if I misunderstand. The error message seems very very clear. FreeRadius cannot verify the client certificate. This means you have not given it the correct CA certificate. You keep talking about "c_rehash" - to the best of my knowledge, FreeRadius doesn't make use of a "certificate directory" with the openssl-style xxxxxxxx.0 -> real.pem symlinks. Forget about that. Can you please provide: * a copy of your eap.conf * a copy of the files from the "eap { tls {} }" section: * certificate_file * CA_file * a copy of the client cert: * user@example.com.pem
Phil Mayers escribió:
Sergio wrote:
Sorry, I'll do the things right jeje
I haven't been reading all your emails, but what I have read is very confusing. So I'm sorry if I misunderstand.
The error message seems very very clear.
FreeRadius cannot verify the client certificate.
This means you have not given it the correct CA certificate.
You keep talking about "c_rehash" - to the best of my knowledge, FreeRadius doesn't make use of a "certificate directory" with the openssl-style xxxxxxxx.0 -> real.pem symlinks. Forget about that.
Can you please provide:
* a copy of your eap.conf * a copy of the files from the "eap { tls {} }" section: * certificate_file * CA_file * a copy of the client cert: * user@example.com.pem - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ok :) I provide certificate files and eap.conf in a tar ball to not to post a mail too long. If I print user@example.com.pem in text form I see how radius is the issuer of the certificate. This is the default PKI and I don't know what I'm doing wrong. Thanks for your attention.
ok :) I provide certificate files and eap.conf in a tar ball to not to post a mail too long. If I print user@example.com.pem in text form I see how radius is the issuer of the certificate. This is the default PKI and I don't know what I'm doing wrong. Thanks for your attention.
I get the exact same error at the CLI: [pjm3@localhost tmp]$ openssl verify -CAfile ca.pem < server.pem stdin: OK [pjm3@localhost tmp]$ openssl verify -CAfile ca.pem < user\@example.com.pem stdin: /C=FR/ST=Radius/O=Example Inc./CN=user@example.com/emailAddress=user@example.com error 20 at 0 depth lookup:unable to get local issuer certificate Your certificates are invalid: * server.pem is signed by ca.pem, which is correct: Issuer: C=FR, ST=Radius, L=Somewhere, O=Example Inc./emailAddress=admin@example.com, CN=Example Certificate Authority Subject: C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate/emailAddress=admin@example.com * user.pem is signed by *server.pem* which is WRONG Issuer: C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate/emailAddress=admin@example.com Subject: C=FR, ST=Radius, O=Example Inc., CN=user@example.com/emailAddress=user@example.com You have signed the user cert with the server cert, which is incorrect. You must sign the user cert with the CA cert.
Phil Mayers escribió:
ok :) I provide certificate files and eap.conf in a tar ball to not to post a mail too long. If I print user@example.com.pem in text form I see how radius is the issuer of the certificate. This is the default PKI and I don't know what I'm doing wrong. Thanks for your attention.
I get the exact same error at the CLI:
[pjm3@localhost tmp]$ openssl verify -CAfile ca.pem < server.pem stdin: OK
[pjm3@localhost tmp]$ openssl verify -CAfile ca.pem < user\@example.com.pem stdin: /C=FR/ST=Radius/O=Example Inc./CN=user@example.com/emailAddress=user@example.com error 20 at 0 depth lookup:unable to get local issuer certificate
Your certificates are invalid:
* server.pem is signed by ca.pem, which is correct:
Issuer: C=FR, ST=Radius, L=Somewhere, O=Example Inc./emailAddress=admin@example.com, CN=Example Certificate Authority
Subject: C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate/emailAddress=admin@example.com
* user.pem is signed by *server.pem* which is WRONG
Issuer: C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate/emailAddress=admin@example.com
Subject: C=FR, ST=Radius, O=Example Inc., CN=user@example.com/emailAddress=user@example.com
You have signed the user cert with the server cert, which is incorrect. You must sign the user cert with the CA cert.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yeah!! Then you're agree with me. I've been explaining (trying) in this forum that client cert must be signed by ca cert. bootstrap command sign client cert with server.key and this not works. The solution is to replace de signing in certs/Makefile (-key server.key -cert server.pem should be -key ca.key -cert ca.pem). Then , are you agree with me when I say, with fear and respect, that default radius PKI doesn't work?. Second: if I sign client certificates with ca.key I assume that I can't manage de CRL because it sholud be signed with server.key, am I right? what do you think about this? Thanks
Yeah!! Then you're agree with me. I've been explaining (trying) in this forum that client cert must be signed by ca cert. bootstrap command sign client cert with server.key and this not works. The solution is to replace de signing in certs/Makefile (-key server.key -cert server.pem should be -key ca.key -cert ca.pem). Then , are you agree with me when I
I think so.
say, with fear and respect, that default radius PKI doesn't work?.
Hmm. Maybe; I guess most people test PEAP which just uses CA & server certs, no client certs. I'm by no means an expert, and Makefile's make my brain hurt, so I could be misreading it. Alan - it does look to my untrained eye as if the "client.crt" Makefile target in /etc/raddb/certs is signing the client key with the server key. Is this intentional, or a bug?
Second: if I sign client certificates with ca.key I assume that I can't manage de CRL because it sholud be signed with server.key, am I right?
I don't think so. Again, I think the CRL is signed with the CA key. Of course, you'll need run your own crl commands, the FreeRadius stuff doesn't come with that.
Phil Mayers wrote:
Alan - it does look to my untrained eye as if the "client.crt" Makefile target in /etc/raddb/certs is signing the client key with the server key. Is this intentional, or a bug?
It's intentional. It's a perfectly valid use of certificate chains. The idea is that you have one CA for your organization, and (perhaps) multiple RADIUS servers. Each server has it's own identity, and can issue it's own client certs for EAP-TLS. But client certs will work across multiple servers, because the servers are signed by the same CA. Alan DeKok.
Alan DeKok escribió:
Phil Mayers wrote:
Alan - it does look to my untrained eye as if the "client.crt" Makefile target in /etc/raddb/certs is signing the client key with the server key. Is this intentional, or a bug?
It's intentional. It's a perfectly valid use of certificate chains.
The idea is that you have one CA for your organization, and (perhaps) multiple RADIUS servers. Each server has it's own identity, and can issue it's own client certs for EAP-TLS. But client certs will work across multiple servers, because the servers are signed by the same CA.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
But the debug I posted shows that radius doesn't recognize the issuer of client cert using default certs. If default certs works and I don't need to install server.pem and ca.pem into ssl/certs dir, what I'm forgetting alan?
Sergio wrote:
But the debug I posted shows that radius doesn't recognize the issuer of client cert using default certs. If default certs works and I don't need to install server.pem and ca.pem into ssl/certs dir, what I'm forgetting alan?
You need to follow the documentation in eap.conf. # If CA_file (below) is not used, then the # certificate_file below MUST include not # only the server certificate, but ALSO all # of the CA certificates used to sign the # server certificate. certificate_file = ${certdir}/server.pem Have you done that? Alan DeKok.
Alan DeKok escribió:
Sergio wrote:
But the debug I posted shows that radius doesn't recognize the issuer of client cert using default certs. If default certs works and I don't need to install server.pem and ca.pem into ssl/certs dir, what I'm forgetting alan?
You need to follow the documentation in eap.conf.
# If CA_file (below) is not used, then the # certificate_file below MUST include not # only the server certificate, but ALSO all # of the CA certificates used to sign the # server certificate. certificate_file = ${certdir}/server.pem
Have you done that?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I've tried several times. First, i need to use CA_file because i'm configuring eap-tls and radiusd won't parse eap.conf. Then I've tried: -cat ca.pem >>server.pem doesn't works (i think it's right if i want to use peap or similar, based on this paragraph of eap documentation) -CA_file = ${cadir}/ca.pem CA_file = ${cadir}/server.pem because you permit a list of trusted ca (although server.pem isn't a ca cert) -cp server.pem root.pem cat ca.pem >>root.pem CA_file = ${cadir}/root.pem works, but i think then I can't manage the crl. Then: a) i'm a little stupid (I don't know any other term) b) i have no idea about english language (many probabilities) c) a) and b) and bad manners (but trying to be a nice boy)
Alan DeKok escribió:
Phil Mayers wrote:
Alan - it does look to my untrained eye as if the "client.crt" Makefile target in /etc/raddb/certs is signing the client key with the server key. Is this intentional, or a bug?
It's intentional. It's a perfectly valid use of certificate chains.
The idea is that you have one CA for your organization, and (perhaps) multiple RADIUS servers. Each server has it's own identity, and can issue it's own client certs for EAP-TLS. But client certs will work across multiple servers, because the servers are signed by the same CA.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sorry, only one more note. bootstrap command doesn't make client certs. you need to execute "make client.pem" to make it. I also assume that it is normal.
On Thu, Jul 24, 2008 at 09:14:54PM +0200, Alan DeKok wrote:
Phil Mayers wrote:
Alan - it does look to my untrained eye as if the "client.crt" Makefile target in /etc/raddb/certs is signing the client key with the server key. Is this intentional, or a bug?
It's intentional. It's a perfectly valid use of certificate chains.
The idea is that you have one CA for your organization, and (perhaps) multiple RADIUS servers. Each server has it's own identity, and can issue it's own client certs for EAP-TLS. But client certs will work across multiple servers, because the servers are signed by the same CA.
Ah, I see.
participants (3)
-
Alan DeKok -
Phil Mayers -
Sergio