EAP Server Certificate considerations

Almost all EAP types in eduroam (with the exception of EAP-PWD) require an X.509 server certificate with which the RADIUS server identifies itself to the end user before the user sends their credentials to the server.

Consideration 1: Procuring vs. creating your own server certificate

In a generic web server context, server certificates are usually required to be procured by a commercial Certification Authority (CA) operator; self-made certificates trigger an "Untrusted Certificate" warning. It makes sense for browsers to have a pre-configured trust store with many well-known CAs because the user may browse to any website; and the operator of that website may have chosen any of those well-known CAs for their website. In an abstract notion, one can say: it is required to have many CAs in the list because the user device does not have all required information for certificate validation contained in its own setup; it misses the information "which CA did the server I am browsing to use to certify the genuinity of his website?".

These considerations are not at all true in an EAP authentication context, such as an eduroam login. Here, the end user device is pre-provisioned with the entire set of information it needs to verify this specific TLS connection: the IdP has a certificate from exactly one CA, and needs to communicate both that CA and the name of their authentication server to the end user. A trust store list from the web browser is thus insignificant in this context; certificates from a commercial CA are as valid for EAP authentications as are self-made certificates or certificates from a small, special-purpose CA. For a commercial CA, the installation of the actual CA file may be superfluous in some client operating systems (particularly those who make their "web browser" trust store also accessible for EAP purposes), but marking that particular CA as trusted for this specific EAP authentication setup still needs to be done.

Note that also root CA certificates have an expiry date. Both for commercial and private CAs please be aware that an exchange of the root CA certificate will require re-configuration of all your end-users' devices to accept the new CA. As a consequence: for commercial CAs, check their root CA's expiry date so you can make an informed decision whether you want to buy the certificate from them or not. For your own private-use CA: choose a very long expiry date for the CA.

Especially for commercial CAs, keep in mind that if you ever want to switch to a different CA as a trust anchor, all your end-user devices again need to be re-configured for that new root.

Configuration tools like eduroam CAT enable to provision the chosen CA(s) and the expected server name(s) into client devices without user interaction. In that light, it does not make much difference whether to procure a server certificate from a commercial CA or to make your own; either way, configuration steps are necessary on the end-user device to enable and secure your chosen setup. With the conceptual differences being small, a number of secondary factors come into play when making the decision where to get a server certificate from.

Factors to consider for a creating and using a private CA to issue a private Server certificates:

1. Do you have the necessary expertise to create a self-signed certificate; or to set up a private Certification Authority and issue a server certificate with it?
   1. For details on properties to impose on the the certificate, see "Consideration 2: Recommended certificate properties" below
2. Does your eduroam NRO operate a special-purpose CA for eduroam purposes so that you could get a professionally crafted certificate without much hassle?
3. Do your end-user devices all verify the exact server identity (issuing CA certificate AND expected server name)?

The third question is particularly important these days because some popular operating systems, particularly early Android versions up until Android 7, do not allow to configure verification of the expected server name in their UI. For such operating systems, using a commercial CA for the server certificate opens up a loophole for fraud: anyone with a valid certificate from this CA, regardless of the name in the certificate, can pretend to be the eduroam authentication server for your end-user; which ultimately means the end-user device will send the user's login credentials to that unauthorised third-party. If you use a self-signed certificate or private CA however, which issues only one/very few certificates, and over which you have full control, then no unauthorised third party will be able to get a certificate in the first place, and thus can't fraud your users.

Another factor to consider when making the decision private vs. commercial CA is that of size and length of the EAP conversation during every login: with a private CA, you will be able to construct a certificate chain without intermediary CA certificates; requiring less bytes to be transmitted inside the EAP conversation (see Consideration 3, below). This results in fewer EAP round-trips and thus a faster authentication.

Recommendations:

1. if you have the required expertise: it is suggested to set up a private CA exclusively to issue an appropriate IdP Server certificate for the eduroam RADIUS server
   1. Qualities a private CA possesses:
      1. A very long lifetime to prevent certificate rollover problems.
      2. Presence of Basic Constraints CA:TRUE per  RFC5280, section 4.2.1.9   to satisfy the required validation of the CA such that it can use it appropriately 
   2. The CA should issue only server certificates for your eduroam IdP server(s).
2. If you do not have expertise: consider making use of your NROs special-purpose CA, if one exists.
3. If none of these work for you:  a certificate from a commercial CA is a commonly used third option.

With great power comes great responsibility. (Voltaire)

If you choose to use a private CA and deploy it to your users' devices, there may be side-effects after the installation of the CA.

Some devices do not differentiate between a CA which is used for Wi-Fi server authentication purposes and, say, web browser TLS encryption.

Your CA may incidentally yield the power on such client devices of your own user base to inspect their web or other traffic (if you actively abuse it and modify your IT infrastructure to enable this). We do not endorse or encourage this in any way.

Having your own trusted root CA in client devices also makes the protection of the private key to this CA an objective of paramount importance.

