Description of problem:
when using EAP-TLS, the flag "check_crl = yes" in eap.conf won't work.
the version of freeradius shipped with Red Hat AS4 fails to load the CRL
(Certificate Revocation List) due to an error triggered in the openssl libs.
Version-Release number of selected component (if applicable):
FreeRADIUS Version 1.0.1, for host , built on Apr 25 2007 at 08:19:46
OpenSSL 0.9.7a Feb 19 2003
Always, just setup EAP-TLS with check_crl = yes and try to authenticate.
Steps to Reproduce:
1. Get a valid CA certificate and a valid CRL issued by that CA, also get two
certificates with the TLS client and server authentication extended key usages.
2. set eap.conf properly, set the users file properly, allow eap in radiusd.conf
3. the CA and CRL go in the same file, in PEM format
4. set te clients.conf properly
5. configure eapol_test with check_crl = yes and test EAP-TLS against radiusd -X
EAP-TLS authentications will fail due to the openssl libs spawning error
3:unable to get certificate CRL. Everything else works.
The CRL should be loaded, the supplied client certificate should be checked
against it and either accepted or rejected.
This is a bug strictly related to the openssl libs. Compiling a different
freeradius source, even the most recent stable freeradius version, 1.1.6,
against the OpenSSL 0.9.7a libs gives the same error.
CRLs are currently unusable with the freeradius + openssl libs available under
RHEL4 and Red Hat AS4.
Even compiling freeradius 1.1.6 from source won't solve the problem unless you
compile it against a different openssl version installed in /usr/local
I have been tested freeradius with a CA hierarchy and CRL lists last year and it
is working as long as the child also has the whole CA hierarchy and the issuing
There might be a change in newer openssl libararies, therefore:
Have you tried to use the openssl library from /usr/local with the freeradius
version from the RHEL-4 RPM? Is this working?
(In reply to comment #1)
> I have been tested freeradius with a CA hierarchy and CRL lists last year and it
> is working as long as the child also has the whole CA hierarchy and the issuing
> There might be a change in newer openssl libararies, therefore:
> Have you tried to use the openssl library from /usr/local with the freeradius
> version from the RHEL-4 RPM? Is this working?
if you mean using alternate openssl libraries compiled from the latest stable
sources and installed in /usr/local, the answer is yes. The freeradius RHEL-4
RPM sources compiled against these libs do load the CRL correctly.
If , on the other hand, you mean there is an official alternate openssl rpm that
installs in /usr/local, then I'm not aware of it.
I also seem to have evidence that a previous official freeradius version was
loading the CRL correctly: I asked somebody who was working in place of me last
year and he confirms it. No further data regarding that, tho.
If there's something else you want me to do, I'm available, anytime.
Even with the actual freeradius and openssl packages I can not reproduce your
problem. I am using a CA hierarchy and it is working as expected.
Can you please build a small reproducer?
sure. It is going to take a few days, but I can attach a tarball with a set of
original rpms (freeradius + openssl) + configuration files + additional info /
logs, if this is ok for you.
Yes, this is ok for me.
Do you have a test case for me, now?
Created attachment 178781 [details]
test case for Bug 246058
this is going to overwrite almost everything in etc/raddb if you unpack it
other than that nothing else happens when you untar the ball.
There are RPMs inside.
(In reply to comment #6)
> Do you have a test case for me, now?
hi, my apologies for the exceedingly long wait, here's a tarbz2ball (previous
comment). You can find a raddb directory with a README, conf files, rpms, a CA
with certs and key pairs on the inside.
here you can find a copy of the /etc/raddb directory along with the involved rpms.
- the /etc/raddb/certs/crl directory contains a crl, a CA cert (with a copy of
the crl on its tail), a server cert / key pair, and the client1.p12 file you can
use with eapol_test (from the wpa_supplicant package, make eapol_test to make
it) to reproduce the the problem.
- /etc/raddb/certs/ca contains the CA structure. It's not really needed now.
- clients.conf and huntgroups has to be modified for the right IP to use..
- for everything CA related the password is 'whatever'
- the client1.p12 identity is 'daffy'
- install the rpms, untar the ball in the right place, compile eapol_test, run a
test with EAP TLS authentication.
- if you comment check_crl = yes in eap.conf, the authentication works, with an
uncommented check_crl = yes line, it fails.
- eapol_test.conf config file:
- eapol_test command line: ./eapol_test -a184.108.40.206 -s radius -c
of course the IP has to be replaced.
- For any questions/problems, I'm available.
transferred from Thomas Woerner to John Dennis, requested by Steve Grubb.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.