All freeradius eap-tls authentications fail when an SSL revocation list is enabled

johnpoz

Are you actually restarting freerad when you change the certs listed in your crl?

I can not duplicate this

Nov 3 06:02:04 	radiusd 	29895 	(7) Login OK: [j-iphone] (from client uap-pro port 0 cli D0-C5-F3-1F-EB-FF) 192.168.2.2 

Nov 3 06:08:08 	radiusd 	78645 	(27) Login incorrect (Failed retrieving values required to evaluate condition): [j-iphone/<via Auth-Type = eap>] (from client uap-pro port 0 cli D0-C5-F3-1F-EB-FF) 192.168.2.2 

Nov 3 06:12:49 	radiusd 	95969 	(7) Login OK: [j-iphone] (from client uap-pro port 0 cli D0-C5-F3-1F-EB-FF) 192.168.2.2

Not in the CRL... login fine, put client in the CRL - blocked!! Pull his cert out of CRL fine..

strangegopher

@smacdoug why don't u remove all the certs involving freeradius and remove freeradius, reboot pfsense, and then install freeradius again. It will generate new default certs that you can use or remove and create your own certs.

smacdoug

I'm restarting the freeradius server using the Status-Services and clicking on the restart icon for radiusd.

In terms of deleting all my certs ans rebuilding from scratch, I'd prefer not if I can avoid it. Freeradius is authenticating all my WiFi users. They're all working fine as long as I don't enable a CRL. Creating all new certs to distribute to all my clients is something I'd prefer not to do.

johnpoz

And your seeing it restart in the log?

I have tried to duplicate this.. Other than the problems I had with it not adding the CRL at all, which fixed once I put in a cert.. I am not having any issues with this..

Maybe if you run it in debug mode you can get more info to figure out where the problem is.

smacdoug

Ok. When I do that I see this in the log which looks relevant:

eap_tls: ERROR: SSL says error 12 : CRL has expired

Since this is a new CRL I'm not sure why it thinks it's expired already. If I run your openssl command I see this:

Last Update: Oct 30 14:47:34 2018 GMT
Next Update: Feb 8 08:19:18 2010 GMT

Which doesn't seem to make sense.

johnpoz

No sure doesn't so yeah that would explain the issue..

Just create a new one.. How many days are you putting in for lifetime... Are you importing or creating?

jimp

Is this on ARM or amd64?

Maybe it's hitting a 32-bit rollover in UNIX timestamps at 2038.

smacdoug

It's ARM (Netgate SG-3100)

If I change the default lifetime from 9999 to 3650, I get a correct expiry of 10 years in the future, if I double that to 7300, I get September 2002.

If I leave it at 10 years, the my radius authentications work.

Us this rollover something that can be addressed in a pfsense update?

johnpoz

I have a sg3100... Let me give it a try.

jimp

I can look into adjusting the defaults on ARM, or for everyone: https://redmine.pfsense.org/issues/9098

Curious that it didn't happen on 2.4.3, but we did change to a pure PHP CRL library on 2.4.4. We had been using a PHP openssl module patch before.

johnpoz

Yeah that is odd - good catch though! Took us long enough ;) hehe But found the problem finally..

Yup just validated on my 3100 does the same thing... But doesn't do it on my sg4860.

smacdoug

Thanks for all the help pointing me in the right direction. I'll keep my list at 10 years for now.