FreeRADIUS InkBridge

EAP Certificates

EAP servers performing TLS-based authentication methods will have one or more certificates configured. There are two distinct purposes for these certificates:

  • Server certificates are presented to connecting devices for them to validate their trust of the server.

  • Trusted CA certificates are used to validate trust of certificates presented by end devices.

FreeRADIUS uses OpenSSL to handle SSL operations. Some of its behavior depends on the version of the OpenSSL libraries it uses and how the global system configuration for OpenSSL is set up.

When upgrading the operating system and OpenSSL libraries it’s crucial to understand any version-specific differences relevant to the functionality of the RADIUS service. Some default behaviours that may change include:

  • The accepted list of protocols, ciphers and key sizes.

  • The method by which chains are built when validating certificates.

  • Required properties of certificates in a chain for an end entity certificate to be verified.

  • The TLS record format that is generated or accepted for on the wire transmission.

Server certificates

Any RADIUS server performing TLS-based EAP must have a server certificate and associated key. This certificate can be signed by a public CA which the end devices already trust, or it can be signed by a self-signed CA managed by the organization. If using a self-signed CA, configure the supplicant to trust the self-signed CA for EAP server authentication purposes. This is often done with a managed security policy.

It’s also possible that a supplicant is instructed to trust an “anchor” certificate in a chain of certificates. The server certificate in this chain has been signed by an intermediate CA certificate, which may have been signed by another CA certificate, and so on, up to a self-signed root CA certificate.

The trust anchor configured on the end device may not be the root CA, in which case this is referred to as validating a "partial chain" as shown below.

     Root CA
        |
Intermediate CA A  <- Supplicant instructed to trust this "anchor"
        |
Intermediate CA B
        |
   Server Cert

The simplest set up for the server certificate for FreeRADIUS is to put all certificates into the certificate file. Put the server certificate and any intermediate certificates needed to reach the certificate trusted by the end device. This file must start with the server certificate and work its way up the chain.

While the certificate file can include the certificate trusted by the supplicant, this may cause larger packet exchanges between FreeRADIUS and the end device. Some supplicants may also fail to trust the server if this certificate is included. Therefore, it’s recommended to stop the certificate file at the certificate in the chain that’s immediately before the one configured as a trust anchor.

In the example above, this means the server certificate file should contain:

  • Server Cert

  • Intermediate CA B

Extended Key Use Extension

In order to satisfy the requirements of certain supplicants, server certificates must contain the following Extended Key Use extension:

  • Server Authentication - OID 1.3.6.1.5.5.7.3.1

It’s strongly recommended to include the following EKU extension in any client certificates generated for EAP-TLS. (or EAP-PEAP /EAP-TTLS methods in which the client certificate is to be validated):

  • Client Authentication - OID 1.3.6.1.5.5.7.3.2

In addition:

  • Some supplicants (notably Windows) refuse to accept wildcard certificates, so these should be avoided for maximum compatibility.

  • Some supplicants (notably ChromeOS) reject Extended Validation (EV) certificates.

  • Apple supplicants will not accept leaf certificates whose validity period is greater than 397 days.

  • Some supplicants (notable MacOS) require that the certificate include a critical BasicConstraint CA:FALSE.

  • Some supplicants store and check the certificate Subject CN. Others use the Subject Alternate Name. Therefore the same (case-sensitive) server name in the form of an FQDN (not necessarily matching the server’s hostname) should be used as both the CN and as a SAN.

When replacing certificates, ensure that the replacement certificates match any explict requirements that are configured on the supplicants of all end devices.

For example, specific names (or domain suffixes) expected in the CN and/or Subject Alternative Names may be part of requirements that have been pinned in the network’s 802.1X profile via an explicit managed security policy.

Furthermore, the CN and/or SAN names from certificates presented during previous network connections may have been automatically saved. This action results in an implicit requirement for future certificates. Changing these “learned” properties cause an authentication failure or the user is prompted to manually accept any new certificate with previously unknown properties.

When replacing a server certificate, make sure you have enough time to update the end devices’ policies. This way, the end devices trust the new server certificates before the old ones expire or are replaced.

Trusted CA certificates

When using “mutual TLS", FreeRADIUS needs to know which CAs to trust to authenticate the end device. The end devices present certificates to the server like EAP-TLS.

The easiest way to manage this is to put any CAs that must be trusted in a single file (named ca_file). Alternatively, the trusted certificates can be placed in a directory (named ca_dir).

