FreeRADIUS 2 with EAP-TLS
-
Dear All,
For a few years, I am using 802.1x with EAP-TLS to secury my WLAN in a two location SOHO situation. Currently, this is based on freeRADIUS on a virtual Centos machine and Lancom access points. However, I would like to move the radius checking to pfSense based on the freeRADIUS2 package, to better integrate with VLANs and to improve some other issues.
Testing with plaintext passwords and radtest, things do work well based on the pfSense package, i.e., I seem to be able to get users, MACs, clients and interfaces right in the pfSense package, basically.
However, things do not work when moving to certificates. I did follow https://doc.pfsense.org/index.php/FreeRADIUS_2.x_package#General_EAP_configuration and the more specific EAP-TLS section below the start of that link. I did generate certificates with the pfSense cert manager – which is consistent with both the recommendation and my aim - and uploaded a client certificate (including key) and the CA certificate to a test device to be connected wirelessly. I am used to building OpenVPN and IPsec-certificates there, so I can handle server and client certificates, CRLs and the like. Unfortunately, EAP-TLS does not work even after a lot of trying. The following challenges did come up:
- System General log contains the following entries upon trying to authenticate:
– radiusd[71184]: –> verify error:num=3:unable to get certificate CRL. That is strange also because I did create a CRL in the cert manager, but it remains to be marked as not in use. Of course, I did choose the cert manager in the freeRADIUS 2 package EAP configuration, leave the private key password empty, did pick the appropriate SSL CA Certificate, SSL Revocation List and SSL Server Certificate.
-- radiusd[71184]: TLS Alert write:fatal:unknown CA
– radiusd[71184]: TLS_accept: error in SSLv3 read client certificate B
– radiusd[71184]: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned. Of course, a user with a name corresponding to the CN of the certificate used does exist in the package configuration
– radiusd[71184]: SSL: SSL_read failed in a system call (-1), TLS session fails.
What further worries me is that while I did choose the cert manager in the package EAP configuration and did leave the private key password empty, the eap.conf file still contains:
– certdir = ${confdir}/certs
-- cadir = ${confdir}/certs
-- private_key_password = whatever
That is what I would have expected if I did NOT check “Choose Cert-Manager”. I would have expected a blank password to correspond with the pfSense certificate manager. However, I cannot generate that configuration. I suspect that the "Private Key Password" setting does not work in line with its description "... The certificates created by the firewall's built-in Cert Manager are not protected so you must leave this field empty." If I do type any value into that field, it gets reflected in the configuration file. If I leave the field empty or if I type just a space, the configuration file reads "private_key_password = whatever". Unless that part of the configuration file is never used, it might be that using the pfSense certificate manager plainly does not work.
Can someone please point me to the right direction?
Regards,
Michael Schefczyk
P.S.: I am using 2.1.4-RELEASE (amd64), Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 16 GB RAM, 0,9 TB HD, freeradius2, 2.1.12_1/2.2.4 pkg v. 1.6.7_3
-
Dear All,
as it turns out, the CRL does not work, when using the pfsense cert manager in freeradius. For further details, please see https://forum.pfsense.org/index.php?topic=43675.msg432323#msg432323.
Regards,
Michael Schefczyk
-
Hey,
I want to confirm the above, I have went through the exact same problem with the exact same errors messages. FreeRadius on PfSense for EAP-TLS + Certmanager = broken. whatever scripts that are program to fire-off when the check boxe for "Choose Cert Manager" are either not working or leaves the underlying configuration a mess. this is really too bad, I was hoping to run my Wireless Enterprise EAP-TLS configuration like this :(.
Update 1/4/2015:
tried the latest version of FreeRadius on Ubuntu server 14.10 64-bit… the problems persist; in hindsite: if you are going to configure Freeradius in a production environment for EAP-TLS WPA2 enterprise it DOES work.. you will however NEVER get the CRL to work and this whole procedure is MUCH faster to configure on Pfsense appliance than Ubuntu any day of the week given how large of a config file the Freeradius application actually is.
if you really need the security or WPA2 Enterprise in a LARGE environment, please look into Active Directory Certificate Services and NAP configuration, I am presuming that it is much more stable at this point in time and the CRL works. I still greatly appreciate the work of the individual who put together Freeradius as it still has plenty of awesome production applications! Thank you!
Update 1/4/2015 2:13PM CST:
found the problem with how Freeradius works with regards to the CRL; the issue is that the Freeradius configuration is in effect incomplete for CRLs, I believe the fix for it shouldn't be as hard as one would believe however:
the below code needs to be changed to yes
check_crl=yes
and the following needs to be done:
The next step is to get FreeRADIUS to find and use the CRL, but if you recall, there were no options to allow you to define where the CRL file lives.
The undocumented thing you need to do is concatenate (join) your CA public key and your CRL into one file, like this:
cat ca.pem mycrl.pem > ca_and_crl.pem
This is the key to making it all work! ca_and_crl.pem now contains both your CA public key and the details of the revoked certificates, in one file. All that remains to be done now is to update eap.conf changing the CA_file line so that it reads CA_file = ${certdir}/ca_and_crl.pem
Make sure you also set check_crl = yes, then restart FreeRADIUS and try connecting with a bad certificate - it should fail, whereas a valid certificate will work.
The main drawbacks to all this however, are:
You must remember to regenerate your combined CA/CRL file each time you revoke a certificate, having a script made to automate this process would be the real fix to make pfsense CRL a real thing, without this functionality administrating it is a nightmare, if there is a way for the web-interface of PfSense to run cat ca.pem mycrl.pem > ca_and_crl.pem after revoking a certificate as well as restarting the radius service all automatically would make this smooth sailing (hopefully).the reason for all this is that you must fully restart FreeRADIUS so the CA/CRL file is reread (generating a new CA/CRL file is not enough - FreeRADIUS/OpenSSL won't reread it)
I do not claim any of the knowledge above as my own, I am simply posting my findings from here: https://sites.google.com/site/techbobbins/home/articles/freeradius-and-crls and then taking the aspects of how the Pfsense firewall could integrate this kind of setup.
thoughts? or is this simply not feasible? it doesn't look too bad.
-
I'm up against this same issue. Has anything changed since the OP?
-
Can someone please tell me if the CRL is still broken in the freeradius package for EAP-TLS authentication???? Please
-
I am running eap-tls with pfsense 2.2.6 x64, freerad2 package 1.6.19 and not having any issues.. Using CA I created on pfsense.
I did a test of revoking a cert once it was using it to install, and worked just as you would expect. I have multiple clients using this. Windows 7 laptops, iphone 5c and 5s, Ipad and android nexus 4 phone.
Biggest roadblock I found was that the CA in pfsense doesn't put a password when you export the certs, and you have to run them through openssl to add a password so can import on apple devices.
I see threads were some stuff doesn't work with windows 10, but not currently using any win 10 clients so have not run into that issue.
You can see in the attached, that in freerad package I have a crl listed..
-
Pfsense 2.2.4 x64 FreeRad2 1.6.19
My CA was created on pfsense with no issues and works fine for VPN and for wifi minus the revoke feature. When I revoke a certificate it shows as revoked and I restart the freeradius service as requested. The wireless client is still able to connect even though the cert is "revoked". The issue is described in detail a few posts above but it requires a lot of manual intervention to workaround the issue. I was able to check the box in the openvpn client export package to password protect the certificate before exporting (that may make your life a little easier instead of using openssl to add a password for apple devices).
So you're saying that you're able to revoke a certificate and after revoking the cert the client can no longer access wireless using the freeradius package, pfsense cert manager, and eap-tls authentication for wireless?
-
An update..
I checked my eap.conf file to confirm what XanALaOM00 stated in a previous post. It does have check_crl = yes, and the ca_cert.pem file does appear to have the CA cert and CRL combined when I view the file. I'm perplexed at why the certs that are being revoked can still authenticate.
-
I found the issue. I had a space in my CRL name that was causing the issue. I re-created the CRL without a space and now I can successfully revoke client certs and they no longer have access. Probably should be sent on to pfsense development to throw an error when some silly user tries to create a CRL with a space in the name. ;D ;D ;D
-
"I was able to check the box in the openvpn client export package to password protect the certificate before exporting"
Not using the same CA as the my vpn CA.. Guess if I was maybe that option would work.. But in the CA when you go to download the ca cert key bundle there is no password on it… Which causes an issue for many clients to install the certs.
-
Thanks for figuring this out. I couldn't get this to work either but managed to sort it out after changing my CRL name to one without any spaces. I also needed to have at least one Revoked Certificate otherwise FreeRadius didn't seem to like just looking at the ca_cert.pem file with just the CA Certificate in it and no CRL data.
-
This is an old thread, and I apologize in advance if solutions have been posted elsewhere…
I have found the workaround solutions above dont quite work, i.e. a change in the radius config (i.e. a user attribute), will cause the radius.conf and the cert files to be overwritten. A little background on my system:
-Free radius v3
-pfsense v2.42 p1Now, i think i may have found a workaround, that is "sticky". It follows the same method as listed in this thread, but instead of appending the CA/CRL in the same file via the CAT command, append the CRL via the pfsense GUI to the CA cert body. This way, every time you reload freeradius, it reads form the PFSENSE Cert files, and now everything works.
Also, i found if you configure sub CA's, free radius has issues with that. So, a work around for that, is to:
-create your root CA
-create sub CA
-create crl for sub ca
-then, "import" a CA. the cert body will be the root->sub->crl
-create free radius server cert
-in free radius, use the "import" CA, and the free radius server cert..i found if you dont do this, free radius will error with error 19, self signed in the chain. Understand the reason to use sub certs is for security, as i understand root CA's are designed to create sub CA's, not user or server certs. This way, if sub CA is copromised, you dont have to recreate cert chain, just that particular sub ca.
I dont claim to be a PKI expert, but the above worked for me.
---note, for revocation to work, you will have to re-paste the CRL info back into the "import" cert, and restart radius. note, that restarting radius via the GUI, i.e services click the restart gear, does not work. I found i needed to make a change to free radius, i.e change a setting in the eap config, save it, then set it back, svae it. this seems to trigger a true radius restart.
hope this helps
-
Still broken, as of now
-
patched by me:
https://github.com/pfsense/FreeBSD-ports/pull/632
With this patch, when you revoke a certificate you need to go to radius config -> eap and "SAVE" to regenerate the CA+CRL file.
Next patch coult be add a funcion similar to openvpn_refresh_crls() that should be called from /usr/local/www/system_crlmanager.php when you update all the other CRLs.
This is my 2nd day on PFSense, so first I need to see if there is a functions file dedicated to components not installed as default and then write the function. Any advice?
