Bug 246058 - Freeradius fails to load the CRL when requested to with OpenSSL libs error 3.
Freeradius fails to load the CRL when requested to with OpenSSL libs error 3.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: freeradius (Show other bugs)
4.0
i386 Linux
low Severity medium
: ---
: ---
Assigned To: John Dennis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-28 03:41 EDT by paolo gaiardelli
Modified: 2012-06-20 12:19 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 12:19:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test case for Bug 246058 (3.84 MB, application/x-bzip)
2007-08-29 07:40 EDT, paolo gaiardelli
no flags Details

  None (edit)
Description paolo gaiardelli 2007-06-28 03:41:45 EDT
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
and
OpenSSL 0.9.7a Feb 19 2003

How reproducible:
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
  
Actual results:
EAP-TLS authentications will fail due to the openssl libs spawning error
3:unable to get certificate CRL. Everything else works.

Expected results:
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.


Additional info:
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
Comment 1 Thomas Woerner 2007-07-16 06:37:27 EDT
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
certificate.

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?
Comment 2 paolo gaiardelli 2007-07-16 07:09:14 EDT
(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
> certificate.
> 
> 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?

Hi,
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.
Bye,
Paolo
Comment 3 Thomas Woerner 2007-07-25 07:32:21 EDT
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?
Comment 4 paolo gaiardelli 2007-07-25 08:38:30 EDT
hi


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.

Comment 5 Thomas Woerner 2007-07-25 09:06:41 EDT
Yes, this is ok for me.
Comment 6 Thomas Woerner 2007-08-23 04:52:09 EDT
Do you have a test case for me, now?
Comment 7 paolo gaiardelli 2007-08-29 07:40:10 EDT
Created attachment 178781 [details]
test case for Bug 246058

this is going to overwrite almost everything in etc/raddb if you unpack it
inside /etc.
other than that nothing else happens when you untar the ball.
There are RPMs inside.
Comment 8 paolo gaiardelli 2007-08-29 07:42:32 EDT
(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.

README contents:

hi

here you can find a copy of the /etc/raddb directory along with the involved rpms.


NOTES:

- 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'


USAGE:

- 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:
network={
        key_mgmt=IEEE8021X
    eap=TLS
        identity="daffy"
       #password="a"
        private_key="/tmp/downloads/client1.p12"
        ca_cert="/tmp/downloads/testroot.pem"
        private_key_passwd="whatever"
        #private_key_passwd=""
}

- eapol_test command line: ./eapol_test -a44.128.5.253 -s radius -c
eapol_test.conf -n
of course the IP has to be replaced.


- For any questions/problems, I'm available.


Comment 9 Red Hat Bugzilla 2007-09-17 01:16:08 EDT
transferred from Thomas Woerner to John Dennis, requested by Steve Grubb.
Comment 10 Jiri Pallich 2012-06-20 12:19:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.