[EMAIL PROTECTED] wrote:
In all cases the server does not initialize, with the error:
rlm_eap: SSL error error::lib(0):func(0):reason(0)
rlm_eap_tls: Error reading Trusted root CA list (null)
rlm_eap: Failed to initialize type tls
sigh You have to love OpenSSL. When the server
On Wed, 19 Mar 2008 07:30:53 +0100, Alan DeKok
[EMAIL PROTECTED] said:
[EMAIL PROTECTED] wrote:
All you need is a server cert and private
key. In PEAP, the client is the one who needs the CA cert, if he wants
to verify the server cert, but even that is optional.
The CA cert is
[EMAIL PROTECTED] wrote:
The first comment might be giving you just another place to provide your
CA cert, whereas the second comment clearly talks about not permiting
EAP-TLS. I say this, because I don't see why the CA would be required at
all if EAP-TLS will be denied.
Because PEAP uses
I'm using FreeRADIUS Version 2.0.2, for host i686-suse-linux-gnu, built
on Feb 14 2008 at 15:20:55
I got back to testing allowing only PEAP-GTC on one virtual server. I
used the included self-signed certs this time, but as I suspected, the
results were the same whenever I comment out CA_file:
It also says:
# 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
It also says:
# 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
It also says:
# 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
[EMAIL PROTECTED] wrote:
Except that my server cert does contain a CA cert. I'm not 100% sure
it's sufficient, because it was issued from an intermediate CA (it needs
to be the signer(s) not the issuer, right?), so I went to another CA got
a webserver cert in pem format directly from the root.
[EMAIL PROTECTED] wrote:
When TLS is empty (i.e. TLS {}):
Huh? Why would you leave it empty?
If you're not going to use TLS, delete the whole section. It's just
like any other module.
When TLS is removed:
rlm_eap: Unable to load EAP-Type/ttls, as EAP-Type/TLS is required
first.
rlm_eap: Unable to load EAP-Type/peap, as EAP-Type/TLS is required
first.
This makes sense, as I'll need my server cert for PEAP. If those certs
have to be defined in the TLS block, what is the right way to disable
TLS in this case, but still have PEAP working?
Don't issue client
[EMAIL PROTECTED] wrote:
I did read that, but I was trying to reject TLS. It also says, If you
do not use client certificates, and you do not want to permit EAP-TLS
authentication, then delete this configuration item, referring to
CA_file. I just want to point out that it appears you can't
[EMAIL PROTECTED] wrote:
I was stuck for a long while. I created two modules, eap_main and
eap_gtc. My server1 and server2 virtual servers referred to each one
respectively. The server would start, but authentication would fail:
auth: type EAP
WARNING: Unknown value specified for Auth-Type.
Pardon the non-threaded replies. I'll have to find a client that works
with the list.
I'm still having trouble with the eap_gtc section, because when I remove
TLS or empty it or try to return reject, the server won't start. Is
removing the section the right way to not support an eap type on
I want to run two virtual servers on different ports, where one server
allows PEAP-MSCHAPV2 and the other doesn't. It seems that only one
eap.conf can be used.
No. You can have multiple instances of the EAP module, just like
anything else:
eap foo {
...
}
eap bar {
...
[EMAIL PROTECTED] wrote:
I want to run two virtual servers on different ports, where one server
allows PEAP-MSCHAPV2 and the other doesn't. It seems that only one
eap.conf can be used.
No. You can have multiple instances of the EAP module, just like
anything else:
eap foo {
...
I want to run two virtual servers on different ports, where one server
allows PEAP-MSCHAPV2 and the other doesn't. It seems that only one
eap.conf can be used. I can see how to separate the Authorize and
Authenticate sections, but I haven't seen any documentation on the
syntax to select or reject
Hi,
I have some doubts about the rules of applying client and listen blocks in
comparison to virtual server setting.
Is it this way that both client and listen blocks can appear in the main
radiusd.conf file so that they will behave
like default global setting for all defined virtual servers??
If
Tomasz Zieleniewski wrote:
I have some doubts about the rules of applying client and listen blocks
in comparison to virtual server setting.
raddb/sites-available/README contains the documentation for that.
Is it this way that both client and listen blocks can appear in the main
18 matches
Mail list logo
