...
The third question is particularly important these days because some popular operating systems, particularly Android onesversions up until Android 7, do not allow to verify 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.
...
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 | 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. |
| 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-1 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. 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 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 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. 2048 bit is the most popular and default choice these days. However, some applications already suggest 3072 bit or more, and a longer key length does not have an extra cost. So, it is recommended to create new certificates with 3072 bit keys or higher (4096 has 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 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. |
| 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 |
Consideration 3: Which certificates to send in the EAP exchange
...
For most deployments, it probably makes more sense to include the intermediate CA certificates during the RADIUS/EAP conversation.