[CONFIG] Socket 4 (frame handler) had an event! Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. [CONFIG] Identity : User [CONFIG] Socket 4 (frame handler) had an event! [CONFIG] Trying to load root certificate /etc/raddb/certs/cert-clt.pem or certificate directory (null) [CONFIG] Loaded root certificate /etc/raddb/certs/cert-clt.pem and directory (null) [CONFIG] Socket 4 (frame handler) had an event! OpenSSL Error -- error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed This is xsupplicant's output. ukey { type = wireless allow_types = eap_peap identity = User eap-peap { random_file = /dev/urandom root_cert = /etc/raddb/certs/cert-clt.pem chunk_size = 1398 allow_types = eap_mschapv2 eap-mschapv2 { username = User password = password } } } I changed the Username and password.
Evan Vittitow wrote:
[CONFIG] Socket 4 (frame handler) had an event! Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. [CONFIG] Identity : User [CONFIG] Socket 4 (frame handler) had an event! [CONFIG] Trying to load root certificate /etc/raddb/certs/cert-clt.pem or certificate directory (null) [CONFIG] Loaded root certificate /etc/raddb/certs/cert-clt.pem and directory (null) [CONFIG] Socket 4 (frame handler) had an event! OpenSSL Error -- error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
That seems pretty clear. The client does not have a CA that allows it to trust the server.
Phil Mayers (p.mayers@imperial.ac.uk) wrote:
Evan Vittitow wrote:
[CONFIG] Socket 4 (frame handler) had an event! Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. [CONFIG] Identity : User [CONFIG] Socket 4 (frame handler) had an event! [CONFIG] Trying to load root certificate /etc/raddb/certs/cert-clt.pem or certificate directory (null) [CONFIG] Loaded root certificate /etc/raddb/certs/cert-clt.pem and directory (null) [CONFIG] Socket 4 (frame handler) had an event! OpenSSL Error -- error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
That seems pretty clear. The client does not have a CA that allows it to trust the server. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How do I redo my CA So this will work?
I got a "Lull" in my school work long enough such that I can work on Free Radius, homework combined with minor Illness did that. Allright, just so everyone is on the same page. I want to implement Host based 802.1X with PEAP or EAP-TLS. Currently, all my Samba Hosts have a Object in the LDAP database that looks like uid=kurama$,ou=Hosts,dc=pukey where Kurama is the host name. There isn't a pasword because this isn't user based. Its Host. I want the Linux Hosts (All running Mandriva 2007) to be able to use Xsupplicant to authenticate to the Wireless network with their valid TLS Cert. But whenever I try, I get [CONFIG] Working from config file /etc/xsupplicant.conf. Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. [CONFIG] Identity : kurama [CONFIG] Socket 4 (frame handler) had an event! [CONFIG] Trying to load root certificate /etc/raddb/certs/cert-clt.pem or certificate directory (null) [CONFIG] Loaded root certificate /etc/raddb/certs/cert-clt.pem and directory (null) [CONFIG] Socket 4 (frame handler) had an event! OpenSSL Error -- error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Library : SSL routines Function : SSL3_GET_SERVER_CERTIFICATE Reason : certificate verify failed
Evan Vittitow wrote:
I got a "Lull" in my school work long enough such that I can work on Free Radius, homework combined with minor Illness did that.
Allright, just so everyone is on the same page. I want to implement Host based 802.1X with PEAP or EAP-TLS. Currently, all my Samba Hosts have a Object in the LDAP database that looks like uid=kurama$,ou=Hosts,dc=pukey where Kurama is the host name.
There isn't a pasword because this isn't user based. Its Host. I want
This shows lack of understanding. If these samba hosts are members of a domain then they *do* have passwords, and a sufficiently recent combination of software will allow them to do PEAP. But if you want to use EAP-TLS that ought to work too.
the Linux Hosts (All running Mandriva 2007) to be able to use Xsupplicant to authenticate to the Wireless network with their valid TLS Cert.
But whenever I try, I get
[CONFIG] Working from config file /etc/xsupplicant.conf. Network ID from EAP hint : Pukey If this is a wired network, the above ID can be used in the configuration file to identify this network. [CONFIG] Working from config file /etc/xsupplicant.conf. [CONFIG] Identity : kurama [CONFIG] Socket 4 (frame handler) had an event! [CONFIG] Trying to load root certificate /etc/raddb/certs/cert-clt.pem or certificate directory (null) [CONFIG] Loaded root certificate /etc/raddb/certs/cert-clt.pem and directory (null) [CONFIG] Socket 4 (frame handler) had an event! OpenSSL Error -- error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Library : SSL routines Function : SSL3_GET_SERVER_CERTIFICATE Reason : certificate verify failed
To repeat my previous email - xsupplicant does not have a CA cert that allows it to trust the server. The line: Loaded root certificate /etc/raddb/certs/cert-clt.pem ...looks wrong. It looks as if you've told xsupp that the CA cert is the client cert, which it isn't. They're different things. In FreeRadius, the "eap.conf" file will have: eap { tls { certificate_file = /path/to/file.pem } } ...and if you run (against that file): openssl x509 -noout -text -in /path/to/file.pem | egrep '(Subject|Issuer):' ...you'll get something like: Issuer: C=US, O=MyOrg, OU=MyCA, CN=My Certificate Authority Subject: C=US, O=MyOrg, OU=MyCA, CN=wireless.myorg.com The certificate you supply to the CLIENT as the *CA* must be the ISSUER cert - that is, the one with: Subject: C=US, O=MyOrg, OU=MyCA, CN=My Certificate Authority I would glance at the xsupp documentation to give more advice but the crapforge^Wsourceforge docs links appears to lead in a loop. This is one reason amongst many others you should seriously consider using wpa_supplicant on the clients.
To repeat my previous email - xsupplicant does not have a CA cert that allows it to trust the server.
The line:
Loaded root certificate /etc/raddb/certs/cert-clt.pem
...looks wrong. It looks as if you've told xsupp that the CA cert is the client cert, which it isn't. They're different things.
In FreeRadius, the "eap.conf" file will have:
eap { tls { certificate_file = /path/to/file.pem } }
...and if you run (against that file):
openssl x509 -noout -text -in /path/to/file.pem | egrep '(Subject|Issuer):'
...you'll get something like:
Issuer: C=US, O=MyOrg, OU=MyCA, CN=My Certificate Authority Subject: C=US, O=MyOrg, OU=MyCA, CN=wireless.myorg.com
The certificate you supply to the CLIENT as the *CA* must be the ISSUER cert - that is, the one with:
Subject: C=US, O=MyOrg, OU=MyCA, CN=My Certificate Authority
I would glance at the xsupp documentation to give more advice but the crapforge^Wsourceforge docs links appears to lead in a loop. This is one reason amongst many others you should seriously consider using wpa_supplicant on the clients.
I have a feeling that I've ruined my CA, and I need to re-create my FreeRadius CA. Now, I've re-examined how to make a CA repeatedly, and everything says something different. my CA.pl is located on /etc/pki/tls/misc Given this is the case, from scratch, what is the best way to create a "Fresh" CA for FreeRadius. I've tried multiple documents from Ubuntu to RedHat, (Mandriva doesn't offer any documentation themselves.) So, in the absense of qualified docs, recommendation?
I finally got PEAP working, nowe I have two questions, should I create a dummy account for the mschap element of authentication. Secondly, how do I create additional certs for additional hosts in FreeRadius? As it is now, I can only authenticate one node.
Evan Vittitow wrote:
I finally got PEAP working, nowe I have two questions, should I create a dummy account for the mschap element of authentication. Secondly, how do
Eh? PEAP+MSCHAP requires a real account for the mschap portion.
I create additional certs for additional hosts in FreeRadius? As it is now, I can only authenticate one node.
You need a working CA for that.
Alright, I'm going to step back and talk conceptually. The issue is that the laptops use a combination of LDAP and Kerberos to authenticate to the Domain Controllers. (OpenLDAP and a Kerberos KDC.) to authorize and authenticate Humans. So you get a Chicken/Egg issue. You can't authenticate Humans until you authenticate nodes, but a Human could not enter MS-CHAPv2 passwords wothout logging in. I want to be able to assign a Certificate to a Host, as long as the Host carries the certificate, it can talk on the network. The Cert should be individualized to each host. So, I'd like to be able give a host a cert, and then let them use the network so they can login with User/Password. I have a working CA now.
Evan Vittitow wrote:
Alright, I'm going to step back and talk conceptually. The issue is that the laptops use a combination of LDAP and Kerberos to authenticate to the Domain Controllers.
If that's what you've designed your system to do, then it's seems to be a problem you created for yourself.
(OpenLDAP and a Kerberos KDC.) to authorize and authenticate Humans. So you get a Chicken/Egg issue. You can't authenticate Humans until you authenticate nodes, but a Human could not enter MS-CHAPv2 passwords wothout logging in.
Then don't design the system in a way that makes it impossible to do what you want.
I want to be able to assign a Certificate to a Host, as long as the Host carries the certificate, it can talk on the network. The Cert should be individualized to each host. So, I'd like to be able give a host a cert, and then let them use the network so they can login with User/Password. I have a working CA now.
Then the laptops have to use PEAP, and your switches have to require 802.1x. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Let me re-phrase, as I think I'm not quite making sense. openssl req -new -keyout kurama.pem -out kurama.pem -days 730 openssl x509 -in kurama.pem -out kurama.crt openssl req -new -keyout altanis.pem -out altanis.pem -days 730 openssl x509 -in altanis.pem -out altanis.crt openssl req -new -keyout serenity.pem -out serenity.pem -days 730 openssl x509 -in serenity.pem -out serenity.crt Here are my three laptops, now as far as I know, based on my understanding of how EAP works, as long as the laptops have these certs, they should be able to authenticate users. the certs authenticate the nodes Case #2 openssl req -new -keyout monkey.pem -out monkey.pem -days 2 openssl x509 -in monkey.pem -out monkey.crt This is a temporary cert for an enemy unit I am allowing temporary guest access to the network, I'd like this person to use their MS-Chapv2 credentials.
Evan Vittitow wrote:
Let me re-phrase, as I think I'm not quite making sense.
openssl req -new -keyout kurama.pem -out kurama.pem -days 730 openssl x509 -in kurama.pem -out kurama.crt
openssl req -new -keyout altanis.pem -out altanis.pem -days 730 openssl x509 -in altanis.pem -out altanis.crt
openssl req -new -keyout serenity.pem -out serenity.pem -days 730 openssl x509 -in serenity.pem -out serenity.crt
Those are invalid openssl commands. The "req" subcommand generated a CSR (certificate signing request). One cannot turn a CSR into a CRT with the x509 command - you need to use the "openssl ca" commands for that. FreeRadius comes with wrapper scripts for this. I suggest you extend them to generate the certs.
Here are my three laptops, now as far as I know, based on my understanding of how EAP works, as long as the laptops have these certs, they should be able to authenticate users. the certs authenticate the nodes
To quote yourself, you're "not quite making sense". An 802.1x supplicant communicates with the radius server (via the access point / switch) using EAP. EAP negotiates ONE mechanism common to the supplicant and server, then executes that mechanism to mutually authenticate the client and the server. So, for a given session your supplicants can either use EAP-TLS or PEAP. Whether they use credentials from a per-machine or per-user store is frankly irrelevant. If you choose to use EAP-TLS, you need 4 items: 1. A server certificate, signed by a Cert Authority "serverCA" 2. A CA certificate ON THE SERVER for "clientCA", so the server can validate and trust the client certs. 3. A client certificate, signed by a Cert Authority "clientCA" 4. A CA certificate ON THE CLIENT for "serverCA", so the client can validate and trust the server certs. You can (and usually do) have serverCA == clientCA so items 2 and 4 are the same. If you choose to use EAP-PEAP/MS-CHAPv2 you need 4 items: 1. A server certificate, signed by a Cert Authority "serverCA" 2. At the server, the ability to execute the MS-CHAP algorith for the user - i.e. access to either the plaintext password, the NT/LM hashes, or the ntlm_auth helper binary and a copy of Samba joined to an NT domain 3. At the client, a valid username/password 4. A CA certificate ON THE CLIENT for "serverCA", so the client can validate and trust the server certs. Item 3 (valid username/password) can either by a person account or it can be a machine account (username=netbiosname$, password=longrandomstring) if the machine is joined into an NT domain. You can ALSO in theory use a client certificate with PEAP, but frankly it's more trouble than it is worth unless you have specialist requirements. So - what are you trying to do?
Phil Mayers wrote:
Evan Vittitow wrote:
Let me re-phrase, as I think I'm not quite making sense.
openssl req -new -keyout kurama.pem -out kurama.pem -days 730 openssl x509 -in kurama.pem -out kurama.crt
openssl req -new -keyout altanis.pem -out altanis.pem -days 730 openssl x509 -in altanis.pem -out altanis.crt
openssl req -new -keyout serenity.pem -out serenity.pem -days 730 openssl x509 -in serenity.pem -out serenity.crt
Those are invalid openssl commands. The "req" subcommand generated a CSR (certificate signing request). One cannot turn a CSR into a CRT with the x509 command - you need to use the "openssl ca" commands for that.
FreeRadius comes with wrapper scripts for this. I suggest you extend them to generate the certs.
Here are my three laptops, now as far as I know, based on my understanding of how EAP works, as long as the laptops have these certs, they should be able to authenticate users. the certs authenticate the nodes
To quote yourself, you're "not quite making sense".
An 802.1x supplicant communicates with the radius server (via the access point / switch) using EAP.
EAP negotiates ONE mechanism common to the supplicant and server, then executes that mechanism to mutually authenticate the client and the server.
So, for a given session your supplicants can either use EAP-TLS or PEAP. Whether they use credentials from a per-machine or per-user store is frankly irrelevant.
If you choose to use EAP-TLS, you need 4 items:
1. A server certificate, signed by a Cert Authority "serverCA" 2. A CA certificate ON THE SERVER for "clientCA", so the server can validate and trust the client certs.
3. A client certificate, signed by a Cert Authority "clientCA" 4. A CA certificate ON THE CLIENT for "serverCA", so the client can validate and trust the server certs.
You can (and usually do) have serverCA == clientCA so items 2 and 4 are the same.
If you choose to use EAP-PEAP/MS-CHAPv2 you need 4 items:
1. A server certificate, signed by a Cert Authority "serverCA" 2. At the server, the ability to execute the MS-CHAP algorith for the user - i.e. access to either the plaintext password, the NT/LM hashes, or the ntlm_auth helper binary and a copy of Samba joined to an NT domain
3. At the client, a valid username/password 4. A CA certificate ON THE CLIENT for "serverCA", so the client can validate and trust the server certs.
Item 3 (valid username/password) can either by a person account or it can be a machine account (username=netbiosname$, password=longrandomstring) if the machine is joined into an NT domain.
You can ALSO in theory use a client certificate with PEAP, but frankly it's more trouble than it is worth unless you have specialist requirements.
So - what are you trying to do? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The thing is, method number 1 (EAP-TLS) makes more sense for my laptops. Method number 2 (EAP-PEAP) makes more sense for guest laptops that are not mine. The FreeRadius CA wrapper scripts did not work for my distro, so I'm having to run CA.pl and the various openssl generation programs by hand. Is it possible for both methods of authentication to be acceptable?
Evan Vittitow wrote:
The thing is, method number 1 (EAP-TLS) makes more sense for my laptops. Method number 2 (EAP-PEAP) makes more sense for guest laptops that are not mine.
The FreeRadius CA wrapper scripts did not work for my distro, so I'm having to run CA.pl and the various openssl generation programs by hand.
Is it possible for both methods of authentication to be acceptable?
Yes. This is relatively trivial. Simply ensure that both the "tls" and "peap" sections of "eap.conf" are enabled and configured correctly.
I'm having an issue telling my server certificate from my client certificate: Issues: Which of these is the client certificate, and which of these is the server cert. in eap.conf private_key_file = ${raddbdir}/certs/cakey.pem certificate_file = ${raddbdir}/certs/cacert.crt CA_file = ${raddbdir}/certs/cacert.pem In /etc/xsupplicant.conf eap-peap { random_file = /dev/urandom root_cert = /etc/raddb/certs/cacert.crt chunk_size = 1398 allow_types = eap_mschapv2 eap-mschapv2 { username = password = } eap_tls { user_key = "/etc/raddb/certs/cacert.crt" user_key_pass = "" root_cert = "/etc/raddb/certs/cacert.crt" root_dir = "/etc/raddb/certs/" chunk_size = 1398 random_file = "/dev/random/" session_resume = yes } Who is the server Private/Public keypair? who is the client server public/private pair?
Evan Vittitow wrote:
I'm having an issue telling my server certificate from my client certificate:
Issues: Which of these is the client certificate, and which of these is the server cert.
in eap.conf
private_key_file = ${raddbdir}/certs/cakey.pem certificate_file = ${raddbdir}/certs/cacert.crt CA_file = ${raddbdir}/certs/cacert.pem
"certificate_file" is the server certificate file. "private_key_file" is the key for that certificate. "CA_file" is the file containing the CA cert which FreeRadius will expect CLIENT certs to be signed by.
In /etc/xsupplicant.conf
eap-peap { random_file = /dev/urandom root_cert = /etc/raddb/certs/cacert.crt chunk_size = 1398 allow_types = eap_mschapv2 eap-mschapv2 { username = password = } eap_tls { user_key = "/etc/raddb/certs/cacert.crt" user_key_pass = "" root_cert = "/etc/raddb/certs/cacert.crt" root_dir = "/etc/raddb/certs/" chunk_size = 1398 random_file = "/dev/random/" session_resume = yes }
"root_cert" is the file containing the CA cert which signed FreeRadius' "certificate_file" "user_key" is the file containing the user cert, which must be signed by FreeRadius' "CA_file" cert.
I've been doing reasearch and reading, and started using a GUI for my CA called OpenCA. Using this, I have created some certs cacert.pem cacert.key (Private Key) A variety of Host certs in the format of host-cert.pem and host-key.pem. (A Prublic/Private key per host.) Here is my Xsupplicant.conf eap_tls { user_key = "/etc/pki/tls/Pukey/kurama-cert.pem" user_key_pass = "" root_cert = "/etc/pki/tls/Pukey/cacert.pem" root_dir = "/etc/pki/tls/Pukey/" chunk_size = 1398 random_file = "/dev/random/" session_resume = yes And here is eap.conf's relaventy section private_key_file = /etc/pki/tls/Pukey/kurama-key.pem certificate_file = /etc/pki/tls/Pukey/kurama-cert.pem CA_file = /etc/pki/tls/Pukey/cacert.pem dh_file = ${raddbdir}/certs/dh This produces the following: OpenSSL Error -- error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Library : SSL routines Function : SSL3_GET_SERVER_CERTIFICATE Reason : certificate verify failed Help?
Evan Vittitow wrote:
Here is my Xsupplicant.conf ... This produces the following: ... Help?
I suggest asking on the Xsupplicant list. They *do* have a list, and it's not this one. You're more likely to get a useful response if you ask questions on the right list. i.e. I don't use xsupplicant, and don't know much about it. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
I need help using TinyCA to manage certificates with FreeRadius. I keep getting this. modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: EAP packet type response id 144 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 1 modcall[authorize]: module "files" returns notfound 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 NAK rlm_eap: EAP-NAK asked for EAP-Type/tls rlm_eap: processing type tls rlm_eap_tls: Requiring client certificate rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 1 modcall: leaving group authenticate (returns handled) for request 1 Sending Access-Challenge of id 179 to 192.168.0.250 port 1823 EAP-Message = 0x019100060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xda517fdde94c93e468275c3b886f60b4 Finished request 1 Going to the next request
FreeRadius is booting the EAP clients if more than one EAP node shows up on the AP. XSupplicant and Radius give the EoAoL message to boot additional nodes. And my Aironet, while succeeded in authentication, reasociates with the other APs in a standard assciation, not an EAP one.
Evan Vittitow wrote:
FreeRadius is booting the EAP clients if more than one EAP node shows up on the AP.
That's impossible. RADIUS doesn't work like that.
XSupplicant and Radius give the EoAoL message to boot additional nodes.
There is no such message in RADIUS.
And my Aironet, while succeeded in authentication, reasociates with the other APs in a standard assciation, not an EAP one.
I suggest asking the Aironet people. You're not having RADIUS problems. As a result, I don't know if anyone here can help you. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (4)
-
Alan DeKok -
Evan Vittitow -
Phil Mayers -
Zombie Ryushu