Bug 514323 - freeradius wants restart/reload on a renewal of CRL.
Summary: freeradius wants restart/reload on a renewal of CRL.
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: 12
Hardware: All
OS: Linux
urgent
high
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-28 20:49 UTC by Michael
Modified: 2010-11-04 12:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-04 10:45:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michael 2009-07-28 20:49:49 UTC
Description of problem:
radiusd does not watch for a renewal of CRL.
I have to restart/reload it to actualise new CRL.
The problem is with the EAP-TLS type and "check_crl = yes" in eap.conf.

Version-Release number of selected component (if applicable):
freeradius-2.1.6-2.fc10.i386

How reproducible:
Constantly.

Steps to Reproduce:
(The steps are with hostapd in mind for example.)

1. Provide new CRL:

[root@ex certs]# mv crl.pem crl.pem.save
[root@ex certs]# mv crl.pem.new crl.pem

Without restarting/reloading freeradius uses old CRL still:

[root@ex certs]# hostapd_cli -i eth0 new_sta 00:0c:29:6a:dd:a0
OK
[root@ex certs]# 

==> /var/log/radius/radius.log <==
Tue Jul 28 21:58:02 2009 : Error: --> verify error:num=12:CRL has expired 
Tue Jul 28 21:58:02 2009 : Error: TLS Alert write:fatal:certificate expired 
Tue Jul 28 21:58:02 2009 : Error:     TLS_accept:error in SSLv3 read client certificate B 
Tue Jul 28 21:58:02 2009 : Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Tue Jul 28 21:58:02 2009 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails.
Tue Jul 28 21:58:02 2009 : Auth: Login incorrect: [24/<via Auth-Type = EAP>] (from client localhost port 0 cli 00-0C-29-6A-DD-A0)

==> /var/log/messages <==
Jul 28 21:58:03 ex hostapd: eth0: STA 00:0c:29:6a:dd:a0 IEEE 802.1X: authentication failed - EAP type: 13 (TLS)

Well. The problem is reproduced in the first step actually.


2. When I restart freeradius it gets new CRL:

[root@ex certs]# service radiusd restart
Stopping RADIUS server:                                    [  OK  ]
Starting RADIUS server:                                    [  OK  ]
[root@ex certs]# 
[root@ex certs]# service hostapd restart
Stopping hostapd:                                          [  OK  ]
Starting hostapd: Configuration file: /etc/hostapd.conf
ctrl_interface_group=0
eapol_version=2
.....................................

==> /var/log/radius/radius.log <==
Tue Jul 28 22:04:04 2009 : Info: Exiting normally.
Tue Jul 28 22:04:07 2009 : Info: Loaded virtual server inner-tunnel
Tue Jul 28 22:04:07 2009 : Info: Loaded virtual server <default>
Tue Jul 28 22:04:07 2009 : Info: Ready to process requests.

==> /var/log/messages <==
Jul 28 22:04:11 ex hostapd: eth0: RADIUS Authentication server 127.0.0.1:1812


3. Then everything works well:

[root@ex certs]# hostapd_cli -i eth0 new_sta 00:0c:29:6a:dd:a0
OK
[root@ex certs]# 

==> /var/log/radius/radius.log <==
Tue Jul 28 22:04:17 2009 : Auth: Login OK: [24] (from client localhost port 0 cli 00-0C-29-6A-DD-A0)

==> /var/log/messages <==
Jul 28 22:04:17 ex hostapd: eth0: STA 00:0c:29:6a:dd:a0 RADIUS: starting accounting session 4A6F3D9B-00000000
Jul 28 22:04:17 ex hostapd: eth0: STA 00:0c:29:6a:dd:a0 IEEE 802.1X: authenticated - EAP type: 13 (TLS)


  
Actual results:

==> /var/log/radius/radius.log <==
Tue Jul 28 21:58:02 2009 : Error: --> verify error:num=12:CRL has expired 
Tue Jul 28 21:58:02 2009 : Error: TLS Alert write:fatal:certificate expired 
Tue Jul 28 21:58:02 2009 : Error:     TLS_accept:error in SSLv3 read client certificate B 


Expected results:

==> /var/log/radius/radius.log <==
Tue Jul 28 22:04:17 2009 : Auth: Login OK: [24] (from client localhost port 0 cli 00-0C-29-6A-DD-A0)


Additional info:
Well. While it doesn't look like a bug but freeradius should even must watch CRL to make things smooth.

Comment 1 John Dennis 2009-07-28 21:36:52 UTC
I'm familiar with this problem. This isn't a freeradius issue to the best of my knowledge rather it's an OpenSSL issue. I recall some versions of OpenSSL either had a bug that prevented the CRL from being reread or the functionality to reread the CRL was added to a specific version of OpenSSL. I did a quick search but I didn't find specific references to this OpenSSL issue or I would have added it here. I'm reassigning this bug to openssl for the time being, perhaps the openssl maintainer has more information and can shed some light on this.

In the interim, why don't you just do a 'service radiusd restart' after you update the CRL.

Comment 2 Tomas Mraz 2009-07-28 21:53:59 UTC
This might be fixed in openssl-1.0.0 as this version should support CRL reload. I will be able to get it into Fedora 12 hopefully.

For the Fedora 10 you'll have to restart the server as John suggests.

Comment 3 Michael 2009-07-28 22:37:32 UTC
(In reply to comment #1)
> In the interim, why don't you just do a 'service radiusd restart' after you
> update the CRL.  

That's exactly why I've posted the bug. The solution is not smooth. I'd like to keep the process untouched. Well, you know.

(In reply to comment #2)
Well. That's the answer.

Comment 4 John Dennis 2009-07-28 22:51:10 UTC
This is not freeradius's responsibility, it's the responsibility of openssl. We're not adding code to freeradius to check if the crl was modified. Even if we did discover the crl was updated I don't know how we would get openssl to reread the crl file without restarting things, so that would put us back where we started.

Tomas, just out of curiosity does openssl even have an API that forces a CRL reload? My understanding was the CRL reload was supposed to be automatic and "under the covers".

Comment 5 Bug Zapper 2009-11-16 11:09:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Tomas Mraz 2010-05-18 12:44:02 UTC
Have you tried Fedora 12 or newer? It is possible that the issue is fixed by updating openssl to 1.0.0 as of these Fedora releases.

Comment 7 aland 2010-09-22 14:43:39 UTC
OpenSSL 1.0.0 still does not have this functionality.

FreeRADIUS will get it automatically when OpenSSL adds it.

Comment 8 Bug Zapper 2010-11-04 10:39:55 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Tomas Mraz 2010-11-04 10:45:49 UTC
As this has to be implemented upstream first closing.

Comment 10 aland 2010-11-04 12:37:38 UTC
FreeRADIUS 2.1.10 supports dynamic certificate checking by writing the cert to a temporary file,
and then running "openssl verify" on it.

That functionality can be used to implement dynamic CRLs.


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