5.2.10.1. Radius Certificates Configuration

To be able to perform authentications through EAP, such as EAP-TLS or to be able to verify the identity of the servers by clients, it is necessary to configure the certificates in OpenNAC Enterprise.

../../../_images/eap-certs_ss.png


When you deploy an ON Server from an OVA, you probably have the FreeRadius certificates expired, and “eapol_test” will fail.

By default, the necessary files for the configuration of the certificates in the RADIUS service are:

  • ca.pem: Certificate containing the public CA to be able to perform EAP-TLS authentications. In case of having a PKI chain, it is recommended to include all the CAs of the chain in this file (End -> Intermediate -> Root).

-----BEGIN CERTIFICATE-----
    (Primary SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
    (Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
    (Root certificate)
-----END CERTIFICATE-----

  • server.pem: Server certificate so that clients can verify the identity of the server.

# Private key of the SSL certificate
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
# Public key of the SSL certificate (the server certificate)
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

5.2.10.1.1. Use an external CA certificate

In case you have your own CA certificate, you can use it with FreeRADIUS.

  • First you have to remove the test certificates information:

cd /etc/raddb/certs
make destroycerts

Warning

The “destroycerts” command will delete all certificates. Exercise extreme caution when executing this command on clients in a production environment, particularly when renewing certificates.

  • Modify in server.cnf file, all the properties you consider, taking special care in the following list:

vim server.cnf

  • default_days

  • input_password

  • output_password

  • countryName

  • stateOrProvinceName

  • localityName

  • organizationName

Note

Server properties (countryName, stateOrProvinceName, localityName and organizationName) have to match the CA certificate values.

  • Modify the private_key_password property from tls section, in the /etc/raddb/mods-enabled/eap_opennac and /etc/raddb/mods-enabled/inner-eap_opennac files, with the output_password value previosly indicated.

  • Generate the CSR request file, for server certificate:

make server.csr

  • Send the generated server.csr file to your certificate authority to obtain the certificate. Remember to include the XP extensions to use with Microsoft Windows.

  • You have to receive the server.pem file from the Certificate Authority, and copy it in /etc/raddb/certs directory.

If you receive a server.crt instead of a server.pem, then you can generate the server.pem file, with the following commands:

PASSWORD_SERVER=`grep output_password server.cnf | sed 's/.*=//;s/^ *//'`
openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12  -passin pass:${PASSWORD_SERVER} -passout pass:${PASSWORD_SERVER}
openssl pkcs12 -in server.p12 -out server.pem -passin pass:${PASSWORD_SERVER} -passout pass:${PASSWORD_SERVER}

  • You have to get the public certificate from the Certificate Authority, for instance, the ca.pem file, and copy it in /etc/raddb/certs directory, to be used by FreeRADIUS to check the client certificates.

  • Prepare the dh and random files:

make dh
make random

  • Finally, provide the right ownership to all the new files and restart RADIUS server:

chown root:radiusd *
systemctl restart radiusd

5.2.10.1.2. Testing Mode Certificates

Warning

This section is for test purposes. It is not recommended to use this configuration in production environments.

You can perform the following steps to renew the certificates in test mode and be careful when using it to production mode. We have followed the <raddb_dir>/certs/README indications.

  • First of all, go to the certificates folder and remove the old test certificates and the certificate’s counters:

cd /etc/raddb/certs
make destroycerts

Note

In case you only want regenerate one specific kind of certificate, you have to remove the indicated CRT and KEY files, and modify the property “unique_subject = no” inside index.txt.attr file, to allow rewrite an existing subject.</notice>

  • Define the “default_days” property in each CNF files (ca, server or client), to indicate the validity of the certificates. 60 days is configured by default. If you want, you can modify the information related to the organization and passwords.

  • Execute bootstrap file, to generate the CA and server certificates:

./bootstrap

  • Finally, provide to all new files the right ownership and restart RADIUS server:

chown root:radiusd *
systemctl restart radiusd

5.2.10.1.2.1. Making a client certificate

  • To generate client certificates, you have to indicate a unique emailAddress and commonName in client.cnf file:

vim client.cnf

And generate the certificate with the following command:

make client.pem

Note

The users certificate will be in “<emailAddress>.pem”, i.e. “user@example.com.pem”.

To create another client certificate, just repeat the steps for making a client certificate. Be sure to enter a different login name for “commonName”, and a different password.

5.2.10.1.3. Certificate Troubleshooting

Important

When we talk about certificate validation it is important that the dates of the equipment are correct. If the computers that are performing certificate verifications have incorrect dates, it is likely that the validation will fail and therefore the authentication will not be possible.

Ensure that both the OpenNAC server and the clients connecting to the network have the up-to-date dates.

1. Check that Private Key and Server Certificate are in PEM format:

For details on formats, see the Format conversions section, below. Run the following commands to check if your files are already in the required PEM format:

To check if your Private Key is in PEM format, run:

openssl rsa -inform PEM -in server.key

To check if your Server Certificate is in PEM format, run:

openssl x509 -inform PEM -in server.crt

2. Verify that the Private Key and Server Certificate match:

    openssl x509 -noout -modulus -in server.pem | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5

  • If the key is inside the server.pem file, you can use server.pem instead of server.key.

The output of these two commands must be exactly the same. If you cannot locate a matching Private Key to your Server Certificate, you will be required to re-key the certificate by generating a new CSR and requesting an updated certificate from the corporate CA.

3. Verify that the Public Keys contained in the Private Key file and the Server Certificate are the same:

    openssl x509 -in server.pem -noout -pubkey
openssl rsa -in server.key -pubout

  • If the key is inside the server.pem file, you can use server.pem instead of server.key.

The output of these two commands should be the same.

4. Check that the “Valid From” and “Valid To” dates of the certificate are correct:

openssl x509 -noout -in /etc/raddb/certs/server.pem -dates

Ensure that the current date is between the certificate’s “Not Before” and “Not After” dates.

5. Check the validity of the Certificate Chain:

openssl verify -CAfile /etc/raddb/certs/ca.pem /etc/raddb/certs/server.pem

If the response is “OK”, the check is valid.

If the client provides us with a client certificate, we can use this command to verify that the client certificate is valid with the CA that we have installed on the radio and therefore that it will authenticate correctly:

openssl verify -CAfile /etc/raddb/certs/ca.pem client.pem

5.2.10.1.3.1. Test Radius Certificate Authentication with radtest

You can use some OpenNAC utilities to simulate Radius authentication using a certificate, this will help you validate that the certificates are correct and eliminate doubts or points of failure in the troubleshooting process.

To begin, go to:

cd /usr/share/opennac/utils/radtest

To see all the testing possibilities, you can cat the README.txt file.

In this scenario, the test of interest is as follows:

* Send a 802.1x certificate authentication request:
./auth_802.1x.sh peap-tls.conf

To use the client certificates, edit the peap-tls.conf file:

eapol_version=1
fast_reauth=1

network={
        key_mgmt=WPA-EAP
        eap=TLS
        identity="usertest"
        ca_cert="/etc/raddb/certs/ca.pem"
        client_cert="/etc/raddb/certs/client.pem"
        private_key="/etc/raddb/certs/client.key"
        private_key_passwd="whatever"
        eapol_flags=3
}

Here, you must set the following information:

  • identity: Field used as the client’s identity. This information is not relevant in authentication (we can leave it as default).

  • ca_cert: CA that will be used to validate the server certificate in the handshake process.

  • client_cert: Client certificate used for authentication.

  • private_key: Key of the client certificate used for authentication (if it is within the client_cert we must put the same file).

  • private_key_passwd: Password to decrypt the client certificate and perform authentication.

After configuring the different parameters, run the test by executing:

./auth_802.1x.sh peap-tls.conf

If everything has gone correctly, you should obtain the “SUCCESS” result:

...
EAP: Status notification: remote certificate verification (param=success)
...
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
...
SUCCESS

You can also verify it in the OpenNAC Default View.

If you encounter a FAILURE, you should review the reason in the logs.

If you want to investigate why it is failing from the RADIUS side, it is advisable to disable the RADIUS service (if not in a production environment) and start it in debug mode:

systemctl stop radiusd
radiusd -X

With the RADIUS service started in debug mode, you can rerun the auth_802.1x.sh test and see the problem in the RADIUS console logs.

Once the debug is finished, start the radiusd service again:

systemctl start radiusd