Having worked on wireless networks at multiple schools, I can say there are two types of certificates that you may be asked to install to connect to their wireless networks:
- A client certificate used when authenticating your device to the wireless network.
- A trusted CA certificate use to help validate the identity of a server.
In the first case, this may be a certificate tied to you as a user, to your device individually or to both. The certificate alone may provide your authentication or you may also be required to provide a username/password. Since this is generally considered one of the more secure forms wireless authentication can take, you have no reason to be concerned about this type of certificate.
The second case is where you may want to question further, but is also likely nothing too concerning. The big distinction here is if the CA certificate is being used during the authentication process to the wireless network (good use) or if it is being used to access the Internet (questionable use). I am going to skip discussing the latter as this topic has been covered by a number of question/answers on this site (I don't have time to look up examples at present, so anyone feel free to edit some in if you like).
Most often this CA certificate is being used to validate the identity of the RADIUS authentication server to which your EAP supplicant is authenticating. Generally speaking, the EAP supplicant must make a decision on whether it will send your username/password to the authentication server without being connected to the network. This means it is only able to work with information it has and information it is given by the authentication server, it can't go out on the Internet to check another source until after it has authenticated and it is too late to withhold your username/password.
The EAP supplicant does this primarily by checking two things (with a couple options present in many EAP supplicants like Windows and OSX, but often not on mobile devices like tablets and phones):
- Is the certificate provided by the authentication server a valid certificate issued from a CA trusted by the client device?
- (Optional) Is the certificate issued from the designated CA(s) in the EAP supplicant?
- Does the hostname listed on the certificate match the hostname given by the authentication server?
- (Optional) Is the hostname given by the authentication server one of the hostnames allowed in the configuration of the EAP supplicant?
The other options for the EAP supplicant are to either have the OS prompt the user to "check and approve" the certificate (bad idea) or to not validate the certificate at all (worse idea) before sending your username/password.
So why would a school choose to setup their own CA and issue certificates for the authentication servers? Several reasons:
- Cost - it used to be there were a small number of CAs that could be expected to be installed on almost all operating systems. Getting certificates that provide for authentication service (not just HTTPS web traffic) from these could be expensive, especially if the school runs a large number of authentication servers (as generally you need a certificate per server).
- Reduced end user impact - most CAs will only issue certificates for a maximum of three years. When the certificate on a wireless authentication server changes, at the very least the end user will be notified of the change and prompted to accept the new certificate. In some cases, the EAP supplicant will simply fail to connect to the wireless network until reconfigured. Schools that run their own CA can choose to issue certificates with expirations further out than 3 years, reducing the number of times their end users are impacted by a certificate change.
- Increased security - if the school uses a public CA to issue their authentication certificates, then an "attacker" will find it easier to "impersonate" the school network.
Let me discuss this last point a bit more as it is the key reason to do so (at least in my mind). I apologize for being redundant, but this is the key point. Since the EAP supplicant isn't connected to a network before deciding to pass along your username/password, it is limited in the information it can use to make this decision. As such, it can be easily "tricked" into doing so by an attacker.
It is trivial (and in some cases entirely free) for an attacker to get a valid certificate from a public CA that can match the hostname of the attacker's own "authentication server." If specific hostnames for the authentication servers are not configured in the EAP supplicant (and they often are not or can't be), then even if the designated CA is configured and is a public CA, the attack just needs to get their certificate from the same public CA. End result is compromised user credentials.
An attacker will have a much more difficult time getting a valid certificate issued from the private CA of the school and if that private CA is the only designated CA in the EAP supplicant, then it makes it very difficult for an attacker to pretend to be the real wireless network and capture credentials for those clients.