Skip to main content

Setting up WPA2-Enterprise + AES with Ubuntu 12.04.2 + FreeRADIUS with EAP-TLS only (The Definitive Guide)

After spending a LOT of time researching, waiting, more researching, and almost giving up on WiFi, I've finally figured out a secure enough WiFi setup that I think has a pretty good chance of standing up to scrutiny. It is called EAP-TLS and it is serious Kung Fu (aka REAL security). Unfortunately, to implement said Kung Fu, the protocol requires a RADIUS server. And, to get said RADIUS server at an affordable price, FreeRADIUS is needed and therefore Linux is necessary. And the easiest Linux to use is (usually) Ubuntu. But, after scouring the Internets, I've also determined that there are NO good tutorials on setting up a basic FreeRADIUS EAP-TLS system at home under Ubuntu 12.04.2 using the apt-get packages for FreeRADIUS. This, therefore, is the definitive guide mostly cobbled together from a number of different sources.

I'm assuming a half-decent understanding of Linux command-line editing, a fresh installation of Ubuntu Server 12.04.2 LTS on a computer on the network where it will reside (usually plugged into the upstream router), an el-cheapo router with WPA2-Enterprise AES support (some "consumer grade" routers have this baked in), and a willingness to follow directions. If you really want this to work without hassle, I recommend getting an el-cheapo DD-WRT capable router from Newegg and loading DD-WRT onto it (you'll only be out $25). DD-WRT implements RADIUS correctly and the authors actually test it, which is kind of critical. Without further ado...

Make the Ubuntu box have a static IP address instead of being issued via DHCP. Run 'ifconfig' and 'route -n' to obtain the current network setup. Then edit '/etc/network/interfaces':

# The primary network interface
auto eth0
iface eth0 inet dhcp
To become something like:

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.15
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameservers 192.168.1.1
Your IP address information will be different and based on your 'ifconfig' and 'route -n' output. Be sure to fire up the router admin and locate where to reserve the Ubuntu box's IP address so DHCP doesn't hand it out to some other device on the network in the future and cause havoc. (Or just change the server IP to something else outside the DHCP address range but still in the same subnet - less fuss.)

Next, install FreeRADIUS on the Ubuntu box:

apt-get install freeradius
Next, back up all the files in the /etc/freeradius/ directory in case something goes wrong (makes it easy to restore stuff). The next steps have to more or less be completed before the server will be ready for use, so the ability to completely revert to the original config files is nice.

Next, disable proxies in '/etc/freeradius/radiusd.conf':

proxy_requests  = no
#$INCLUDE proxy.conf
And optionally comment out the "accounting port" in the same file ('/etc/freeradius/radiusd.conf'):

#  This second "listen" section is for listening on the accounting
#  port, too.
#
#listen {
#       ipaddr = *
##      ipv6addr = ::
#       port = 0
#       type = acct
##      interface = eth0
##      clients = per_socket_clients
#}
That closes at least one open port on the FreeRADIUS server that isn't usually necessary, especially for smaller networks.

Next, disable the default client in '/etc/freeradius/clients.conf':

#client localhost {
#       ipaddr = 127.0.0.1
#       secret          = testing123
#       require_message_authenticator = no
#       nastype     = other     # localhost isn't usually a NAS...
#}
Set up a new client in '/etc/freeradius/clients.conf':

client your_router_name {
       ipaddr = your_routers_ip_address
       secret = random_string
       require_message_authenticator = yes
}
The client entry is really custom for your environment and you can have more than one. The IP address, within the average home network, is the gateway IP address of the Ubuntu box. See the default client that was just commented out for details on various options. For 'secret' and other strings that should be random, use a good tool or the Random.org random string generator. Note that your router might have hard character limits (e.g. 32 bytes) while FreeRADIUS will accept just about anything.

Next, edit '/etc/freeradius/eap.conf'. Comment out all subsections inside the 'eap' block except for 'tls'. The following lines need to be changed from this:

eap {
  default_eap_type = md5
  # Supported EAP-types
  md5 {
  }
  leap {
  }
  gtc {
  }
  ttls {
  ...
  }
  peap {
  }
  tls {
    cipher_list = "DEFAULT"
    make_cert_command = "${certdir}/bootstrap"
    verify {
#      tmpdir = /tmp/radiusd
#      client = "/usr/bin/openssl verify -CApath ${..CA_path} %{TLS-Client-Cert-Filename}"
    }
  }
  mschapv2 {
  }
}
Into something more like this:

