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

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

  • S

    I've been configuring a new Netgate appliance to replace an obsolete model. I'm having an issue with the freeradius package on the new appliance. The old appliance has freeradius 0.15.5_2 on pfsense 2.4.2-RELEASE-p1, while the new is freeradius 0.15.5_5 on pfsense 2.4.4.

    Freeradius is configured to authenticate eap-tls from my wifi clients. The certificates are issued using the pfsense certificate manager.

    Authentication with eap-tls works fine until I enable the ssl revocation list in the 'Certificates for TLS' section of the eap config. If I leave this as 'none', authentication is good. If I chose the CRL I've configured in the cert manager, then all logons fail, even if I have an empty CRL. I've tried recreating the CRL, to no avail.

    The error I get is: 'Login incorrect (Failed retrieving values required to evaluate condition)'

    On the old system I could enable the CRL without having any logon issues. Although, in that case I even people with revoked certs were still allowed on the network, even after I restarted freeradius as the instructions say, so now I'm having the opposite issue, where nobody can logon as long as any CRL exists.

    0
  • LAYER 8 Global Moderator

    I can test this when I get home..

    0
  • LAYER 8 Global Moderator

    Hmmm yeah this looks to be broken.. Have to look into this more.. But clearly something is not right..

    0
  • LAYER 8 Global Moderator

    Ok this came up before here
    https://forum.netgate.com/topic/70749/freeradius-2-with-eap-tls/9

    And that jogged my memory.. From a quick test I don't think the ca and crl are being combined.. When you look in
    /usr/local/etc/raddb/certs

    And you change your freerad to use your crl.. Doesn't look like it adds it to your ca.pem file? Need to look at if further.. But there also seems to be an issue with 2.4.5 and freerad checking cert attributes... I will look to see if crls are working in 2.4.5.. They for sure use to work.. Would have to fire up a copy of 2.4.3 to test - all my systems have been moved to 2.4.4 or 2.4.5

    0
  • LAYER 8 Global Moderator

    Ok... Seems if there is NO certs in the crl it doesn't get added to the pem.. So I created a dummy cert, then added it to the crl.. And now it does get added to the ca_cert.pem file

    0_1540895507175_joined.png

    I am not sure if it has always been this way or not? But should prob be documented somewhere or changed so that CRL gets created even if empty and added to the freerad ca pem files that get created for freerad to use.

    I have to look into who manages the freerad package to discuss..

    0
  • S

    Thanks for checking. To be clear, my issue occurred even with a non-empty CRL. In other words I had a CRL populated with several revoked certs. My own cert was not revoked, but I was unable to logon. As soon as I disabled the CRL in the freeradius settings, I was able to logon. I then tried with the empty CRL and had the same issue.

    0
  • Rebel Alliance Developer Netgate

    I don't see any code in FreeRADIUS that checks to see if the CRL is empty or not.

    If it finds the CRL it puts in the text of the CRL.

    Before you added the dummy cert did your CRL have a text tag in the config with content?

    0
  • LAYER 8 Global Moderator

    What I found jimp was that if the CRL was created but empty everyone failed.. But if you put in a dummy cert that was revoked it worked. When the crl was created but empty it didn't seem to update any info in the pem that there was even a crl..

    0
  • Rebel Alliance Developer Netgate

    Right but what I'm asking is if the config.xml entry for the CRL had a text entry when it was defined but did not have a certificate present.

    0
  • LAYER 8 Global Moderator

    oh didn't check for that.. sorry.

    0
  • LAYER 8 Global Moderator

    @smacdoug but if your crl was empty and didn't update the pem with CRL info - then yeah everyone would fail.. Because it can not find the CRL to even check if your client is in the CRL or not.. If you call for CRL - the pem has to have the CRL added to it - or everyone will fail.

    Here is error that was logged for me, when no CRL in the pem - but crl set to yes

    Oct 30 04:27:07 	radiusd 	81992 	(13) 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
    0
  • LAYER 8 Global Moderator

    So now I told it to not use crl...
    The pem was updated to remove the crl info from it.

    Then deleted the dummy cert that was in the crl. Then reenabled the empty crl and it update the pem show the X509 CRL info..

    0
  • LAYER 8 Global Moderator

    Ok - so I parsed out the x509 crl into its own pem... Then checked it with openssl and you can see no certs listed.. Before this was never added to the ca_cert.pem that freerad uses for the CRL.

    0_1540914885246_crl.png

    0
  • Rebel Alliance Developer Netgate

    Maybe change this bit of code in /usr/local/pkg/freeradius.inc:

    			if ($crl_cert != false) {
				$crl = base64_decode($crl_cert['text']);
				$check_crl = "check_crl = yes";
			} else {
				$check_crl="check_crl = no";
			}

    To this:

    			if (($crl_cert != false) &&
			    !empty($crl_cert['text'])) {
				$crl = base64_decode($crl_cert['text']);
				$check_crl = "check_crl = yes";
			} else {
				$check_crl="check_crl = no";
			}
    0
  • LAYER 8 Global Moderator

    Your the developer ;) Do you need a report of this to implement that? Or can you put it in without a redmine.

    I'm not exactly sure what

    $crl_cert['text']

    Actually does.. Normally that is a part of an array right.. To be honest having a hard time following what exactly you change is doing different. Other then doing some extra check on some variable.

    0
  • Rebel Alliance Developer Netgate

    I just meant to try that change to see if it helps.

    The text is the PEM generated content of the CRL that gets updated when the system updates the CRL, usually when adding or removing a certificate or making another change to the CRL.

    If that text is empty it would explain why you hit the error condition you did.

    0
  • LAYER 8 Global Moderator

    Oh would prob have to start over to try and recreate the problem.. Since its working for me now.. like I said when back to empty crl and its working, etc.

    Maybe the OP can chime in.. It works just fine - even with empty crl it adds the crl to the ca_cert.pem file.

    0
  • S

    While it seems that you guys have it working for yourselves, at least with a blank CRL, my original issue still remains.

    I never cared about blank CRLs, this was only a test I tried to see if a blank CRL would work any better than a populated one. My issue is that when any CRL is enabled, my logon fails, even though my cert is not in the CRL. I've tried deleting and recreating the CRL as well as using just a blank CRL, but the only time I can authenticate is when I leave the CRL setting as none.

    0
  • LAYER 8 Global Moderator

    And you validated your CRL is actually getting added the pem file?

    0
  • S

    There is a: -----BEGIN X509 CRL----- section in ca_crt.pem that appears when I enable the CRL, there is no crl.pem that ever appears.

    0
  • LAYER 8 Global Moderator

    there wont be... Pull out what gets added and look in what is in the CRL... you can do that with the cmd I posted above.

    This works fine for me with either blank crl or crl with different cert revoked - my client that is not listed the crl. When i get home tonight I will revoke my client so that it blocks it... Then remove it from the crl, etc..

    if your crl is getting added, your going to have to look to see what is in there - maybe your blocking your clients cert? Once I got the crl to be added to the ca pem, I have not been able to duplicate your problem.

    0
  • S

    I decoded the CRL and found 17 revoked certs, exactly the number of certs in the CRL displayed in the GUI, none of them were the serial of my cert. I added my cert in and see that it's added the CRL. Then I removed it and restarted freeradius. My cert was still in the revoked list in ca_cert.pem. So I changed the setting to none and back, this removed my cert from ca_cert.pem. In spite of this I still can't logon with my cert unless the CRL is set to none.

    0
  • LAYER 8 Global Moderator

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

    0
  • S

    @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.

    0
  • S

    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.

    0
  • LAYER 8 Global Moderator

    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.

    0
  • S

    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.

    0
  • LAYER 8 Global Moderator

    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?

    0
  • Rebel Alliance Developer Netgate

    Is this on ARM or amd64?

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

    0
  • S

    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?

    0
  • LAYER 8 Global Moderator

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

    0
  • Rebel Alliance Developer Netgate

    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.

    0
  • LAYER 8 Global Moderator

    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.

    0
  • S

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

    0
Log in to reply
 

Products

Applications

Support

Services

News

Resources

Company

Our Mission

As host of the pfSense open source firewall project, Netgate believes in enhancing network connectivity that maintains both security and privacy. We also believe everyone should be able to afford it.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2019 Rubicon Communications, LLC | Privacy Policy