Multiple radius servers with the same CA
Hi All, I've been searching the archives for a while on some guidance into setting up multiple radius servers using the same CA for use with EAP/TTLS. I've generated a CA which is distributed to all the clients (i.e. SecureW2). I've got 2 radius servers for redundancy. All NAS devices have two radius server configured. I'm using the scripts from freeradius 2.0 to generate the certificates according to instructions in the README. I've setup the ca.cnf and server.cnf (not using eap/tls so I skip clients.cf). On the primary radius server I generated the certificates by issuing: make Now on the second radius server I just copy the following files: /certs/ca.pem /certs/ca.key /certs/ca.der /certs/*.cnf /certs/Makefile /certs/README /certs/xpextensions and issue: make server make dh This seems to have worked. But is this really correct? I'm renewing one radius server and did this procedure again but now I'm receiving "chain could not be validated" errors in SecureW2. Radius log seems fine however EAP communication is not finished which corresponds with the client stopping communication since it can't validate the certificate. I'm really getting lost in the SSL jungle? I would really like to understand how this is done right, since it is about security. Rg, Arnaud -- View this message in context: http://old.nabble.com/Multiple-radius-servers-with-the-same-CA-tp28013061p28... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi, is it possible that make server generated a new CA etc? I'd recommend making a copy of the current CA cert on each machine and doing a diff Regards, Matt Harlum On 24/03/2010, at 9:21 PM, sphaero wrote:
Hi All,
I've been searching the archives for a while on some guidance into setting up multiple radius servers using the same CA for use with EAP/TTLS.
I've generated a CA which is distributed to all the clients (i.e. SecureW2). I've got 2 radius servers for redundancy. All NAS devices have two radius server configured.
I'm using the scripts from freeradius 2.0 to generate the certificates according to instructions in the README. I've setup the ca.cnf and server.cnf (not using eap/tls so I skip clients.cf).
On the primary radius server I generated the certificates by issuing: make
Now on the second radius server I just copy the following files: /certs/ca.pem /certs/ca.key /certs/ca.der /certs/*.cnf /certs/Makefile /certs/README /certs/xpextensions
and issue: make server make dh
This seems to have worked. But is this really correct? I'm renewing one radius server and did this procedure again but now I'm receiving "chain could not be validated" errors in SecureW2. Radius log seems fine however EAP communication is not finished which corresponds with the client stopping communication since it can't validate the certificate. I'm really getting lost in the SSL jungle? I would really like to understand how this is done right, since it is about security.
Rg,
Arnaud -- View this message in context: http://old.nabble.com/Multiple-radius-servers-with-the-same-CA-tp28013061p28... Sent from the FreeRadius - User mailing list archive at Nabble.com.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Matt Harlum wrote:
Hi,
is it possible that make server generated a new CA etc?
I'd recommend making a copy of the current CA cert on each machine and doing a diff
Regards, Matt Harlum
[snip]
You're absolutely right. I did a md5sum on the CA.pem on the production radius and this new one and it is different. Now how did that happen? I did a md5sum on all ca.* files and the .key and .pem are different. It must have happened either by issuing make server.pem or make dh I've checked the history of my actions: 66 make server.pem 67 nano ../eap.conf 68 fg 69 freeradius -X & 70 make dh 71 freeradius -X & I remember I started freeradius while I hadn't generated the dh file. I'm going to check the exact actions of the Makefile. Rg, Arnaud -- View this message in context: http://old.nabble.com/Multiple-radius-servers-with-the-same-CA-tp28013061p28... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 03/24/2010 06:21 AM, sphaero wrote:
Hi All,
I've been searching the archives for a while on some guidance into setting up multiple radius servers using the same CA for use with EAP/TTLS.
I've generated a CA which is distributed to all the clients (i.e. SecureW2). I've got 2 radius servers for redundancy. All NAS devices have two radius server configured.
I'm using the scripts from freeradius 2.0 to generate the certificates according to instructions in the README. I've setup the ca.cnf and server.cnf (not using eap/tls so I skip clients.cf).
On the primary radius server I generated the certificates by issuing: make
Now on the second radius server I just copy the following files: /certs/ca.pem /certs/ca.key /certs/ca.der /certs/*.cnf /certs/Makefile /certs/README /certs/xpextensions
and issue: make server make dh
This seems to have worked. But is this really correct? I'm renewing one radius server and did this procedure again but now I'm receiving "chain could not be validated" errors in SecureW2. Radius log seems fine however EAP communication is not finished which corresponds with the client stopping communication since it can't validate the certificate. I'm really getting lost in the SSL jungle? I would really like to understand how this is done right, since it is about security.
It would help to read the Makefile and understand it. Your goal is to produce multiple certificates, each with a unique subject (e.g. the host name of the radius server) and have it signed by the ca. There is no need to do this process on each machine, the creation of certs can be done on any machine. Find the part of the Makefile which says this: "Create a new server certificate, signed by the above CA." If you make the target server.pem target (e.g. make server) it will cause the Makefile to execute a series of commands to produce the certificate starting with a CSR (Certificate Signing Request). Note, the server.csr target depends on server.cnf so make sure you edit this for each server whose certificate you want to generate (see the req(1) man page to understand how the certificate subject, e.g. DN, may be specified). But also note in the Makefile that server.crt is dependent on ca.key and ca.pem, which themselves are dependent on ca.cnf. If when you copy the files the ca.cnf file ends up with a newer timestamp than ca.key or ca.pem then a new ca will be created, you don't want that. You can either fix the timestamps using touch or just make all the certs on one machine so you don't have to worry about the ca being recreated. After you've created your certificates on the one machine (don't foget to rename the server.{crt,p12,pem} files) dump them out using openssl x509 -in XXX.pem -inform PEM -text and verify each has the certificate subject you expected. Then verify the each cert with: openssl verify -CAfile ca.pem XXX.pem If that succeeds you'll know each is successfully signed by the same ca and you can distribute that ca to your clients. Then copy your server certs to your RADIUS hosts, don't forget to edit the config so certificate names match how you named your certs (it will no longer be server.{crt,p12,pem}. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi, John covered pretty much everything I was going to say I'd recommend choosing a machine to generate your keys and certs on and sticking with that, otherwise you'll end up with SSL Certs with clashing serial numbers Plus it'll allow you to revoke certificates later if need be Regards, Matt Harlum On 24/03/2010, at 11:30 PM, John Dennis wrote:
On 03/24/2010 06:21 AM, sphaero wrote:
Hi All,
I've been searching the archives for a while on some guidance into setting up multiple radius servers using the same CA for use with EAP/TTLS.
I've generated a CA which is distributed to all the clients (i.e. SecureW2). I've got 2 radius servers for redundancy. All NAS devices have two radius server configured.
I'm using the scripts from freeradius 2.0 to generate the certificates according to instructions in the README. I've setup the ca.cnf and server.cnf (not using eap/tls so I skip clients.cf).
On the primary radius server I generated the certificates by issuing: make
Now on the second radius server I just copy the following files: /certs/ca.pem /certs/ca.key /certs/ca.der /certs/*.cnf /certs/Makefile /certs/README /certs/xpextensions
and issue: make server make dh
This seems to have worked. But is this really correct? I'm renewing one radius server and did this procedure again but now I'm receiving "chain could not be validated" errors in SecureW2. Radius log seems fine however EAP communication is not finished which corresponds with the client stopping communication since it can't validate the certificate. I'm really getting lost in the SSL jungle? I would really like to understand how this is done right, since it is about security.
It would help to read the Makefile and understand it. Your goal is to produce multiple certificates, each with a unique subject (e.g. the host name of the radius server) and have it signed by the ca. There is no need to do this process on each machine, the creation of certs can be done on any machine.
Find the part of the Makefile which says this:
"Create a new server certificate, signed by the above CA."
If you make the target server.pem target (e.g. make server) it will cause the Makefile to execute a series of commands to produce the certificate starting with a CSR (Certificate Signing Request). Note, the server.csr target depends on server.cnf so make sure you edit this for each server whose certificate you want to generate (see the req(1) man page to understand how the certificate subject, e.g. DN, may be specified).
But also note in the Makefile that server.crt is dependent on ca.key and ca.pem, which themselves are dependent on ca.cnf. If when you copy the files the ca.cnf file ends up with a newer timestamp than ca.key or ca.pem then a new ca will be created, you don't want that. You can either fix the timestamps using touch or just make all the certs on one machine so you don't have to worry about the ca being recreated.
After you've created your certificates on the one machine (don't foget to rename the server.{crt,p12,pem} files) dump them out using
openssl x509 -in XXX.pem -inform PEM -text
and verify each has the certificate subject you expected.
Then verify the each cert with:
openssl verify -CAfile ca.pem XXX.pem
If that succeeds you'll know each is successfully signed by the same ca and you can distribute that ca to your clients. Then copy your server certs to your RADIUS hosts, don't forget to edit the config so certificate names match how you named your certs (it will no longer be server.{crt,p12,pem}. -- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Matt Harlum wrote:
Hi,
John covered pretty much everything I was going to say
I'd recommend choosing a machine to generate your keys and certs on and sticking with that, otherwise you'll end up with SSL Certs with clashing serial numbers Plus it'll allow you to revoke certificates later if need be
Regards, Matt Harlum
On 24/03/2010, at 11:30 PM, John Dennis wrote:
On 03/24/2010 06:21 AM, sphaero wrote:
Hi All,
I've been searching the archives for a while on some guidance into setting up multiple radius servers using the same CA for use with EAP/TTLS.
I've generated a CA which is distributed to all the clients (i.e. SecureW2). I've got 2 radius servers for redundancy. All NAS devices have two radius server configured.
I'm using the scripts from freeradius 2.0 to generate the certificates according to instructions in the README. I've setup the ca.cnf and server.cnf (not using eap/tls so I skip clients.cf).
On the primary radius server I generated the certificates by issuing: make
Now on the second radius server I just copy the following files: /certs/ca.pem /certs/ca.key /certs/ca.der /certs/*.cnf /certs/Makefile /certs/README /certs/xpextensions
and issue: make server make dh
This seems to have worked. But is this really correct? I'm renewing one radius server and did this procedure again but now I'm receiving "chain could not be validated" errors in SecureW2. Radius log seems fine however EAP communication is not finished which corresponds with the client stopping communication since it can't validate the certificate. I'm really getting lost in the SSL jungle? I would really like to understand how this is done right, since it is about security.
It would help to read the Makefile and understand it. Your goal is to produce multiple certificates, each with a unique subject (e.g. the host name of the radius server) and have it signed by the ca. There is no need to do this process on each machine, the creation of certs can be done on any machine.
Find the part of the Makefile which says this:
"Create a new server certificate, signed by the above CA."
If you make the target server.pem target (e.g. make server) it will cause the Makefile to execute a series of commands to produce the certificate starting with a CSR (Certificate Signing Request). Note, the server.csr target depends on server.cnf so make sure you edit this for each server whose certificate you want to generate (see the req(1) man page to understand how the certificate subject, e.g. DN, may be specified).
But also note in the Makefile that server.crt is dependent on ca.key and ca.pem, which themselves are dependent on ca.cnf. If when you copy the files the ca.cnf file ends up with a newer timestamp than ca.key or ca.pem then a new ca will be created, you don't want that. You can either fix the timestamps using touch or just make all the certs on one machine so you don't have to worry about the ca being recreated.
After you've created your certificates on the one machine (don't foget to rename the server.{crt,p12,pem} files) dump them out using
openssl x509 -in XXX.pem -inform PEM -text
and verify each has the certificate subject you expected.
Then verify the each cert with:
openssl verify -CAfile ca.pem XXX.pem
If that succeeds you'll know each is successfully signed by the same ca and you can distribute that ca to your clients. Then copy your server certs to your RADIUS hosts, don't forget to edit the config so certificate names match how you named your certs (it will no longer be server.{crt,p12,pem}. -- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -
Hi all, Thanks for these clarifications. So to clear this up I know have one machine to generate the certificates. This machine had it's CA setup according to instructions found in the certs/README distributed with FR 2. Certificates for a second radius server (radius2) using the same CA are generated as follow: # Certificate request (.csr) en key (.key) openssl req -new -out radius2.csr -keyout lx0008.key -config ./server.cnf # Certificate (.crt) openssl ca -batch -keyfile ca.key -cert ca.pem -in radius2.csr -key $PASSWORD_CA -out radius2.crt -extensions xpserver_ext -extfile xpextensions -config ./server.cnf # p12 openssl pkcs12 -export -in radius2.crt -inkey radius2.key -out radius2.p12 -passin pass:$PASSWORD_SERVER -passout pass:$PASSWORD_SERVER # PEM openssl pkcs12 -in radius2.p12 -out radius2.pem -passin pass:$PASSWORD_SERVER -passout pass:$PASSWORD_SERVER (Ofcourse the password vars are replaced with the vars in the ca.cnf & server.cnf) I then copy the following files onto this second radius server: radius2.pem and ca.pem Finally I generate a dh file on the second radius server: openssl dhparam -out dh 1024 Bump, still doesn't work :( I'm still doing something wrong? Rg, Arnaud -- View this message in context: http://old.nabble.com/Multiple-radius-servers-with-the-same-CA-tp28013061p28... Sent from the FreeRadius - User mailing list archive at Nabble.com.
sphaero wrote:
Hi all,
Thanks for these clarifications. So to clear this up I know have one machine to generate the certificates. This machine had it's CA setup according to instructions found in the certs/README distributed with FR 2.
Certificates for a second radius server (radius2) using the same CA are generated as follow:
# Certificate request (.csr) en key (.key) openssl req -new -out radius2.csr -keyout lx0008.key -config ./server.cnf # Certificate (.crt) openssl ca -batch -keyfile ca.key -cert ca.pem -in radius2.csr -key $PASSWORD_CA -out radius2.crt -extensions xpserver_ext -extfile xpextensions -config ./server.cnf # p12 openssl pkcs12 -export -in radius2.crt -inkey radius2.key -out radius2.p12 -passin pass:$PASSWORD_SERVER -passout pass:$PASSWORD_SERVER # PEM openssl pkcs12 -in radius2.p12 -out radius2.pem -passin pass:$PASSWORD_SERVER -passout pass:$PASSWORD_SERVER
(Ofcourse the password vars are replaced with the vars in the ca.cnf & server.cnf)
I then copy the following files onto this second radius server: radius2.pem and ca.pem
Finally I generate a dh file on the second radius server: openssl dhparam -out dh 1024
Bump, still doesn't work :( I'm still doing something wrong?
Rg,
Arnaud
Forget that last sentence. It does work. Was probably something with the nas. But if someone can confirm this procedure so it's safe. Rg, Arnaud -- View this message in context: http://old.nabble.com/Multiple-radius-servers-with-the-same-CA-tp28013061p28... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 03/24/2010 11:13 AM, sphaero wrote:
Matt Harlum wrote:
Hi,
John covered pretty much everything I was going to say
I'd recommend choosing a machine to generate your keys and certs on and sticking with that, otherwise you'll end up with SSL Certs with clashing serial numbers Plus it'll allow you to revoke certificates later if need be
Regards, Matt Harlum
On 24/03/2010, at 11:30 PM, John Dennis wrote:
On 03/24/2010 06:21 AM, sphaero wrote:
Hi All,
I've been searching the archives for a while on some guidance into setting up multiple radius servers using the same CA for use with EAP/TTLS.
I've generated a CA which is distributed to all the clients (i.e. SecureW2). I've got 2 radius servers for redundancy. All NAS devices have two radius server configured.
I'm using the scripts from freeradius 2.0 to generate the certificates according to instructions in the README. I've setup the ca.cnf and server.cnf (not using eap/tls so I skip clients.cf).
On the primary radius server I generated the certificates by issuing: make
Now on the second radius server I just copy the following files: /certs/ca.pem /certs/ca.key /certs/ca.der /certs/*.cnf /certs/Makefile /certs/README /certs/xpextensions
and issue: make server make dh
This seems to have worked. But is this really correct? I'm renewing one radius server and did this procedure again but now I'm receiving "chain could not be validated" errors in SecureW2. Radius log seems fine however EAP communication is not finished which corresponds with the client stopping communication since it can't validate the certificate. I'm really getting lost in the SSL jungle? I would really like to understand how this is done right, since it is about security.
It would help to read the Makefile and understand it. Your goal is to produce multiple certificates, each with a unique subject (e.g. the host name of the radius server) and have it signed by the ca. There is no need to do this process on each machine, the creation of certs can be done on any machine.
Find the part of the Makefile which says this:
"Create a new server certificate, signed by the above CA."
If you make the target server.pem target (e.g. make server) it will cause the Makefile to execute a series of commands to produce the certificate starting with a CSR (Certificate Signing Request). Note, the server.csr target depends on server.cnf so make sure you edit this for each server whose certificate you want to generate (see the req(1) man page to understand how the certificate subject, e.g. DN, may be specified).
But also note in the Makefile that server.crt is dependent on ca.key and ca.pem, which themselves are dependent on ca.cnf. If when you copy the files the ca.cnf file ends up with a newer timestamp than ca.key or ca.pem then a new ca will be created, you don't want that. You can either fix the timestamps using touch or just make all the certs on one machine so you don't have to worry about the ca being recreated.
After you've created your certificates on the one machine (don't foget to rename the server.{crt,p12,pem} files) dump them out using
openssl x509 -in XXX.pem -inform PEM -text
and verify each has the certificate subject you expected.
Then verify the each cert with:
openssl verify -CAfile ca.pem XXX.pem
If that succeeds you'll know each is successfully signed by the same ca and you can distribute that ca to your clients. Then copy your server certs to your RADIUS hosts, don't forget to edit the config so certificate names match how you named your certs (it will no longer be server.{crt,p12,pem}. -- John Dennis<jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -
Hi all,
Thanks for these clarifications. So to clear this up I know have one machine to generate the certificates. This machine had it's CA setup according to instructions found in the certs/README distributed with FR 2.
Certificates for a second radius server (radius2) using the same CA are generated as follow:
# Certificate request (.csr) en key (.key) openssl req -new -out radius2.csr -keyout lx0008.key -config ./server.cnf # Certificate (.crt) openssl ca -batch -keyfile ca.key -cert ca.pem -in radius2.csr -key $PASSWORD_CA -out radius2.crt -extensions xpserver_ext -extfile xpextensions -config ./server.cnf # p12 openssl pkcs12 -export -in radius2.crt -inkey radius2.key -out radius2.p12 -passin pass:$PASSWORD_SERVER -passout pass:$PASSWORD_SERVER # PEM openssl pkcs12 -in radius2.p12 -out radius2.pem -passin pass:$PASSWORD_SERVER -passout pass:$PASSWORD_SERVER
(Ofcourse the password vars are replaced with the vars in the ca.cnf& server.cnf)
I then copy the following files onto this second radius server: radius2.pem and ca.pem
Finally I generate a dh file on the second radius server: openssl dhparam -out dh 1024
Bump, still doesn't work :( I'm still doing something wrong?
Did you edit your eap.conf file to point to radius2.pem? Did you set your private_key_password in eap.conf to match $PASSWORD_CA used above? BTW, don't use the same password as in the example ;-) Did you verify the certs as suggested above? Saying something doesn't work isn't helpful, the log output would be helpful. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
[snip] Did you edit your eap.conf file to point to radius2.pem? Did you set your private_key_password in eap.conf to match $PASSWORD_CA used above? BTW, don't use the same password as in the example ;-)
Did you verify the certs as suggested above?
Saying something doesn't work isn't helpful, the log output would be helpful.
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yep did all that. I think I was working on this too long, starting to see double. On the machine where I generate the certificate: openssl verify -CAfile ca.pem lx0008.pem lx0008.pem: OK However if I copy the file over to the other machine: openssl verify -CAfile ca.pem lx0008.pem lx0008.pem: /C=NL/ST=Radius/O=AOg/CN=Radius Certificate/emailAddress=nw@aog.nl error 9 at 0 depth lookup:certificate is not yet valid But I discoverd a time sync issue here. Clocks are 10 min. apart. This was a bit of clue, right. So I checked the client I was testing this on, and it was a day behind. So it could never validate the certificate. So setting up some time synchronisation resolved this. openssl verify -CAfile ca.pem lx0008.pem lx0008.pem: OK Here's the log output of the failed attempt. The eap exchange stops at: Sending Access-Challenge After setting time right it works as expected. Thanks for all help! Rg, Arnaud rad_recv: Access-Request packet from host 10.6.254.189:1024, id=51, length=214 Framed-MTU = 1480 NAS-IP-Address = 10.6.254.189 NAS-Identifier = "ENNR" User-Name = "lsa@aog.nl" Service-Type = Framed-User Framed-Protocol = PPP NAS-Port = 1 NAS-Port-Type = Ethernet NAS-Port-Id = "1" Called-Station-Id = "00-18-fe-57-b7-60" Calling-Station-Id = "00-d0-59-9d-9a-3c" Connect-Info = "CONNECT Ethernet 100Mbps Full duplex" Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "138" State = 0x271f405150fffa1a648249140e571065 EAP-Message = 0x022200061500 Message-Authenticator = 0xd9de91ff01317e671b475cdf3125a11a Processing the authorize section of radiusd.conf modcall: entering group authorize for request 3 modcall[authorize]: module "preprocess" returns ok for request 3 modcall[authorize]: module "chap" returns noop for request 3 modcall[authorize]: module "mschap" returns noop for request 3 rlm_realm: Looking up realm "aog.nl" for User-Name = "lsa@aog.nl" rlm_realm: Found realm "DEFAULT" rlm_realm: Adding Stripped-User-Name = "lsa" rlm_realm: Proxying request from user lsa to realm DEFAULT rlm_realm: Adding Realm = "DEFAULT" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 3 rlm_eap: EAP packet type response id 34 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 3 users: Matched entry DEFAULT at line 156 modcall[authorize]: module "files" returns ok for request 3 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 3 modcall: leaving group authorize (returns updated) for request 3 Found Autz-Type asa Processing the authorize section of radiusd.conf modcall: entering group asa for request 3 radius_xlat: 'lsa' rlm_sql (asa): sql_set_user escaped user --> 'lsa' radius_xlat: 'SELECT UserID,Usernaam,'SHA-Password' AS Attribute, Wachtwoord, ':=' AS Op FROM bas_user WHERE Usernaam = 'lsa' AND Actief = 1 ORDER BY UserID' rlm_sql (asa): Reserving sql socket id: 1 radius_xlat: '' radius_xlat: 'SELECT UserID,Usernaam,'Reply-Message' AS Attribute, Achternaam, '=' AS Op from bas_user WHERE Usernaam = 'lsa' AND Actief = 1 ORDER BY UserID ' radius_xlat: '' rlm_sql (asa): Released sql socket id: 1 modcall[authorize]: module "asa" returns ok for request 3 rlm_pap: Normalizing SHA-Password from hex encoding rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 3 modcall: leaving group asa (returns ok) for request 3 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 3 rlm_eap: Request found, released from the list rlm_eap: EAP/ttls rlm_eap: processing type ttls rlm_eap_ttls: 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 modcall[authenticate]: module "eap" returns handled for request 3 modcall: leaving group authenticate (returns handled) for request 3 Sending Access-Challenge of id 51 to 10.6.254.189 port 1024 Service-Type = Framed-User Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "132" Reply-Message = "Loonstra" EAP-Message = 0x0123040a15c000000969c8049aa1fa621dd38e41b929518a3c23d2fd05e03097c2956b56307195bb23fef70dc1288f83798a26c511427a6226b15e62cbe20135878672c254894d8b5cac9600051c3082051830820400a003020102020900d7489a39739dc2be300d06092a864886f70d01010505003081b8310b3009060355040613024e4c310f300d060355040813065261646975733119301706035504071310416d6172616e746973205261646975733121301f060355040a1318416d6172616e746973204f6e64657277696a7367726f65703129302706092a864886f70d010901161a6e65747765726b62656865657240616d6172616e7469732e EAP-Message = 0x6e6c312f302d06035504031326416d6172616e7469732052616469757320436572746966696361746520417574686f72697479301e170d3038303932323133323131395a170d3138303932303133323131395a3081b8310b3009060355040613024e4c310f300d060355040813065261646975733119301706035504071310416d6172616e746973205261646975733121301f060355040a1318416d6172616e746973204f6e64657277696a7367726f65703129302706092a864886f70d010901161a6e65747765726b62656865657240616d6172616e7469732e6e6c312f302d06035504031326416d6172616e746973205261646975732043657274 EAP-Message = 0x6966696361746520417574686f7269747930820122300d06092a864886f70d01010105000382010f003082010a0282010100b638d7f91164627f1f26b1b9c6b80c60d0f5f09788d12f7f8e05f4d5c56d3e7c12d45c07c7d4c6549924ffa6f89ffbb8e05c27479f62c7829d11eb919da7756ae3fa7d04b0830838c664c9b36be9621932cd6c212135c0c390942d191fe61d6aa63c41db73c2ff9590bc551547b5ef43cdd433a85ff6d012573eb4a6d1597c900ef9117eb0ae006b41649b4ab71e1243c8e4cf3abee6f062494669453f9619b0f4815684380f3bedda3b66ca5cfe47f57e9f272fa1e3f4a7d5945c439e92ddd2d5a037caedd024b98b846a EAP-Message = 0xd1671051f441d970f0424d695f96cb1336d5225febae79a91606fecfe2be75698c6c4fc512edc155f6d7ec2556f01d325126cee3ef0203010001a38201213082011d301d0603551d0e0416041439c24dc7a03a56dacbc5217ae8deaabbe13a1c193081ed0603551d230481e53081e2801439c24dc7a03a56dacbc5217ae8deaabbe13a1c19a181bea481bb3081b8310b3009060355040613024e4c310f300d060355040813065261646975733119301706035504071310416d6172616e746973205261646975733121301f060355040a1318416d6172616e746973204f6e64657277696a7367726f65703129302706092a864886f70d010901161a6e65 EAP-Message = 0x747765726b62656865657240616d6172616e7469732e Message-Authenticator = 0x00000000000000000000000000000000 State = 0x9e7aef98290aab34c5bdeffbf332c930 Finished request 3 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 10.6.254.189:1024, id=52, length=214 Framed-MTU = 1480 NAS-IP-Address = 10.6.254.189 NAS-Identifier = "ENNR" User-Name = "lsa@aog.nl" Service-Type = Framed-User Framed-Protocol = PPP NAS-Port = 1 NAS-Port-Type = Ethernet NAS-Port-Id = "1" Called-Station-Id = "00-18-fe-57-b7-60" Calling-Station-Id = "00-d0-59-9d-9a-3c" Connect-Info = "CONNECT Ethernet 100Mbps Full duplex" Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "138" State = 0x9e7aef98290aab34c5bdeffbf332c930 EAP-Message = 0x022300061500 Message-Authenticator = 0x4290459647a474c647d2bf8a6fef24f8 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 4 modcall[authorize]: module "preprocess" returns ok for request 4 modcall[authorize]: module "chap" returns noop for request 4 modcall[authorize]: module "mschap" returns noop for request 4 rlm_realm: Looking up realm "aog.nl" for User-Name = "lsa@aog.nl" rlm_realm: Found realm "DEFAULT" rlm_realm: Adding Stripped-User-Name = "lsa" rlm_realm: Proxying request from user lsa to realm DEFAULT rlm_realm: Adding Realm = "DEFAULT" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 4 rlm_eap: EAP packet type response id 35 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 4 users: Matched entry DEFAULT at line 156 modcall[authorize]: module "files" returns ok for request 4 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 4 modcall: leaving group authorize (returns updated) for request 4 Found Autz-Type asa Processing the authorize section of radiusd.conf modcall: entering group asa for request 4 radius_xlat: 'lsa' rlm_sql (asa): sql_set_user escaped user --> 'lsa' radius_xlat: 'SELECT UserID,Usernaam,'SHA-Password' AS Attribute, Wachtwoord, ':=' AS Op FROM bas_user WHERE Usernaam = 'lsa' AND Actief = 1 ORDER BY UserID' rlm_sql (asa): Reserving sql socket id: 0 radius_xlat: '' radius_xlat: 'SELECT UserID,Usernaam,'Reply-Message' AS Attribute, Achternaam, '=' AS Op from bas_user WHERE Usernaam = 'lsa' AND Actief = 1 ORDER BY UserID ' radius_xlat: '' rlm_sql (asa): Released sql socket id: 0 modcall[authorize]: module "asa" returns ok for request 4 rlm_pap: Normalizing SHA-Password from hex encoding rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 4 modcall: leaving group asa (returns ok) for request 4 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 4 rlm_eap: Request found, released from the list rlm_eap: EAP/ttls rlm_eap: processing type ttls rlm_eap_ttls: 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 modcall[authenticate]: module "eap" returns handled for request 4 modcall: leaving group authenticate (returns handled) for request 4 Sending Access-Challenge of id 52 to 10.6.254.189 port 1024 Service-Type = Framed-User Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "132" Reply-Message = "Loonstra" EAP-Message = 0x012401731580000009696e6c312f302d06035504031326416d6172616e7469732052616469757320436572746966696361746520417574686f72697479820900d7489a39739dc2be300c0603551d13040530030101ff300d06092a864886f70d01010505000382010100454dfc9bb4cbcf95b5f701246176fd230f70bea0564a0197a28047390ac07c4d77609834f9a422361f4ede51bd4ea30d051893ff236b6cc7b41c7499535829221400d18a177b680caff00689e1db909167f5d5331d5c239a164b9b0731ff047b8317771b5cd9a3d41b80b4be974c13d6718e2cbeed6de3f20b3c4828d76ddd3d22667f2bc119dae184b60fb0b4d9bf5377d1b0 EAP-Message = 0xc01469c020e470c2d300264d2eaed55c7d81257cc14baeba7df5f6b1b255603a91e6bdfa9c7ecccee3c2e370084d807db1e8bdb0113de9ad8a744601813b8c9a9819007d6ce46ace182c9b410274b8b6facd3b085ca4b8e07424aca602afc83df29e78cbe45d4c2de4e825595d16030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x8645d7e4f090233c4a654c8cbbfec31e Finished request 4 Going to the next request --- Walking the entire request list --- Waking up in 5 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 48 with timestamp 4baa367f Cleaning up request 1 ID 49 with timestamp 4baa367f Cleaning up request 2 ID 50 with timestamp 4baa367f Cleaning up request 3 ID 51 with timestamp 4baa367f Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 4 ID 52 with timestamp 4baa3680 Nothing to do. Sleeping until we see a request. -- View this message in context: http://old.nabble.com/Multiple-radius-servers-with-the-same-CA-tp28013061p28... Sent from the FreeRadius - User mailing list archive at Nabble.com.
participants (3)
-
John Dennis -
Matt Harlum -
sphaero