eap {
  default_eap_type = tls
  # Supported EAP-types
#  md5 {
#  }
#  leap {
#  }
#  gtc {
#  }
#  ttls {
#  ...
#  }
#  peap {
#  }
  tls {
    cipher_list = "HIGH"
#    make_cert_command = "${certdir}/bootstrap"
    verify {
      tmpdir = /var/tmp/radiusd
      client = "/usr/bin/openssl verify -CApath ${..CA_path} %{TLS-Client-Cert-Filename}"
    }
  }
#  mschapv2 {
#  }
}
Options not mentioned are to be left alone (except new protocols). The CA private key password will be used later when the CA is set up. The above mostly just disables EAP-MD5, LEAP, EAP-GTC, EAP-TTLS, PEAP, and EAP-MSCHAPv2 (all of those are broken, weak, a bad idea, or a combination of those words), commenting out the bootstrap line (as documented in the config), and setting the allowed ciphers to something rational/sane. Only EAP-TLS is truly secure and all major OSes (including Windows) support it.

Next, create '/var/tmp/radiusd' as root:

mkdir /var/tmp/radiusd
chown freerad /var/tmp/radiusd
chgrp freerad /var/tmp/radiusd
chmod 700 /var/tmp/radiusd
Next, disable the default virtual servers:

