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 his 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 his 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 his 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.
...
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. Leave sufficient time for a rollover period in which your CAT profile (if you use one) contains both the old and new commercial CA root certificate(s).
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:
- 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?
- For details on properties to impose on the the certificate, see "Consideration 2: Recommended certificate properties" below
- Does your eduroam NRO operate a special-purpose CA for eduroam purposes so that you could get a professionally crafted certificate without much hassle?
- Do your end-user devices all verify the exact server identity (issuing CA certificate AND expected server name)?
...
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.As a general recommendation
Recommendations:
- if you have the required expertise: it it is suggested to set up a private CA exclusively to issue an appropriate IdP' IdP Server certificate for the eduroam RADIUS server
- Qualities a private CA possesses:
- A very long lifetime to prevent certificate rollover problems.
- Presence of Basic Constraints CA:TRUE per RFC5280, section 4.2.1.9 to to satisfy the required validation of the CA such that it can use it appropriately
- The CA should issue only server certificates for your eduroam IdP server(s).
- Qualities a private CA possesses:
- If you do not have expertise: consider making use of your NROs special-purpose CA, if one exists.
- If none of these work for you: a certificate from a commercial CA is a commonly used third option.
...
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:
Certificate Validity length
As of Q1 2025, all public CAs have committed to follow the CA/B Forum's recommendation to reduce server certificate lengths progressively to 47 days within the next few years.
This will, if you do not employ certificate renewal automation via a mechanism like SCEP or ACME/CertBot, increasingly cause administrative and technical issues for you. Consider looking at SCEP, ACME or CertBot, and you should also consider support for any of these methods for automated certificate renewal to be an important criterion when choosing a commercial CA.
See the CA/B Forum's vote here: https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
Communications from Sectigo: https://www.sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days
Communications from DigiCert: https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
Sectigo / "AAA Certificate Services" certificates issued by the GÉANT Certificate Service before January 2025
Sectigo, the commercial CA backing the GÉANT Certificate Service before January 2025, 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
- WARNING: This shorter root will not seamlessly validate certificates subsequently issued by Sectigo themselves, and you must include the R46 and R36 intermediate certificates provided with your server certificate in your profile.
HARICA certificates issued by the GÉANT Certificate Service
HARICA is the CA backing the GÉANT Certificate Service since January 2025. The server certificate issued by the service comes with the GEANT intermediate certificate. It is recommended to also add the Cross Certificate from HARICA Root CA 2015 to 2021 as a second intermediate certificate to the RADIUS server after the GÉANT intermediate certificate. This way, supplicants with knowledge of only the Root CA 2015 could still connect securely. However, it is recommended to put only the HARICA TLS Root CA 2021 to eduroam CAT for usage during onboarding.
In summary:
- The RADIUS/EAP server should send the server certificate, the HARICA GEANT TLS intermediate certificate and the Cross Certificate from HARICA Root CA 2015 to 2021 as second intermediate certificate
- ECC certificates: GEANT.pem (GEANT.txt) Cross-Certificate-from-HARICA-Root-CA-2015-to-2021.pem (Cross-Certificate-from-HARICA-Root-CA-2015-to-2021.txt)
- RSA certificates: GEANT.pem (GEANT.txt) Cross-Certificate-from-HARICA-Root-CA-2015-to-2021.pem (Cross-Certificate-from-HARICA-Root-CA-2015-to-2021.txt)
- When using eduroam CAT as the onboarding tool, upload the HARICA TLS Root CA 2021 to CAT
- ECC: Root-CA.pem (Root-CA.txt)
- RSA: Root-CA.pem (Root-CA.txt)
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:
| Property | Content | Remarks | ||||
|---|---|---|---|---|---|---|
| X.509 version | 3 | The CA certificate should be an X.509v3 certificate. | ||||
| Server name (commonName in the Subject) | parses as fully-qualified domain name | Server certificates with spaces in the common name (CN), e.g. "RADIUS Service of Foo University" are known to be problematic with some supplicants, one example being Apple iOS 6.x. | ||||
| Server name | Subject/CN == SubjectAltName:DNS | Some supplicants only consult the CN when checking the name of an incoming server certificate (Windows 8 with PEAP); some check either of the two; some new EAP types such as TEAP, and Linux clients configured by CAT 1.1.2+ will only check SubjectAltName:DNS. Keeping the desired name in both fields in sync is a safe bet for futureproofness. Only use one CN. If you have multiple RADIUS servers, either use the same certificate for all of them (there is no need for the name to match the DNS name of the machine it is running on), or generate multiple certificates, each with one CN/subjectAltName:DNS pair. In the case of multiple certificates, make sure you add a SubjectAltName in the Extended Key Usage extension that is common between all of them, so that you can use it in the eduroam CAT profile. Make sure the case of the Subject/CN and the SubjectAltName matches, e.g. "CN=servername.org" and "DNS:Servername.org" do not match (despite being effectively identical in DNS). Android 12 is known to be picky about this. | ||||
| Server name | not a wildcard name (e.g "*.someidp.tld") | Some supplicants exhibit undefined/buggy behaviour when attempting to parse incoming certificates with a wildcard. Windows 8 and 8.1 are known to choke on wildcard certificates, and it is difficult to use the defined wildcard CN in the eduroam CAT profile. | ||||
| Signature algorithm | Minimum: SHA-256 Recommended: SHA-256 or higher | Server certificates signed with the signature algorithm MD5 are considered invalid by many modern operating systems, e.g. Apple iOS 6.x and above. Windows 8.1 and all previous versions of Windows (8, 7, Vista) which are on their latest patch levels will not validate such certificates either. Having a server certificate (or an intermediate CA certificate) with MD5 signature will create problems on these operating systems. Apparently, no operating system as of yet has an issue with the root CA being self-signed with MD5. This may change at any point in the future though; when creating a new CA infrastructure, ensure that you do not use MD5 as signature algorithm anywhere. The continued use of SHA-1 as a signature algorithm is not recommended, because several operating systems and browser vendors already have a deprecation policy for SHA-1 support. It is now the case that system libraries and operating system APIs are starting to penalise the use of SHA-1, e.g. Android 12 is known to block certificates signed with SHA-1. Therefore, for new certificates, SHA-256 is recommended to avoid problems with the certificate in the future. | ||||
| Key Algorithm | Minimum: RSA Recommended: ECC | RSA certificates (so named after the key algorithm of the key material in the certificate) have long been the standard for certificates across the world. However, as key sizes (below) grow, so does the certificate size. As the certificate sizes increases, the chances of RADIUS packets being fragmented increase, which in turn causes issues with some firewalls performing packet or SSL/TLS inspection and UDP fragment DDoS protection (Microsoft Azure cloud services for example will throw away UDP packets when packet fragments do not arrive in the specific order that they should be reassembled in). The vast majority of modern devices and operating systems support ECC certificates (also known as ECDSA certificates). ECC certificates are based on elliptic curve cryptography (hence the name), which uses maths behind defining specific curves to generate keys, which in turn are a lot smaller (but not less secure than large RSA keys) and are less likely to suffer from fragmentation. If your users are all using modern devices (Android 8, Windows 8, iOS 9 and above), you probably can/should change your server certificate to one using ECC, even if the root certificate is an RSA certificate. | ||||
| Length of public key (applicable to RSA certificates) | Minimum: 2048-bit Recommended: 3072-bit | |||||
| Property | Content | Remarks | ||||
| X.509 version | 3 | The CA certificate should be an X.509v3 certificate. | ||||
| server name | parses as fully-qualified domain name | Server certificates with spaces, e.g. "RADIUS Service of Foo University" are known to be problematic with some supplicants, one example being Apple iOS 6.x. | ||||
| server name | Subject/CN == SubjectAltName:DNS | Some supplicants only consult the CN when checking the name of an incoming server certificate (Windows 8 with PEAP); some check either of the two; some new EAP types such as TEAP, and Linux clients configured by CAT 1.1.2+ will only check SubjectAltName:DNS. Keeping the desired name in both fields in sync is a safe bet for futureproofness. Only use one CN. If you have multiple RADIUS servers, either use the same certificate for all of them (there is no need for the name to match the DNS name of the machine it is running on), or generate multiple certificates, each with one CN/subjectAltName:DNS pair. Make sure the case of the Subject/CN and the SubjectAltName matches, e.g. "CN=servername.org" and "DNS:Servername.org" do not match (despite being effectively identical in DNS). Android 12 is known to be picky about this. | ||||
| server name | not a wildcard name (e.g "*.someidp.tld") | Some supplicants exhibit undefined/buggy behaviour when attempting to parse incoming certificates with a wildcard. Windows 8 and 8.1 are known to choke on wildcard certificates. | ||||
| signature algorithm | Minimum: SHA-256 Recommended: SHA-256 or higher | Server certificates signed with the signature algorithm MD5 are considered invalid by many modern operating systems, e.g. Apple iOS 6.x and above. Also Windows 8.1 and all previous versions of Windows (8, 7, Vista) which are on current patch levels will not validate such certificates. Having a server certificate (or an intermediate CA certificate) with MD5 signature will create problems on these operating systems. Apparently, no operating system as of yet has an issue with the root CA being self-signed with MD5. This may change at any point in the future though, so when creating a new CA infrastructure, be sure not to use MD5 as signature algorithm anywhere. The continued use of SHA-1 as a signature algorithm is not recommended, because several operating systems and browser vendors already have a deprecation policy for SHA-1 support. It is now the case that system libraries and operating system APIs are starting to penalise the use of SHA-1, e.g. Android 12 is known to block certificates signed with SHA-1. Therefore, for new certificates, SHA-256 is recommended to avoid problems with the certificate in the future. | ||||
| length of public key | Minimum: 2048 Bit Recommended: 3072 Bit or higher | Server certificates with a length of the public key below 1024 | bit bits are considered invalid by some recent operating systems, e.g. Windows 7 and above. Having a server certificate (or an intermediate CA certificate) with a too small public key will create problems on these operating systems. The continued use of 1024-bit length keys is not recommended, because several operating systems and browser vendors already have a deprecation policy for this key length. While the deprecation in browser-based scenarios does not have an immediate impact on EAP server usage, it is possible that system libraries and operating system APIs will over time penalise the use of short key lengths. A 2048-bit key length is the most popular and default choice these days. However, some applications already suggest 3072 | bit bits or more, and a longer key length does not have an extra cost | . So, it (other than certificate size). It is recommended to create new certificates with 3072-bit keys or higher (4096 | has -bit lengths have been tested and is also unproblematic) to avoid problems with the certificate in the future. |
| Extension: Extended Key Usage | TLS Web Server Authentication | Even though the certificate is used for EAP purposes, some popular operating systems (i.e. Windows XP and above) require the certificate extension "TLS Web Server Authentication" (OID: 1.3.6.1.5.5.7.3.1) to be present. Having a server certificate without this extension will create problems on these operating systems. | ||||
| Extension: CRL Distribution Point | HTTP/HTTPS URI pointing to a valid CRL | Few very recent operating systems require this extension to be present; otherwise, the certificate is considered invalid. Currently, Windows Phone 8 is known to require this extension; Windows 8 can be configured to require it. These operating systems appear to only require the extension to be present; they don't actually seem to download the CRL from that URL and check the certificate against it. One might be tempted to fill the certificate extension with a random garbage (or intranet-only) URL which does not actually yield a CRL; however this would make the certificate invalid for all operating systems which do evaluate the extension if present. So the URL should be a valid one. | ||||
| Extension: BasicConstraint (critical) | CA:FALSE | Server certificates | need to must be marked as not being a CA. Omitting the BasicConstraint:CA totally is known to cause certificate validation to fail with Mac OS X 10.8 (Mountain Lion); setting it to TRUE is a security issue in itself. Always set the BasicConstraint "CA | " to false, and mark the extension as critical" to false, and mark the extension as critical, where possible. On Windows, the built-in certificate authority has a bug in that if you want to mark the BasicConstraint extension as critical, it will also set pathlen=0, which is not RFC-compliant and subsequently causes issues. If you use a Windows Certificate Authority, do not mark the BasicConstraint extension as critical in your certificate request. | ||
| Certificate Type | Domain-Validated (DV) or Organisation-Validated (OV) | There have been several reports that ChromeOS will refuse to accept Extended Validation (EV) certificates. You should avoid these types of certificates if you care about this operating system. | ||||
| Validity Time | 825 days or fewer | Apple products as of macOS 10.15+ and iOS 13+ enforce this limit and consider certificates with a longer lifetime as untrusted. See also | . | for more information, or read about Michal Spacek's investigation and experience (granted, with Safari, but it apparently also applies to iDevices) at his blog: Michal Spacek: The validity period of user added CA certificates is 2 years |
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 must always needs to send its server certificate.
...