We recommend that you inform your users how best to restrict the power of the CA (e.g. with CA installation instructions which point to a dedicate Wi-Fi store [Android 4.3+]; or with the advice not to use browsers which use the built-in CA store of the device [MS Windows]).

Specific Issues with Commercial CAs

When Identity Providers choose to deploy certificates from a public CA, eduroam does not recommend any particular CA. All public CAs provide very similar services. However, as we become aware of known caveats or technical specialities with particular CAs, we try to list them here.

Sectigo / "AAA Certificate Services"

This CA has cross-signed a previously intermediate CA certificate as its own root certificate in 2020. This leads to a new, shorter, CA chain path stopping at the root variant of "USERTrust RSA Certificate Authority". The older CA chain path with a CA of that same name as an intermediate variant, and a root CA certificate named "AAA Certificate Services" continues to be offered by Sectigo only for compatibility with very old legacy systems which are unaware of the root variant of USERTrust. It is NOT RECOMMENDED to download and use the longer chain as Windows 10 has known issues building a trusted path when the USERTrust CA happens to be installed as a root variant already (which becomes increasingly common over time). Identity Providers using certificates from this CA should NOT include the intermediate CA variant of "USERTrust RSA Certificate Authority" in their onboarding tool and EAP server configurations. All contemporary supplicants include this CA as a root CA and can build a trust chain with it.

In summary:

• The RADIUS/EAP server should send the server certificate and the intermediate(s) below USERTrust RSA Certification Authority. This is typically only one intermediate certificate with names "GEANT OV RSA CA 4" or "Sectigo RSA Organization Validation Secure Server CA"
• When using eduroam CAT as the onboarding tool, include only the root variant of USERTrust RSA Certificate Authority

Consideration 2: Recommended certificate properties

Various end-user device operating systems impose different requirements on the contents of the server certificate that is being presented. Luckily, these requirements are not mutually exclusive. When creating or procuring a server certificate, you should check with the CA that its certificates satisfy as many of these requirements as possible to ensure broad compatibility with your users' devices. The list below does not include "standard" sanity checks applied to certificates; e.g. well-formedness of the data, validity timestamps etc. These checks are done "as per usual" in every TLS connection.

The most important property of the server certificate is the name of the server. Since this certificate is not for a webserver, there is no necessity to put an actual hostname into the server name. Also, when an Identity Provider uses multiple servers for resilience reasons, then all these servers can and should have a certificate with the same name; and it may well be the identical certificate. Having different names for different servers means that end-user devices must be configured to trust multiple servers, which is more cumbersome than just having to configure one name string.

Some end-user device operating systems might (incorrectly) require the name to be parseable as a hostname; so it is a good idea to use a server name which parses as a fully-qualified domain name - the corresponding record does not have to exist in DNS though. The server name should then be both in certificate's Subject field (Common Name component) and be a subjectAltName:DNS entry as well. The case of both should match.

The following additional certificate properties are non-standard and are of particular interest in the eduroam context:

Consideration 3: Which certificates to send in the EAP exchange

End-user devices need to verify the server certificate. They do this by having a known set of trustworthy anchors, the "Trusted Root Certificates". These root certificates need to be available and activated on the device prior to starting the eduroam login. Therefore, it does not serve any useful purpose to send the root CA certificate itself inside the RADIUS/EAP conversation. It is not harmful to send it anyway though, except that it unnecessarily inflates the data exchange, which means more round-trips during eduroam authentication, and in turn a slower login experience. One possible exception is: there are reports of certain Blackberry devices for which it is advantageous to send the root CA certificate nonetheless; if you expect you need/want to support Blackberry devices, sending the root CA may be of help.

During the EAP conversation, the eduroam IdP RADIUS server always needs to send its server certificate.

One question needs an administrative decision: if there is one or more intermediate CAs between the root CA and the server certificate (such as is the case with, for example, the TERENA Certificate Service (TCS) and many commercial CAs), should the intermediate CA certificates be sent to the end user device during the EAP conversation, or should the devices pre-install the intermediate CAs along with the root certificate?

In any case, for a successful verification of the server certificate, the end-user's device must have the full set of CA certificates available. It does not matter whether the intermediate CAs have been pre-provisioned or are sent during the login phase; but if any one intermediate CA is missing, the verification of the server certificate will fail.

Pre-provisioning the intermediate CAs has the advantage of a relatively small amount of data being sent during the EAP authentication, which means fewer round-trips between the end-user's device and the eduroam IdP RADIUS server. The downsides of this approach are that any changes to intermediate CAs (re-issue, rollover) will also need to be pushed to end-user devices. Also, if end-user devices are not under administrative control of the IdP, there is a danger that some end users do not follow the advice to install all intermediate CAs even though they should, and end up in a situation where the server certificate can not be validated.

Sending the intermediate CAs during the login phase means a longer time to authenticate due to more round-trips, but means that it is sufficient for client devices to install the root CA certificate; if intermediate CAs change, the new ones will always become available to the device during the next authentication data exchange.

For most deployments, it probably makes more sense to include the intermediate CA certificates during the RADIUS/EAP conversation.