Paranoid Penguin - Securing Your WLAN with WPA and FreeRADIUS, Part III
We're finally ready to configure FreeRADIUS. You may be intimidated when you see the long list of files in etc/raddb, but don't be. For WPA with EAP-TLS, we need to edit only three files: radiusd.conf, eap.conf and clients.conf.
In radiusd.conf, all we need to do is set the user and group accounts that the radiusd process runs as. By default these are inherited from whatever user starts the dæmon. If you run radiusd from a startup script, this is root; however, you definitely do not want to run radiusd as root. Therefore, you should set the user and group parameters in radiusd.conf, both set to nobody, as shown in Listing 2.
Listing 2. Two Parameters to Set in radiusd.conf
user = nobody group = nobody
Naturally you can choose different nonprivileged user and group accounts instead of nobody and nobody, but if you do so, you need to adjust the ownerships and permissions on the certificate files we tweaked earlier. Regardless, make sure your nonprivileged user's entry in /etc/password sets the user's shell to a non-shell, such as /bin/false or /bin/true—this account should not be usable for SSH, telnet or similar programs. For that matter, make sure both the user and group accounts exist in the first place, and create them if they don't.
Other parameters may be set in radiusd.conf, but these really are the only two whose default settings need to be changed. See the radiusd.conf(5) man page or Jonathan Hassell's book RADIUS for more information.
The next file we need to edit is eap.conf; here's where the real heavy lifting occurs. Listing 3 shows the lines you need to edit in eap.conf.
Listing 3. Changes in eap.conf
eap {
# There are several generic EAP parameters you can
# set here, but the important one for our purposes
# is default_eap_type:
default_eap_type = tls
# Next come parameters for specific EAP types. Since
# we're going to use EAP-TLS, the tls{} section is
# the one we care about:
tls {
# The following parameters tell radiusd where to
# find its certs and keys, plus dh & random files:
private_key_password = keYpasSphraSE_GOES_h3r3
private_key_file = ${raddbdir}/certs/bt_keycert.pem
certificate_file = ${raddbdir}/certs/bt_keycert.pem
CA_file = ${raddbdir}/certs/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
}
}
In Listing 3, I've specified a server-key passphrase with the private_key_password parameter. This actually should be empty if you created your server certificate and key with OpenSSL's -nodes option. Unfortunately, I told you to use this option in last month's column, and I'm retracting that advice now: it is poor practice to use passphrase-free X.509 keys, even when that key is stored in a clear-text configuration file such as eap.conf. Yes, if the FreeRADIUS server gets rooted—hacked into with root privileges—even a passphrase-protected certificate still can be compromised, thanks to eap.conf. But if the certificate/key file is eavesdropped in transit—when, for example, you transfer it from your CA host to your FreeRADIUS server—it is useless to the attacker if it's passphrase-protected.
Either way, make sure that eap.conf is owned and readable only by root and not by the unprivileged user account you configured in radiusd.conf. This may seem paradoxical—doesn't nobody need to be able to read configuration files? But, if you start radiusd as root, it reads its configuration files, including radiusd.conf, eap.conf and clients.conf, before demoting itself to nobody.
Finally, you need to create an entry for your access point in clients.conf. Listing 4 shows such an entry.
Listing 4. Access Point Entry in clients.conf
client 10.1.2.3/32 {
secret = 1sUpErpASSw0rD
shortname = wiremonkeys_AP
}
In Listing 4, the client statement specifies the access point's IP address. Its secret parameter specifies a string that your access point uses as an encryption key for all queries it sends to your FreeRADIUS server. shortname simply is an alias for your access point to be used in log entries and so on.
You now can start radiusd by using the rc.radiusd script, for example, rc.radiusd start. You also could restart it with rc.radiusd restart. If radiusd starts without errors, you're ready to go.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- RSS Feeds
- New Products
- Trying to Tame the Tablet
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
- Drupal is an Awesome CMS and a Crappy development framework
4 hours 33 min ago - IT industry leaders
6 hours 55 min ago - Reply to comment | Linux Journal
23 hours 43 min ago - Reply to comment | Linux Journal
1 day 2 hours ago - Reply to comment | Linux Journal
1 day 3 hours ago - great post
1 day 4 hours ago - Google Docs
1 day 4 hours ago - Reply to comment | Linux Journal
1 day 9 hours ago - Reply to comment | Linux Journal
1 day 10 hours ago - Web Hosting IQ
1 day 11 hours ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




