Creating Certificates

Some distributions include a makefile in the /etc/raddb/certs directory. You can use this makefile in combination with OpenSSL to create three kinds of certificates: a certificate for (first) a small CA that will later sign the certificates for (second) the server and (third) the clients. However, if this directory is empty, as is the case with Ubuntu 9.04, you can grab the files from the FreeRADIUS GitHub at raddb/certs/ [6]. The package includes a configuration file for each certificate and a shared makefile. To create a new CA certificate, you need to modify ca.cnf. Modify the [certificate_authority] section as shown in Listing 2. The values for input_password and output_password must be identical.

To edit the [server] section in server.cnf, follow the same steps, but choose a different commonName to differentiate between the certificates (see Listing 3). Next, insert private_key_password, specified in eap.conf, as the password. Finally, make all will create both the CA and server certificates, the required Diffie-Hellman file (dh), and the random file, both of which are important components in the SSL/TLS handshake.

User Certificates

In EAP-TLS, each device needs its own client certificate, which you can create with client.cnf. The FreeRADIUS makefile signs these credentials with the server certificate by default. To use the CA to sign them, change the lines in Listing 4 and watch out for the tab at the start of line 2. You can then give the supplicants the CA certificates directly.

The commonName in the [client] section specifies the user name for permissions and other settings in RADIUS. Again, the certificate is password-protected using the passwords set as input_password and output_password:

[client]
countryName = DE
stateOrProvinceName = Hamburg
localityName = Hamburg
organizationName = UebelHacker
emailAddress = s@uebelhacker.de
commonName = uebelacker

In contrast to the CA and server certificates, you need to create multiple certificates here – one for each user. As make client only creates one certificate, it makes sense to script this task. You can then hand out the certificates, passwords, and the CA certificate to the users in a secure manner, preferably on a USB stick or smartcard.

Setting up Users

The next things the RAS server needs are the details of the authorized users. To keep this simple, you can simply give each user a client certificate signed by the CA. If you don't change the users configuration file on the RADIUS server, it will give access to anybody with a valid certificate. The switch will then assign the supplicant to the specified VLAN.

However, if you prefer to give the RAS server more details about the users, a number of options are available for doing so: The fastest approach would be to add the authorized and non-authorized users to the users file. See Listing 5 for an example of this method.

Line 3 of Listing 5 defines the defaults for any supplicant that provides a valid certificate via EAP. The Tunnel-Type and Tunnel-Medium details are required by the standard if you want the switch to assign a VLAN – for example, 23 as the user segment. RFC 2869 defines more RADIUS extensions; for example, you can restrict user logins to weekdays between 8am and 8pm to prevent night hacking sessions.

The first line blocks the user dau, who has just left the company but still has a valid certificate. As an alternative, you could implement this business logic with Certificate Revocation Lists (CRLs), although this step is slightly more complex. The first match rule applies for this file, unless you have set the Fall-Through attribute as shown in line 7. The additional attributes overwrite the settings for the administrator, uebelacker, who is not subject to time restrictions and lands directly in the administrative segment.

radiusd -X launches the RAS in debug mode to identify any incorrect configurations. If the server launches cleanly, RADIUS will show that it is now responding to requests:

Listening on authentication address 192.168.123.23 port 1812
Ready to process requests.

It makes sense to run the daemon in debug mode until the network port is unlocked; this will log any activities verbosely on standard output.