cd /etc/freeradius/sites-enabled/
rm *
Next, copy the 'default' virtual server and edit the new file (change 'your_ap_name' to the router's SSID or something similar):

cd /etc/freeradius/sites-available/
cp default your_ap_name_default
vim your_ap_name_default
In the new file, comment out everything except 'preprocess', 'eap', 'expiration', and 'logintime' from the 'authorize' section. Comment out everything but 'eap' from the 'authenticate' section. Comment or delete the 'accounting' sections if you commented out the accounting port earlier.

Next, enable the new default file:

cd /etc/freeradius/sites-enabled/
ln -s ../sites-available/your_ap_name_default your_ap_name_default
Next, stop the currently running FreeRADIUS server and run FreeRADIUS in debug mode:

/etc/init.d/freeradius stop
freeradius -X
If all goes well, you should have an enabled EAP-TLS only FreeRADIUS installation with just port 1812 open, a client that is your router (access point), and the sentence "Ready to process requests" on the screen. If you get an error message, then try to fix it (paste error messages into Google searches). Once it works, press Ctrl-C to exit the server. At this point, you can breathe a sigh of relief because the only thing left is to generate SSL certificates.

Next, if you don't have it installed, install 'make':

apt-get install make
Next, remove the default certificates:

cd /etc/freeradius/certs/
rm *.pem
rm *.key
Next, copy the tools to set up FreeRADIUS certificates to a reasonable directory:

mkdir /var/certs
mkdir /var/certs/freeradius
chgrp ssl-cert /var/certs/freeradius
chmod 710 /var/certs/freeradius
cp /usr/share/doc/freeradius/examples/certs/* /var/certs/freeradius/
cd /var/certs/freeradius/
rm bootstrap
chmod 600 *
Next, clean up any previous attempts and initialize the required baseline files:

make destroycerts
make index.txt
make serial
Next, edit 'ca.cnf' and set various options to your heart's content. At the very least, change: 'md5' to 'sha1', up the 'default_bits' from 2048 to at most 4096, and 'default_days' to something longer than 365 days (unless you want to change all certificates every year). (I tried 8192 for 'default_bits', but, even though the year is 2013, I ran into TLS handshake issues - rebuilding all the certs and using 4096 bits fixed the handshake problems.) Keep various text strings anonymous. Change 'output_password' to a random string ('input_password' does not appear to be used by the Makefile but it doesn't hurt to make both passwords the same). You can always recreate the CA later if you don't like some setting.

Next, generate 'ca.pem':

make ca.pem
make ca.der
make printca
If you get an error while generating 'ca.pem', there are a number of things that could have gone wrong, but it is generally best to start over with the 'make destroycerts' command, edit 'ca.cnf' after searching Google for hints, and try again. The last command lets you confirm that the CA cert contains the information you want at the strength you want.

Next, edit 'server.cnf' and repeat the editing process.

Next, generate 'server.pem':

make server.pem
Next, edit 'client.cnf' and repeat the editing process. But this time only issue the client a cert for the default 365 days and emailAddress and commonName should be the e-mail address of the user who will use it. (If you don't want to use e-mail addresses, edit 'Makefile' and locate the 'USER_NAME' field and change " | grep '@'" to " | grep -v optional" or all files will end up named '.pem'). The official README says to use an e-mail address, but it can be anything that can also be a valid filename. Note that the user is going to have to manually enter the password used in 'output_password' to add the certificate to their certificate store. Best to keep it simple.

Actually, edit the 'Makefile' anyway (vim Makefile). Locate:

client.p12: client.crt
  openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12  -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)

client.pem: client.p12
  openssl pkcs12 -in client.p12 -out client.pem -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
  cp client.pem $(USER_NAME).pem
Change it to:

client.p12: client.crt
  openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12  -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
  cp client.p12 $(USER_NAME).p12

client.pem: client.p12
  openssl pkcs12 -in client.p12 -out client.pem -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
  cp client.pem $(USER_NAME).pem

client_android.p12: client.crt
  openssl pkcs12 -export -in client.crt -inkey client.key -certfile ca.pem -name "$(USER_NAME)" -out client_android.p12  -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
  cp client_android.p12 $(USER_NAME)_android.p12
Make sure indented lines are 'tabs' and not 'spaces'. This copies the PKCS#12 file too (why should PEM files have all the fun), which is necessary for some OSes and adds a special case for Android, which bundles the CA certificate with the PKCS#12 file and gives it a "friendly name". Next, generate the client certificate, private key, and everything else needed:

make client.pem
make client_android.p12
You can generate as many client certificates as you need. Just open the 'client.cnf' file up and edit a few things before running the above 'make' commands. If you plan on generating lots of certs, you might want to write a script to do the editing and generating.

Assuming everything has gone well to this point, you now have Ubuntu 12.04.2 + FreeRADIUS + EAP-TLS only (with "HIGH" ciphers) and a brand new certificate authority, a server certificate, and a client certificate. But the latter aren't connected (yet). Time to put on the finishing touches:

chmod 600 *
chmod 640 ca.pem
chmod 640 server.pem
chmod 640 server.key
chgrp ssl-cert ca.pem
chgrp ssl-cert server.pem
chgrp ssl-cert server.key
cd /etc/freeradius/certs/
ln -s /var/certs/freeradius/ca.pem ca.pem
ln -s /var/certs/freeradius/server.pem server.pem
ln -s /var/certs/freeradius/server.key server.key
cd /etc/freeradius/
vim eap.conf
Note that you should run the first four lines after generating each client SSL certificate. OpenSSL likes to 'chmod' files as 644.

Locate the line in 'eap.conf' containing 'private_key_password'. This should be changed from "whatever" to the value of 'output_password' from '/var/certs/freeradius/server.cnf'. Save and close. Run 'freeradius -X' and make sure everything still works. Again, Google is your friend for resolving issues.

At this point, the Ubuntu FreeRADIUS server is set up. Come on, it wasn't THAT bad (plus I did all the digging around the configs for you). The only missing piece is your router configuration. Each router is different, but dig around the settings for a while to locate a way to switch to WPA2-Enterprise + AES (don't use Wifi Protected Setup or WPS or whatever "automatic configuration" setup your router offers). A few extra fields will show up. Plug in your Ubuntu server's static IP address and the shared secret from '/etc/freeradius/clients.conf'.

Hooray! The router and RADIUS parts are done. Time to move onto the first client. Fire up 'freeradius -X' during testing so you can debug issues more easily. Extract the client certificate (the .p12 and .pem files) from the server as well as the 'ca.der' and 'ca.pem' certificates. Install the CA cert on the client. Then install the client certificate. This might take some trial and error depending on all sorts of factors - you might have to rename the file extension to get the OS to recognize the certificates. Searching Google for "[OS name] install certificate" usually turns up relevant results. However, there are "recipes" below that you might want to try (and if you come up with a good client recipe, write it down in the comments). After that, try to connect to the WiFi router using the newly installed certificate. Both errors and successful connections will show up in the FreeRADIUS output. However, once it works, you've got the most secure WiFi on the block!

Once you are satisfied with the setup, you can terminate the command-line debug mode and do the '/etc/init.d/freeradius start' thing so that FreeRADIUS runs as a background service.

Recipes

For Windows: Use 'ca.der' and '(name).p12'. Double-click the 'ca.der' file. Click "Install Certificate..." Click "Next". Select "Place all certificates in the following store" and select "Trusted Root Certification Authorities" from the dialog. Click "Next". Click "Finish". A dialog will appear warning about the certificate, click "Yes". A dialog saying "The import was successful" will appear. Click "OK". Double-click on the '(name).p12' file. Click "Next". Click "Next". Enter the password. Click "Next". Click "Next". Click "Finish". A dialog saying "The import was successful" will appear. Next, add the WiFi network manually for WPA2-Enterprise + AES and then somewhere in the settings for the connection is an option for "Network authentication method" that defaults to PEAP. Change it to "Smart Card or other certificate". Open the "Settings" dialog. Use the "Use a certificate on this computer" option and the "Use simple certificate selection (Recommended)" option. Check the imported CA cert in the "Trusted Root Certification Authorities" box. Click "OK". Now it is possible to try to connect normally. If all goes well, the connection will be established.

For Linux (Ubuntu GUI): Use 'ca.pem' and '(name).p12'. The GUI acts a little weird because it first asks for the client public key under the WPA2 Enterprise + TLS setup. Skip that field. The 'ca.pem' file goes into the CA certificate field. Put the '(name).p12' into the private key field and type in the password. The 'Connect' button becomes available when the correct information is in the right fields.

For Android: Use '(name)_android.p12'. First get the certificate on the device by putting the certificate in the root directory of the SD card. Then, go into Settings -> Security -> Credential Storage -> Install from storage. Enter the password. A dialog will appear offering to install three things (CA public cert, client public cert, and client private key). Next go into WiFi settings and connect to the network using 802.1x EAP, the EAP method as TLS, no Phase 2 auth, use the same certificate for both CA and user certificates (will probably be the only option in the dropdown), supply the same string for the Identity and Anonymous Identity you want the device to use, and don't use a password.

Troubleshooting

If you need help, offer a geek/nerd a free dinner in exchange for their help.

Connecting just two devices together flawlessly is apparently too difficult for the software/hardware industry to figure out most of the time (and they like to abuse the "finger of blame" rather than fix the problems that exist). So imagine the complexity of three devices: Your computer/tablet/phone (multiple OSes) + your router (multiple OS flavors of varying levels of quality of feature support) + your Ubuntu box (with FreeRADIUS having a zillion configuration options). When something goes wrong, it will go spectacularly wrong and be nearly impossible to diagnose. A connection that constantly drops could be bad hardware, too many WiFi devices in range on the same channel, and a zillion other factors. Or, in my case, my first router simply couldn't handle RADIUS packets correctly - out of hundreds and hundreds of attempts by the client, it only passed along packets to the Ubuntu box maybe three times which sent FreeRADIUS into fits and spasms of "got connection, dropping connection, got connection, dropping connection, error, got connection, error, error, error". I have no idea what it was doing wrong. I found a cheap $25 router that supported DD-WRT, put DD-WRT on it, and FreeRADIUS was MUCH more reliable. Only then was I able to diagnose that the issue was with using 8192 bit certificates.

The point is that this stuff is (unnecessarily) complicated to debug. You need to have friends who are serious nerds and/or be one yourself should you run into issues and the fact is, even though this guide exists to get a specific setup working, there's a pretty good chance it won't work at all. So you have to be serious about getting this to work. If you need a nerd's help, make them a meal. Free food is decent compensation, especially if they are the slightest bit interested in a crazy EAP-TLS installation.

References:

http://www.area536.com/projects/the-toughest-wifi-on-the-block/
http://linuxtechtutorials.blogspot.com/2011/10/installing-freeradius-on-ubuntu-1110.html
http://blog.wains.be/2009/09/13/wpa2-freeradius-eap-tls/
http://www.privacywonk.net/2010/10/security-how-to-wpa2-enterprise-on-your-home-network.php
http://www.ibm.com/developerworks/library/l-wifiencrypthostapd/
http://technet.microsoft.com/en-us/network/cc917480
http://support.google.com/android/bin/answer.py?hl=en&answer=1649774
http://blog.wains.be/2011/03/13/importing-certificates-on-android-ca-and-client/
(Plus tons of digging around the configuration files for myself.)

Other thoughts: This makes for a nice multi-weekend project. Some people do woodworking on weekends. Others wrestle with Linux.

Comments

  1. Thanks a lot for such a detailed documentation. Please share configurations for other EAP securities like PEAP, LEAP, TTLS, "FAST". Thanks in advance.

    ReplyDelete
    Replies
    1. I'm not going to do that. As stated at the beginning, only EAP-TLS is secure. I also specifically went out of my way to lock out the other protocols you mention because I deem those protocols to be broken, weak, a bad idea, or some combination of those words.

      Delete
    2. How can I revoke a certificate? I followed this tutorial, It helped me a lot, but I really need to test a revoke certificate...

      Delete
    3. @Tatis - I haven't messed around a lot with certificate revocation. Looks like a lot of people who use EAP-TLS run into problems with FreeRADIUS + CRLs. A quick Google search turned up:

      https://sites.google.com/site/techbobbins/home/articles/freeradius-and-crls

      Which has a promising set of steps. As a side note, it is also my personal experience that the FreeRADIUS mailing list is *VERY* unhelpful.

      Anyway, the key seems to be to combine your CA with your CRL into a single file (a new file) and then point FreeRADIUS at the new file, set 'check_crl' to 'yes', and restart FreeRADIUS. Note that FreeRADIUS requires a restart rather than HUP to read new CRL entries. Given what I know about both FreeRADIUS and OpenSSL, the FreeRADIUS restart requirement is probably some issue with how OpenSSL works (that or laziness).

      Delete
  2. Hi, I did your tutorial and put up my freeradius server, and now I want to make a CRL, do you have any idea on how to accomplish this??

    Thanks

    ReplyDelete
    Replies
    1. Since the tutorial uses the built-in OpenSSL CA commands to create the CA, the CRL is going to be created the same way. A quick Google search for "OpenSSL CRL" turned up:

      http://blog.didierstevens.com/2013/05/08/howto-make-your-own-cert-and-revocation-list-with-openssl/

      Keep in mind that there seem to be issues with CRLs and FreeRADIUS as my reply to Tatis above shows.

      Delete
  3. Thank you very much, im going to try it.

    ReplyDelete
  4. I really tried, I Really tried, but this just sounds too ridiculous for wireless configuration, even if I wanted it to work..

    ReplyDelete
    Replies
    1. I'm not sure what you mean by "really tried". Did you actually try this and get stuck somewhere? It isn't intended to be read as a light novel but actual instructions to follow along with. Of course it is "ridiculous" until you realize that this is *actual security* and that no one's ever said real security was easy that actually knew what they were talking about. Real security is hard. The consumer-level WiFi setups that everyone is used to don't have ANY security and you're fooling yourself if you believe otherwise. And, of the available WPA2-Enterprise protocols, EAP-TLS is also the only actually secure WiFi connection protocol. With EAP-TLS, devices can't get onto the network in the first place without having a signed certificate issued by a private certificate authority, which, when properly locked down, requires physical access to the box that issues the certificates. I'm pretty certain that at that point the owner of said network would have other problems that would take precedence - such as staying alive to tell the tale (e.g. a home intrusion to get at your WiFi network - hey, people have done more idiotic things than that).

      When your WPA2-PSK network with a random ~40 character password that you think is secure is hacked into remotely like mine was, you'll reconsider the ridiculousness of this guide.

      Delete
  5. Any idea why this error would come up:
    error 20 at 0 depth lookup:unable to get local issuer certificate

    ReplyDelete
    Replies
    1. This may help:

      http://stackoverflow.com/questions/12041512/openssl-unable-to-get-local-issuer-certificate-unless-cafile-is-explicitly-speci

      Depending on the complexity of your CA/cert chain, you may need to concatenate the entire certificate chain into a single file. I'm not sure what the problem is beyond this.

      Delete
  6. Hello Thomas,
    I followed all your step one by one . But when i try to connect client with AP , it is not able to connect and gives an error deauthenticated by Local choice(reason=3). I am using Wi-Fi gui to connect to AP.Also not able to see any logs on radius server machine. Can you please help me????

    ReplyDelete
    Replies
    1. If you aren't seeing anything in the RADIUS logs, then your AP isn't talking to the server. RADIUS should ideally be on the same subnet as the AP. Check both the RADIUS and AP setup.

      My experience is that RADIUS doesn't work all that well with consumer-grade AP firmware. When I put the DD-WRT firmware on a cheap AP, it worked much better and helped me diagnose the problem I was running into. The AP firmware could be the problem - vendors don't really test the enterprise-y features very well.

      Delete
  7. For anyone having the following issue when creating your android certs.
    failed to update database
    TXT_DB error number 2

    # vi /etc/pki/tls/openssl.cnf
    set 'unique_subject = no'

    ReplyDelete
  8. I keep getting the error in freeradius debug:
    verify error:num=19:self signed certificate in certificate chain
    any ideas?

    ReplyDelete
    Replies
    1. Your CA root is self-signed. The root always is. It would be helpful to know what step you reached.

      Delete
  9. so i just came to the part where you want us to download "Make", but then i can´t proceed. You don`t even mention in one sentence, WHAT make ist, WHAT make does or any other infos, you`re like: go ahead and make destroycerts
    make index.txt
    make serial -> I tried, but i just get told that theres no rule, but HTF do i get this rule?

    ReplyDelete
    Replies
    1. It has been a long time since I've had to touch the FreeRADIUS install. I'm pretty sure this line:

      cp /usr/share/doc/freeradius/examples/certs/* /var/certs/freeradius/

      Copies a 'Makefile' to /var/certs/freeradius/.

      But you are right that I do assume that people know what 'make' is. So, 'make' takes a Makefile as input and any options and then executes a series of commands to reach the destination target. So, 'make destroycerts' looks to see what is required to complete the 'destroycerts' target and then executes that series of commands to get there. 'make' is primarily used to build software from source (e.g. ./configure followed by make). If you've never build software from source before, it is understandable that you might get confused. In this case, it is being used as a cross-platform way to manage the freeradius certs.

      Delete
  10. Hello Thomas,

    thank you VERY MUCH for this GREAT tutorial!

    Tried this on Ubuntu 14.04 and had to change the verify command to:

    /usr/bin/openssl verify -CAfile ${..CA_path}/ca.pem %{TLS-Client-Cert-Filename}

    The following packages were used:
    openssl:amd64/trusty-security 1.0.1f-1ubuntu2.5
    freeradius:amd64/trusty 2.1.12+dfsg-1.2ubuntu8

    I always got the following error in freeradius DEBUG output:

    error 20 at 0 depth lookup:unable to get local issuer certificate

    Next I tried the openssl verify command in the CLI and got the same problem. If
    I provided the CA file directly, it worked.

    I didn't dig very far into it, so if somebody has a better solution please post it here.

    ReplyDelete
    Replies
    1. OpenSSL isn't magical - it has to be able to trace a complete path to the root CA certificate: Your CA cert -> Optional intermediate cert #1 -> Individual cert. My guess is that newer versions of OpenSSL might require a full path to be traceable whereas before it might not have and would have just issued a warning. You can usually (at least with PEM format) embed CA cert public keys into the same file as the individual certificate public key. The order in which the certs appear in the file doesn't really matter as the software is able able to figure it out.

      Delete
  11. In case anyone else gets this error: rlm_eap: No such sub-type for default EAP type md5

    It was because I missed this very important change in eap.conf:
    default_eap_type = tls

    ReplyDelete
  12. This is a great tutorial, but if anyone is using Ubuntu 14.04.2 and freeradius 2.1.12 getting "error 20 at depth 0 lookup: unable to locate issuer certificate" when their client tries to authenticate the fix is to edit the verify function in the eap.conf file from:

    client = "/usr/bin/openssl verify -CApath ${..CA_path} %{TLS-Client-Cert-Filename}"

    to

    client = "/usr/bin/openssl verify -CAfile ${..CA_file} %{TLS-Client-Cert-Filename}"

    ReplyDelete
  13. my radacct table is showing empty in freeradius.in daloradius online users is also not visible.pls help me if possible.
    thank u.

    ReplyDelete
    Replies
    1. I've never used daloRADIUS. This post is for manually configuring FreeRADIUS with EAP-TLS as the only allowed protocol.

      Contact the daloRADIUS community for support with that product.

      Delete
  14. I got message from log.
    WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    WARNING: !! EAP session for state 0x3e833be03884222b... did not finish!
    WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility
    WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    how to solve this problem ?

    ReplyDelete
    Replies
    1. Read the referenced guide. Windows requires certain OIDs to be in the certificate. There are also limitations as to the size of any certificate and chain. When I first started using FreeRADIUS, I used a public/private key pair that was far too large and the system silently failed until I started over and made smaller keys.

      Delete
  15. While generating the client certificate, I am getting this error :

    cp client.p12 `grep emailAddress client.cnf | grep '@' | sed 's/.*=//;s/^ *//'`.p12
    cp: target ‘.p12’ is not a directory
    make: *** [client.p12] Error 1

    Can you please help me with this.

    ReplyDelete
    Replies
    1. Maybe 'client.cnf' changed and 'emailAddress' is no longer a part of that file? That's the only way I can think of that the stuff inside the backticks would evaluate to an empty string.

      Delete
  16. im getting this error when trying to run freeradius -x,
    "Failed to find 'Auth-Type EAP' section. Cannot authenticate users"
    "Installation failed for module eap"

    ReplyDelete
  17. Hi Thomas,

    We have CA and Issuing server on windows. And also have RootCA.pem, IssuingCA.pem and chain.pem files. We copied those files on to $(confdir)/certs directory. Is it OK?
    Also also generate Freeradius server cert and kept same directory .. What next

    Best regards

    Anwar

    ReplyDelete
  18. Fantastic tutorial. Got my whole house (phones, computers, raspberrypis) up and running quickly. I'll try to work out a recipe for wpa_supplicant--I need to get my IOT bits on too to fully abandon passwords.

    ReplyDelete
    Replies
    1. Neat! While it's not surprising, since it runs Linux, Raspberry Pi is a nice addition to the list.

      Since not every device supports this configuration, I actually have a dual Wi-Fi network setup on a single DD-WRT access point. The first Wi-Fi network is what is described here in this article (WPA2-Enterprise + AES). The other is a carefully configured WPA2-PSK network that can only talk to the Internet (i.e. not communicate with other devices on the network) but not access the router admin panel, talk directly to the upstream router, or SSH/SFTP anywhere I consider to be sensitive by using various iptables rules. The WPA2-PSK password is randomly generated using a script that runs once a month (i.e. the password automatically changes every month). I also have another script that runs and reports on connected devices so that no new device gets onto my network without me knowing about it. And even if something does manage to get onto the WPA2-PSK network, I can manually run my script to change the password to kick everything off and, given they were only able to access the Internet, the only thing that might happen is that someone could steal some bandwidth. As a result, the main network remains isolated while guests can comfortably access the Internet and I can easily reset access once they leave by running the monthly password reset script.

      If you are interested in doing something similar, I recommend this script as a starting point for the password reset portion:

      https://github.com/cubiclesoft/php-csprng/blob/master/tests/generate_words.php

      PHP CSPRNG supports using a dictionary frequency distribution to randomly generate fake but mostly pronounceable words. I recommend using 3-4 short, randomly generated words for a WPA2-PSK password generator. That will make it basically unguessable but still sufficiently readable for humans to type in vs. a completely random string that's hard to read/type.

      DD-WRT allows me to use a single access point to broadcast as many SSIDs as I want on a single channel. A single access point with multiple SSIDs produces less noise on the 2.4GHz and 5GHz bands and is therefore less likely to experience connectivity issues than using multiple access points.

      Even after setting all of this up, I still prefer wired LAN. It's more stable, easier, faster, and more secure, especially when messing around with VLANs. And it doesn't hurt that I've got plenty of Ethernet cable lying around.

      Delete

Post a Comment