CAs used for signing end device certificates should NOT be public CAs. Trusting public CAs usually means that an end device presenting any certificate signed by that same CA is trusted. If client authentication uses a public CA, the acceptable client certificates must be resticted (using the check_cert_cn option or the check-eap-tls virtual server).

However, a self-signed CA used only for EAP authentication, whose private key is known only to the organization, doesn’t have this problem.

Using FreeRADIUS’s provided scripts to create certificates

If a CA is not already in use for signing certificates then FreeRADIUS ships with scripts which can create a CA, server certificates, and client certificates.

Full details of how to generate certificates can be found here and the corresponding raddb/certs/Makefile.

Loading certificates onto the RADIUS servers

Certificates to be loaded onto the RADIUS servers must be copied into raddb/certs directory. Use file names which help to identify what the certificates are.

The freeradius certificates required at a minimum are:

  • ca.pem: raddb/certs/ca.pem

  • server.pem: raddb/certs/server.pem

  • server.key: raddb/certs/server.key

If additional certificates are needed for different EAP methods (e.g. EAP-PEAP using one server certificate and EAP-TLS using another) then generate and add the required certificates into this directory.

Certificates in the FreeRADIUS EAP Configuration

Certificate settings for EAP are found in the eap module configuration located in the raddb/mods-enabled/eap directory.

If a common set of certificates is used by all EAP methods then it will be set in a tls-config section called tls-common. This section is referenced within each EAP method that’s enabled.

This section contains at least the following:

tls-config tls-common {
#    private_key_password = whatever
    private_key_file = ${certdir}/server.key
    certificate_file = ${certidir}/server.pem
    auto_chain = no
    ca_file = ${cadir}/ca.pem
#    ca_dir = ${cadir}/trusted
    tls_min_version = "1.1"
    tls_max_version = "1.2"
}

If applicable, the private_key_password item must be un-commented and set to the password used when generating the private key,

The certificate_file and private_key_file items refer to files that contain the server certificate (followed by intermediate CAs up to but not including the CA trusted by supplicants) and the private key corresponding to the server certificate, respectively.

By setting the auto_chain item to no the certificate chain will be presented to the end device as it is in the server certificate file. With auto_chain set to yes OpenSSL automatically creates a chain. The chain is based on the certificates in ca_file and ca_dir. OpenSSL’s automatic chain building behaviour differs greatly between versions and may result in a chain that may not reflect what the supplicant expects.

The ca_file item refers to a file that contains CA certificates which FreeRADIUS trusts when checking client certificates.

The ca_dir item refers to a directory containing CA certificates which FreeRADIUS trusts when checking client certificates. Additionally, any Certificate Revocation Lists (CR) are included. After modifying this directory the c_rehash command must be run.

The set of certificates present in ca_file determines the list of Distingished Names trusted by the server which are sent to an end device when a client certificate is requested. For example during EAP-TLS authentication, or during PEAP or EAP-TTLS when mutual authentication is requested. This not true for trusted certificates within the ca_path directory.

Many supplicants won’t send a client certificate unless its issuer is in the list of trusted certificates sent by the server. Also, the client’s issuer may be in the configured client certificate chain. Also. The supplicant won’t send a certificate if the list of trusted certificates is empty. This means no ca_file is configured with trusted certificates placed in the ca_dir.

Many supplicants won’t send a client certificate unless its issuer (or one of the configured client certificate chain issuers) is in the list of trusted certificates sent by the server. Also, the supplicant won’t send a certificate if the list of trusted certificates is empty. This means no ca_file is configured with trusted certificates placed in the ca_dir.

The tls_min_version and tls_max_version items control which TLS versions are acceptable.

In order to allow supplicants to connect using TLS versions 1.0 or 1.1 the option cipher_list within the tls-config may need to be set as follows

    tls-config tls-common {
        ...
        cipher_list = "DEFAULT@SECLEVEL=1"
        ...
    }

This situation arises if the server’s system default for SECLEVEL is higher.

For strong security we recommend setting tls_min_version to 1.2 or 1.3.However this setting might prevent end devices on older operating systems from connecting.

Different certificates for different EAP methods

If different certificates are required for different EAP methods then create additional tls-config sections with distinct names. Reference the corresponding tls-config section in the configuration section for each EAP method

Example 'tls-config' section

    tls-config eap-peap-tls-config {
        ...
        private_key_file = ${certdir}/server-peap.key
        certificate_file = ${certdir}/server-peap.pem
        ...
    }

    peap {
       ...
       tls = eap-peap-tls-config
       ...
    }

Add the new certificate and key to the servers.