Page History

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.

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.

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.

Minimum: 2048-bit

Recommended: 3072-bit or higher

Server certificates with a length of the public key below 1024 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 bits or more, and a longer key length does not have an extra cost (other than certificate size). It is recommended to create new certificates with 3072-bit keys or higher (4096-bit lengths have been tested and is also unproblematic) to avoid problems with the certificate in the future.

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.

Server certificates 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, 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.

Apple products as of macOS 10.15+ and iOS 13+ enforce this limit and consider certificates with a longer lifetime as untrusted.

See also this Apple article 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