My university used to recommend explicitly selecting "do not validate" for the longest time, even though validation through the system store (or a certificate of your choice) has existed for years.
For what it's worth, if you're using a valid TLS certificate for your 802.1x setup then you don't need to load any certificates anymore (at least not since Android 10 or 11). Users may need to enter a ___domain to validate, though; I don't know the specifics of these protocols.
Not every modern Android device offers the “use system CA store” option. And chromebooks don’t. We just gave up and kept loading the certificate.
You also have to understand that “valid” doesn’t really mean anything. When android supports the system CA store, they’re the first and only OS to do it this way. It doesn’t make a ton of sense to try to do this because there is no ___domain to validate. Unless it’s preconfigured, in which case you may as well have loaded a root CA.
That’s what we’re doing now (preconfiguring the root CA). Then the server sends a valid cert and trust chain, just not within the typical global PKI infrastructure.
From what I'm reading about this online the ___domain validation thing is part of the WPA3 spec, though it's clearly more visible on Android. Perhaps they removed their WPA2 code path and stuck to WPA3 exclusively but I think this is a way forward rather than a problem; it's too easy to accidentally import a root certificate authority into the trust store when you're trying to get the WiFi going and that's a security risk. The stupid warnings should still disappear when you import the CA as an EAP certificate of course. I'm pretty sure most modern operating systems will (some day soon) connect to enterprise networks configured the way Android likes it without ever needing to install a certificate, which is an obvious benefit to me. The ___domain itself is either the entered ___domain or the ___domain of the identity you entered, I believe this is also based on some part of WPA3.
Validating the common name through the system CA store is also an option on Linux, though you have to select the system certificate store manually instead of specifying a PEM file that you can never move again.
I don't know about Chromebooks but I think the system CA validation setting is standard in Android since either Android 10 or Android 11. Android 11 added validation of the certificate (presumably through OCSP stapling?) but that's disabled by default. If you're not on Android 10+ I'm not sure if I'd call that a "modern" Android version anymore with how quickly manufacturers drop support for older Android versions. I'm pretty sure Google already dropped security support for Android 9 anyway.
It's possible that some manufacturers broke the setting, but if they did they should've added their own replacement. You can't blame Google for broken Android forks imo.
Unfortunately this wouldn’t help us because we are an eduroam identity provider. The SSID is always eduroam but the cert presented is different, based on your username, because your login is handled by your home institution (the IdP responsible for your identity).
But I believe Android does care about the ___domain an Eduroam user said their user is in. So, if your user says I'm [email protected] I think it will expect the certificate from the 802.1X server (at MIT) to have a certificate for mit.edu, which is what will happen in Eduroam.
The certificates used are PKIX certificates, they say they're for TLS Server Authentication (which they technically are) and the subjects are DNS server names (these are, after all, servers on the Internet) and so realistically the only PKI exercising any oversight over such certificates so that it could Just Work™ which is what your users want, is the Web PKI.
For what it's worth, if you're using a valid TLS certificate for your 802.1x setup then you don't need to load any certificates anymore (at least not since Android 10 or 11). Users may need to enter a ___domain to validate, though; I don't know the specifics of these protocols.