Radius service must be restarted after CRL is renewed

[cdpearce]

As reported in this forum thread:
https://www.zeroshell.org/forum/viewtopic.php?t=1325

If CRL (Certificate Revocation List) checking is enabled, then when the CRL expires and gets renewed the RADIUS service does not reload the CRL. This causes authentications to start to fail because the CRL being used by RADIUS is no longer valid. The workaround is to disable and then enable the RADIUS service. But, this has to be done monthly, which appears to be the frequency with which the CRL gets renewed.

I think the RADIUS service needs to be stopped and restarted automatically when the CRL gets renewed.

This is an issue with 2.0RC1. I have not yet upgraded to 2.0RC2. Has this bug been fixed already in that version?

[cdpearce]

I have now upgraded to 2.0RC2, and a month has passed, which means the CRL has expired once. I did not see a recurrence of the failure. So, either the bug is fixed in 2.0RC2 or else the failure is intermittent. I’ll assume the bug is fixed, but I’ll report back again if it returns.

[cdpearce]

Sadly, I was too hasty. The Certificate Revocation List got renewed again, and RADIUS stopped authenticating. The “Stop+Start RADIUS” procedure worked again. But, clearly the underlying problem still exists in 2.0RC2.

[cdpearce]

Unfortunately the bug is still in 3.0.0

[garfield]

and also into 3.9.0
My first impression is, that you must check the timestamp from …/radiusd.pid against CRL last update via cron job.

The Conditions must be:
• RADIUS is enabled (see also on /DB/_DB.001/var/register/system/radius/Enabled)
• CRL check into RADIUS is enabled (see also on /DB/_DB.001/var/register/system/radius/CheckCRL:
  check_crl = yes)
• Timestamp from CRL last update field must be older than timestamp from radiusd.pid file

a workaround for this problem is to write a monitor script NAME=”CFGRELOAD”, SYSTEM=RADIUS, Processing=”One Time Schedule” where you implement this function.

best regards

[Author]

Posts