Hello!
I have been using Windows 7, Freeradius 2.1.10 from Debian Squeeze, HP
MSM710 WLAN controller and EAP_TLS Computer Certificate Authentication
for a log time and worked perfect. I used Certificates created on the
Debian server by openssl including the extensions for Client
So you went from a working system and then changed everything for the switch
authentication. Why? Why didn't you just keep the same AAA backend?
Either way, if you want to use 2 different certs and CAs then you'll need 2
instances or proxy the other ones off to eg microsd NPS server..but
Hi,
my radius client is sending with user-name and password aslo realm. I
can not disable sending realm, is it possible to configure radius that
will not user realm with user-name (user-name@realm)?
[digest] Digest-Attributes look OK. Converting them to something more
usful.
On 23/01/13 14:47, Miha wrote:
Hi,
my radius client is sending with user-name and password aslo realm. I
can not disable sending realm, is it possible to configure radius that
will not user realm with user-name (user-name@realm)?
[digest] Digest-Attributes look OK. Converting them to
On Wed, Jan 23, 2013 at 2:47 PM, Miha m...@softnet.si wrote:
Hi,
my radius client is sending with user-name and password aslo realm. I can
not disable sending realm, is it possible to configure radius that will not
user realm with user-name (user-name@realm)?
i only know that it is
On 01/23/2013 04:32 AM, Armin Maier wrote:
Hello!
I have been using Windows 7, Freeradius 2.1.10 from Debian Squeeze, HP
MSM710 WLAN controller and EAP_TLS Computer Certificate Authentication
for a log time and worked perfect. I used Certificates created on the
Debian server by openssl including
Am 23.01.2013, 19:53 Uhr, schrieb Stephan Manske
gmane-re...@stephan.manske-net.de:
Yes, it is a ssl problem, the ca.key and all the certs are incompatible.
And no, it is not only a ssl problem, it is a freeradius problem, too:
Unless the makefile in certs is provided by openssl, but I
Am 22.01.2013, 22:19 Uhr, schrieb Alan DeKok al...@deployingradius.com:
Stephan Manske wrote:
[tls] -- verify return:1
-- verify error:num=7:certificate signature failure
[tls] TLS 1.0 Alert [length 0002], fatal decrypt_error
TLS Alert write:fatal:decrypt error
TLS_accept: error in SSLv3
On 01/23/2013 12:24 PM, John Dennis wrote:
On 01/23/2013 04:32 AM, Armin Maier wrote:
Hello!
I have been using Windows 7, Freeradius 2.1.10 from Debian Squeeze, HP
MSM710 WLAN controller and EAP_TLS Computer Certificate Authentication
for a log time and worked perfect. I used Certificates
Stephan Manske wrote:
Unless the makefile in certs is provided by openssl, but I think this is
freeradius stuff, or?
The Makefile I pointed to was written by me. It runs OpenSSL scripts
to create certificates. It uses sample configurations written by me.
It works for *everyone* else. If
Stephan Manske wrote:
I think I found the issue:
...
makes ca.key dependant to the date of index.txt and serial
Both files are updated every time a new client cert is build. IMHO.
OK. That's a better explanation than FreeRADIUS is wrong.
There's a fix on github, which will be in 2.2.1.
Hi,
IMHO these patch
https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f968db1ee108eb6f05db09#raddb/certs/Makefile
with
+ca.key ca.pem: ca.cnf index.txt serial
you stated earlier that you didnt touch freeradius...that all you did was
update
OpenSSL to the latest
Am 23.01.2013, 21:03 Uhr, schrieb Alan DeKok al...@deployingradius.com:
Stephan Manske wrote:
Unless the makefile in certs is provided by openssl, but I think this is
freeradius stuff, or?
It works for *everyone* else. If you didn't use the Makefiles to
create the certs, then don't
On 01/23/2013 01:53 PM, Stephan Manske wrote:
IMHO these patch
https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f968db1ee108eb6f05db09#raddb/certs/Makefile
with
+ca.key ca.pem: ca.cnf index.txt serial
makes ca.key dependant to the date of index.txt and serial
Both
Thanks for your reply.
Fortunately it seems that the segfault is a false alarm.
As it semt strange to me that Freeradius stop working by segfault, I
installed FR in another PC and I copy the same configuration.
Now it seems to be working, except that it stays in loop on DHCP
Discover (no Offer,
Thanks Alan for the info. By using the if statement I was able to stop the
processing of the request. However I need to do more research and
communicating with our AD or our NPS server. However since that doesn't
involve the subject of this message I would start another question without
Am 23.01.2013, 21:13 Uhr, schrieb Alan DeKok al...@deployingradius.com:
Stephan Manske wrote:
I think I found the issue:
...
makes ca.key dependant to the date of index.txt and serial
Both files are updated every time a new client cert is build. IMHO.
OK. That's a better explanation
hi,
those ID values look a little 'wierd' - vary large and negative
does the DHCP response leave the server? do you have anything
like dHCP snooping on the network that might be blocking the
responses from this new DHCP server or is the client getting
its answers from a.n.another DHCP
Am 23.01.2013, 21:23 Uhr, schrieb a.l.m.bu...@lboro.ac.uk:
IMHO these patch
https://github.com/FreeRADIUS/freeradius-server/commit/2d3f119cd8d9e99028f968db1ee108eb6f05db09#raddb/certs/Makefile
with
+ca.key ca.pem: ca.cnf index.txt serial
you stated earlier that you didnt touch
Stephan Manske wrote:
Does this work with specific make commands only? So you cannot use it in
freeradius to be compatible?
It only works with GNU Make. Version 3 has a new build system, which
requires GNU Make. It could be done there.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
20 matches
Mail list logo
