Once the initial EAP testing has been performed, it's time to create the production-grade server certificates for your FreeRADIUS environment. These certificates form the foundation of secure communications in your production network and will be configured on the end hosts using PEAP, TTLS, or EAP-TLS authentication.
Understanding certificate types for FreeRADIUS
There are the three certificate types used in secure FreeRADIUS implementations:
- Root CA certificate: The trusted authority that signs other certificates.
- Server certificate: Used by the RADIUS server to prove its identity to clients.
- Client certificate: Used for EAP-TLS authentication (optional for TTLS/PEAP).
Production certificates
The FreeRADIUS certificate configuration files are located in /etc/raddb/certs/*.cnf. Most of the contents of those files can be ignored, as they configure various OpenSSL parameters. Some fields (highlighted in bold below) should be edited to meet your local requirements.
Configuring the root certificate authority, ca.cnf
... [ req ] prompt = no distinguished_name = certificate_authority default_bits = 2048 input_password = whatever output_password = whatever x509_extensions = v3_ca
[certificate_authority] countryName = FR stateOrProvinceName = Radius localityName = Somewhere organizationName = Example Inc. emailAddress = admin@example.com commonName = "Example Certificate Authority" ...
Configuring your server certificate, server.cnf
... [ req ] prompt = no distinguished_name = server default_bits = 2048 input_password = whatever output_password = whatever
[server] countryName = FR stateOrProvinceName = Radius localityName = Somewhere organizationName = Example Inc. emailAddress = admin@example.com commonName = "Example Server Certificate" ...
You need to edit client.cnf only if you are using EAP-TLS. If not, then that file can be left as is.
Generating the root and server certificates
Once the ca.cnf and server.cnf files have been edited, you'll need to re-create the CA and Server certificates as before in the EAP procedure. This process will destroy any existing certificates, so you should make a backup of this directory before continuing.
$ cd /etc/raddb/certs $ make
Depending on the version of FreeRADIUS, the output may be
make: Nothing to be done for 'all'
In that case, you will have to remove some files manually, and then re-create the certificates:
$ rm -f *csr *key $ make
Otherwise, you should see OpenSSL creating the keys and certificates, as shown below:
openssl req -new -x509 -keyout ca.key -out ca.pem -config ./ca.cnf Generating a 2048 bit RSA private key ................................................... etc.
Testing your server certificates
Once the new certificates have been generated, restart the server in debugging mode, and repeat the tests given in the EAP procedure. Leave the Validate Server Certificate box (or equivalent) unchecked initially, and try to log in using the same username and password as in the PAP procedure.
If the authentication succeeds (and it should, if the EAP procedure succeeded), then you can proceed to the next step of importing the root CA onto client machines.
Creating and managing client certificates
Client certificates are required for EAP-TLS authentication, which provides the highest security level by authenticating both the server and client with certificates.
Generating client certificates
Creating a client certificate follows a similar process to server certificates:
- Edit the client.cnf file, setting appropriate fields in the [client] section at the bottom of the file.
- Save the file.
- Generate the certificate by running the following command:
$ make client
This command creates a new client certificate in client.pem, which can be imported into client devices for EAP-TLS authentication.
Creating multiple client certificates
For environments requiring multiple client certificates, repeat the above steps for each client. Important: Use different values for the fields emailAddress and commonName fields for each certificate. OpenSSL requires unique certificates for each client, and will complain if you try to create two different certificates that re-use those fields.
Common client certificate challenges in production networks
When deploying client certificates in large production networks, consider these factors:
- Certificate distribution: Develop a secure method for distributing certificates to users.
- Certificate revocation: Implement a process for revoking compromised certificates.
- Certificate renewal: Plan for periodic certificate renewal to maintain security.
Next step: importing your root CA certificate
After successfully creating your server and client certificates, the next critical step is to configure clients to properly validate server certificates by importing your root CA certificate. This ensures clients only connect to legitimate RADIUS servers, preventing man-in-the-middle attacks.
Need more help?
InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here.
Related Articles
Command line testing for EAP with FreeRADIUS
As part of the process of configuring EAP for FreeRADIUS, you will need to test whether or not it works. If you prefer to use a command line tool rather than clicking through windows, this article walks through the steps for testing your EAP configuration.
Importing the root CA
The final step to configuring EAP for FreeRADIUS is to add the CA (Certificate Authority) to every client machine that performs EAP authentication.