eduroam's EAP authentication is secured using X.509 certificates — the same sort of security certificates you use for websites. However, unlike a web server, you shouldn't necessarily rush out and buy a certificate for eduroam…
There are a few ways to create a security certificate you can use for your eduroam RADIUS server, each with its own relative pros and cons. You can use a commercially signed certificate, one signed by an internal CA (e.g., Active Directory Certificate Services), or a self-signed certificate generated by your RADIUS software.
Our recommendation for new RADIUS server deployments is as follows:
Note that irrespective of which option you choose, you should not use a wildcard certificate since this is known to be problematic in some versions of Microsoft Windows. Similarly, certificates that use a SHA1 hash do not work with Apple and newer Android devices.
GÉANT (who maintain the global eduroam infrastructure) has published a useful guide on the various options available, and their relative pros and cons. You can also use the pre-selection approach described below to support multiple options.
RSA certificates are much larger than their elliptic curve (ECC) equivalents. This results in longer key exchanges (potentially slowing authentication) and larger RADIUS packets. For UDP, this can sometimes trigger fragmentation problems, resulting in intermittently failing authentications that are hard to debug.
While they're historically less widely used, ECC certificates are well supported by all major vendors and have been for a long time. They are also extensively used in eduroam. There are no known Wi-Fi compatibility concerns with anything newer than Android 8, Windows 8, or iOS 9.
The benefits of using ECC typically far outweigh the slower authentication and the risk of fragmentation with RSA. That's even more true for longer chains (such as used in the current iteration of our certificate service). For this reason, we recommend using ECC certificates on all new deployments.
You'll note that there are several mentioned of eduroam CAT above. This is because eduroam CAT generates customised installers for all major operating systems, allowing your users to configure eduroam correctly by simply running an installer and/or installing the geteduroam. CAT automatically configures the correct security settings for your users, and is the easiest way to onboard your certificates onto user devices.
Onboarding tools like eduroam CAT are becoming increasingly important, particularly if the certificate you use is not part of the publicly key infrastructure and is not already trusted by your end users' devices. This is because modern operating systems make it difficult for users to accept an untrusted certificate on first use. CAT is, of course, not the only way to solve this problem. However, it is a freely available tool that is supported by the eduroam community.
You can enrol your institution for CAT via our management interface. You can read about how to use CAT to onboard certificates in the CAT administrator guide.
It is absolutely critical that your users validate the security certificate used for eduroam. This is typically done automatically by their operating system, and eduroam CAT will set things up correctly without your users having to know anything about the process. Without CAT, users may be prompted to check the certificate the first time they connect, and you should publish details of the correct certificate so your users know what to look for. Many operating system vendors are starting to disable the option to trust-on-first for untrusted CAs because users blindly accept certificates without adequately checking them.
We've seen a few institutions recommend disabling certificate validation to work around the problem of onboarding a certificate or continuing to use an expired certificate. This is the wrong approach and puts the security of your users' accounts at risk (and thus all the personal and other information they contain or have access to). Without certificate validation, a malicious attacker can conduct a man-in-the-middle attack against your users and decrypt their username and password from inside the EAP conversation. Because of the risks it presents, newer devices also remove the option to disable validation.
Our monitoring system will let you know if your certificate is about to expire.
From time to time it may be necessary to renew or roll over the certificate you use for eduroam.
Certificate renewals are generally relatively painless — if you've anchored your installation on a CA certificate and you continue to use a certificate signed by the same certification authority with the same common name (as is typical with a commercial certificate renewal), most operating systems will accept the new certificate without any problems. We are aware of at least one, Apple iOS, that will prompt users to reaffirm acceptance of the certificate, but most users will probably not even be aware of the renewal.
If, however, you need to change the certification authority you use, have a self-signed certificate that is expiring, or want to change the certificate subject (server name), you need to plan a proper certificate rollover. This can take some time to get right, and we recommend planning for it at least six months in advance — you may, for instance, want to time it to coincide with a change in the academic year to minimise the impact on your help desk.
Fortunately, eduroam CAT can also help with this, as it will allow you to embed both an old and a new certificate within the installer. If you update your CAT installers well in advance of the anticipated change, you can greatly reduce the impact of this change.
An advanced approach to certificate roll-over, particularly where the certification authority may change, is to use the outer identity to pre-select a particular certificate. This was an idea first seen at the University of Cambridge and can be implemented in FreeRADIUS by making some relatively minor changes.
1) Create a new named instance of the eap module in mods-enabled/eap. This instance should be identical to your default instance except for changes to the certificate location. What follows assumes the named instance is called "eap.public".
2) Edit your outer tunnel virtual server (sites-available/eduroam) and make the following changes:
a) In the authorize section, find the reference to the eap module and replace it with this stanza:
## Preselection of CA certificates based on anonymous user-name
if ("%{Stripped-User-Name}" =~ /^_public/i) {
eap.public {
ok = return
}
} else {
eap {
ok = return
}
}b) In the authenticate section, replace the reference to the eap module with this stanza:
# eap
Auth-Type eap.public {
eap.public
}
Auth-Type EAP {
eap
}Once completed, these changes allow you to use an outer identity of _public@yourrealm to preselect the eap.public named eap instance (and therefore the particular certificate it uses).
You can couple this approach with eduroam CAT's ability to set the anonymous outer identity to create versioned CAT installers that use different certificates. This very gracefully handles the transition from one certificate approach to another.