Comments
Addendum
killall -HUP radiusd may not work for some - you may need to kill (stop) the daemon entirely, and restart it for it to reread the .pem files.
Addendum
killall -HUP radiusd may not work for some - you may need to kill (stop) the daemon entirely, and restart it for it to reread the .pem files.
Getting CRLs to work properly (hurrah!)
This guide on FreeRADIUS & WPA Enterprise is brilliant, but I had major problems getting a CRL to work/check correctly - but have figured it out and will share it with everyone CLEARLY, to save other poor souls the problems I've had (along with others who get no clear help on the FreeRADIUS lists!)
To revoke a certificate, run :
openssl ca -revoke CERT_TO_REVOKE.pem -keyfile ca.key -cert ca.pem -config ./ca.cnf
Obviously your filenames may vary :)
Once it's revoked, run these commands :
openssl ca -gencrl -keyfile ca.key -cert ca.pem -out mycrl.pem -config ca.cnf
cat ca.pem mycrl.pem > ca_and_crl.pem
That will build a CRL file (mycrl.pem), and then concatenate your ca.pem file with it, to build ca_and_crl.pem
The ca_and_crl.pem is now your CA cert WITH the CRL. This is KEY to the whole thing working!
Then, edit your eap.conf and edit CA_file so it reads :
CA_file = ${certdir}/ca_and_crl.pem
Then change include_length, check_crl and CA_path to be :
include_length = yes
check_crl = yes
CA_path = ${certdir}/
Then run killall -HUP radiusd and radius will restart, and now should accept certs which are NOT revoked, but throw out your rejected cert.
I hope that helps someone! Bear in mind if you DON'T concatenate the ca.pem and mycrl.pem, anything you revoked will NOT be revoked (the CA will still say it's signed and ok) - so ENSURE you keep your CRL file handy, OR ensure your client certificates are not issued for HUGE amounts of time :)
Thank you Mr Pete
I mean it. Worked 'out of the box'.
I'm so pleased with this page
Very new to Linux but following this instruction step by step, i was able to establish a TLS connection to a RedHat9 server within 1 working day. I use Ruckus Wireless Access Point and Odyssey client. Choose option to ignore server validation. Works like charm. Thank you so much !!!
Working RH v5.1 Version
Hi Guys - thought this might be useful, (Red Hat'd version of this article). I'm a novice and perhaps this isn't best practice but it's working for me:
-- Certificate Setup --
1. Modify /etc/pki/tls/openssl.cnf - this file contains the defaults information for the certificates.
dir = /etc/ssl
countryName_default = GB
stateOrProvinceName_default = Antrim
localityName_default = Belfast
0.organizationName_default = CSI Ireland Limited
2. Create the file /etc/ssl/xpextensions with the following, these are additional extensions required by XP clients:
[ xpclient_ext ]
extendedKeyUsage = 1.3.6.1.5.5.7.3.2
[ xpserver_ext ]
extendedKeyUsage = 1.3.6.1.5.5.7.3.1
3. Create a new self-signed certificate authority (if not already created) in /etc/ssl:
mkdir private
mkdir newcerts
touch index.txt
echo '01' > serial
openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 3650
4. Create server certificate request in /etc/ssl:
openssl req -new -nodes -keyout server_key.pem -out server_req.pem -days 730
5. Sign server certificate using the certificate authority created earlier (with XP extensions):
openssl ca -policy policy_anything -out server_cert.pem -extensions xpserver_ext -extfile /etc/ssl/xpextensions -infiles /etc/ssl/server_req.pem
6. Create a server file with both the server key and the server certificate:
cat server_key.pem server_cert.pem > server_keycert.pem
7. Create a client certificate request in /etc/ssl:
openssl req -new -keyout client_key.pem -out client_req.pem -days 730
8. Sign client certificate using the certificate authority created earlier (with XP extensions):
openssl ca -policy policy_anything -out client_cert.pem -extensions xpclient_ext -extfile /etc/ssl/xpextensions -infiles /etc/ssl/client_req.pem
9. Export the client certificate in the appropriate format (P12) for an XP client:
openssl pkcs12 -export -in client_cert.pem -inkey client_key.pem -out client_cert.p12 -clcerts
10. Export the root certificate of the server in the appropriate format (DER) for an XP client:
openssl x509 -setalias "Radius@CSI" -outform DER -in cacert.pem -out cacert.der
11. The files 'client_cert.p12' and 'cacert.der' can now be safely moved to a folder for import onto the XP clients.
-- FreeRadius Setup --
12. Remove the FreeRadius default certificate files etc:
rm -Rf /etc/raddb/demoCA
13. Create the appropriate directories in /etc/raddb in which to keep the certificate information:
mkdir /etc/raddb/certs
14. Move the server certificate and the root certificate to the FreeRadius folder:
cp /etc/ssl/cacert.pem /etc/raddb/certs/
cp /etc/ssl/server_keycert.pem /etc/raddb/certs/
15. Create the Diffie-Hellman parameters file using for TLS:
openssl dhparam -check -text -5 512 -out dh
16. Create the random bitstream file for TLS:
dd if=/dev/urandom of=random count=2
17. Modify /etc/raddb/eap.conf (full listing):
eap {
default_eap_type = tls
tls {
private_key_password = ************
private_key_file = ${raddbdir}/certs/server_keycert.pem
certificate_file = ${raddbdir}/certs/server_keycert.pem
CA_file = ${raddbdir}/certs/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
}
}
18. Client a radius client for the wireless access point in /etc/raddb/clients.conf:
client x.x.x.x/xx {
secret = **************
shortname = Secure-WAP
}
19. Modify /etc/raddb/radius.conf:
(To see authentication requests and results)
log_auth = yes
authorize {
preprocess
eap
files
}
authenticate{
eap
}
excellent documentation
this step by step explanation is really helpful. It worked for me..Thanks
Encrypting the unencrypted private key
If you used the -nodes on the server key request as in Part II but want to now encrypt the private key, you can use
mv server_key.pem server_key_DELETEME.pem
openssl rsa -in server_key_DELETEME.pem -des3 -out server_key.pem
You will be prompted for a passphrase for the (new) server_key.pem. You must give -des or -des3 for the new key to be encrypted.
You'll want to recreate server_keycert.pem from the new server_key.pem.
The server_cert.pem doesn't change.
You can use this command anytime you might want to change the passphrase on a private key.
I use this command to check users' ssh keys to see that they actually have a passphrase.
openssl rsa -passin 'pass:' -in id_rsa -out /dev/null
peap with tls not working
I followed the steps as mentioned in this article, configured PEAP with TLS but unable to establish connection with the access point. But when i enable "Authentication as
computer when computer info is available" on xp supplicant i could see the traffic hitting freeradius server for the 1st time alone.
Am using intel pro/2200 bg wireless card on xp supplicant and linksys wap54g AP. I have enabled wpa_enterprise on the AP and configured the same on xp supplicant.
did anyone faced this issue ?
supplicant in windows
Hi all,
I followed the steps in the entire 3 parts of this article but i am not able to establish a connection with the Access point. I am using a Netgear wg311v2 card(uses acx_pci in linux and netgear wireless utility for a GUI based configuration in windows basically a Ndis driver). I am trying to setup the WPA support through the Netgear wireless GUI utility. But WPA-PSK is only available. Does anyone know if Netgear wg311v2 supports other WPA methods say the WPA-RADIUS? This is of utmost priority....Kindly let me know even the basic clues that can make the set up work.
Thank u,
Cheers,
Anuranjani Nandakumar
Network snarfing of private keys? Huh?
There's no need to ever transfer private keys around between CA hosts and RADIUS servers.
You avoid this completely by generating the private key on the RADIUS host, generating your certificate request on that host, transfering the request to the CA, signing it there (with the CA private key that never leaves the CA host) and copying the signed certificate (which contains no private information) back to the RADIUS host (in the clear if you really want).
Now, for convenience it might be handy to keep the private key and cert together and generate both on the CA host, but we're erring on the side of security here, right? ;)
Certain proprietary operating systems might make it hard for you to take this approach, of course.
How to connect to WPA-protected WLAN before logging (to domain)?
Great set of articles. I've setup FreeRADIUS, CA, APs & WinXP clients and everything works well (when I log on to WinXP local account). But there's a problem - how can I connect my WinXP client to WPA (EAP-TLS) protected network BEFORE he logs to domain (SAMBA)? Before logging there's no certificate to use for WPA (they are stored in profiles I think). So how can I login to domain and get certificate from profile before connecting to network which needs it?
There's tool - "wpa_supplicant" - I've heard that it can be run as service in WinXP and can connect system to WPA-protected network but I don't want use it (it requires additional configuration and certs are required to be stored on client's disk, not mentioning about unencrypted password for certificate in configuration file, this i potential security hole - someone can copy certs & conf from one computer to another and can gain access to network)
Regards
Chris
How to connect to WPA-protected WLAN before logging (to domain)?
Any ideas?
Great guide!!
Thanks for this wonderfull explanation about wpa in general, and eap-tls in particular. Especially the explanation of how you make appropriate certificates is excellent. Many tutorials about creating those certificates make use of some scripts that come with freeradius, but those never worked for me. With your step by step approach we understand what we're doing, in contrast to those scripts.
Great article, but needs some corrections
Great Article.
I had the same errors as described above:
- The first error is in the listing of eap.conf:
private_key_file = ${raddbdir}/certs/bt_keycert.pem
certificate_file = ${raddbdir}/certs/bt_keycert.pem
This should read:
private_key_file = ${raddbdir}/certs/server_keycert.pem
certificate_file = ${raddbdir}/certs/server_keycert.pem
Most distributions already create radiusd user + group so if you install from a package just run radius as that user instead of user nobody.
After this I still had trouble running it under user radiusd (error reading root CA stuff) running as user root was working!
found solution at google groups:
I did a #chown -R radiusd /etc/raddb/.
This is from google groups (not sure if you need to do this)
[root@p doc]# chmod -R -rwx /etc/raddb
[root@p doc]# chmod u+rwx /etc/raddb
[root@p doc]# chmod u+rwx /etc/raddb/certs/
[root@p doc]# chmod u+rwx /etc/raddb/certs/demoCA/
[root@p doc]# chmod -R u+rw /etc/raddb
[root@p doc]# mkdir /var/run/radiusd
[root@p doc]# chown radiusd:radiusd /var/run/radiusd.pid
[root@p doc]# chown -R radiusd:radius /var/run/radiusd
[root@p run]# /etc/init.d/radiusd stop
Stopping RADIUS server: [FAILED]
[root@p run]# /etc/init.d/radiusd start
Starting RADIUS server: [ OK ]
[root@p run]# /etc/init.d/radiusd status
radiusd (pid 6239) is running...
Now radius started without errors...I now have to check if I can get my clients to connect...
WLAN FREE RADIUS with windows xp SP2 supplicant
I followed the article and made corrections to eap.conf.
- The first error is in the listing of eap.conf:
private_key_file = ${raddbdir}/certs/bt_keycert.pem
certificate_file = ${raddbdir}/certs/bt_keycert.pem
This should read:
private_key_file = ${raddbdir}/certs/server_keycert.pem
certificate_file = ${raddbdir}/certs/server_keycert.pem
Radius server started with no errors.
I want to add one point to the article regarding configuring the windows xp sp2 supplicant.
After you follow the article for configuring win xp sp2 supplicant. go the wireless network properties under Authentication Tab click properties and uncheck validate server.
Once i did that i was able to connect to the wireless network. I dont know if this is right or i did something wrong while creating the certificates.
Thanks again
Thank you for the three-part article. It was very useful and as far as I'm concerned it works.
My test system is composed of:
1 radius server on Gentoo Linux,
2 Linksys WAP54G
1 Linksys WRT54G
1 AMD Turion64 laptop with Broadcom wifi (used native WinXP SP2 supplicant)
Would like to point out that on the Linksys APs you should use the WPA-Enterprise security option (not the RADIUS option).
fopen error
Hi. I found a solution, which seems to work: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg156...
cacert.pem
I have followed your step and keep getting this error. I checked the perrmissions on cacert.pem and it is set as you say to set it.
8830:error:0200100D:system library:fopen:Permission denied:bss_file.c:104:fopen('/etc/raddb/certs/cacert.pem','r')
18830:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:109:
18830:error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:by_file.c:274:
rlm_eap_tls: Error reading Trusted root CA list
rlm_eap: Failed to initialize type tls
radiusd.conf[9]: eap: Module instantiation failed.
in radiusd.conf coment out
in radiusd.conf coment out lines :
# user = radiusd
# group = radiusd
maybe it is not safe to run radius as root but at least it solves the problem :)
CA.all script file
In the 30th line of CA.all script (ie. under the freeradius source directory) file make sure you have set the path properly, that should resolve this issue.
me too
me too
fopen:Permission denied:bss_file.c
I too have this same problem
Fixing fopen:Permission denied:bss_file.c
When freeradius is installed via the RPMS available for CentOS and I assume Fedora the permissions on /etc/raddb prevent other user from executing the directory. To get rid of the fopen error and still keep things relatively closed down just execute:
chmod o+x /etc/raddb
I also had to change
I also had to change permissions on the certs directory in /etc/raddb to be able to connect successfully
chmod o+x /etc/raddb
sorry that was u+x
sorry that was u+x /etc/raddb/certs
OMG that solved my problem..
OMG that solved my problem.. Thank you!!
small problem
rlm_eap_tls: Loading the certificate file as a chain
rlm_eap: SSL error error:0906D06C:PEM routines:PEM_read_bio:no start line
rlm_eap_tls: Error reading certificate file
rlm_eap: Failed to initialize type tls
radiusd.conf[10]: eap: Module instantiation failed.
radiusd.conf[1919] Unknown module "eap".
radiusd.conf[1866] Failed to parse authenticate section.
any idea?
Verify that password for
Verify that password for private key in eap.conf is properly set.
how did u fix this issue?
i meet the same status~
Plz tell me how to fix this issue?
THX
What did you do to fix this?
What did you do to fix this?
ok i got it
ok i got it
but when i want to connect to my wlan i got invalid cerificate...
What did you do to fix this issue?
Hi, I also have the same problem. What have you done to get this fixed? Could you pase a copy of your radiusd.conf?
i had the same issue in
i had the same issue in debian, apparently you have to build a package instead of ./configure, make and make install, i used the instruction here http://wiki.freeradius.org/Build#Building_Debian_packages hope that helps