This question indicates parents are to buy laptops for a school to install software and certificates. I am seeking to understand reasons for site certificates installation:
I am seeking to understand both legitimate (constructive) reasons for certificates and potential for misuse / abuse. It is unclear from the thread how schools could somehow decrypt traffic with certificates.
There are two different kinds of certificates you could install on a machine:
The first type of certificate is root certificate authority. A root certificate contains just a public key of the certificate authority. A root certificate is a trust anchor that is installed in your machine so that your machine can identify "trusted" sites to connect to, a certificate authority can issue a claim in the form of a server certificate that "X is owner of domain Y" and because your machine trusts the root certificate authority, it'll trust that claim. If the school/company installs a root certificate to your machine, your machine will trust whatever connections made to the school/company's server thinking that it is legitimate. If you install a root certificate, the school/company would be able to intercept any SSL/TLS connections made by your machine that runs through their network without triggering browser certificate errors/warning.
The second type of certificate is client certificate. A client certificate contains a private key that is unique to you and a certificate signed by the school/company's certificate authority. A client certificate is used for your machine to authenticate to the school's infrastructure, proving that it is you that is connecting. A client certificate is used as essentially a better solution to authentication credential than having to remember passwords. A client certificate cannot be used by the school/company to eavesdrop on connections made by your machine to servers that aren't owned by the school/company.
A client certificate is fine to install and shouldn't cause any security concerns. In contrast, be very wary of installing a root certificate, as it is a cause for concern as the root certificate can easily be abused.
Well there is at least a legitimate use case. It is common for large organizations and university to run a private PKI. That means that they have a (secured) root certificate that is used to sign (with enventual sub authorities) various certificates.
And it is also common to use that private PKI to sign HTTPS servers which are not intended to by publicly used: the only requirement is that the (internal) clients all declare the private root certificate.
The risk is a MITM attack on HTTPS connections. In fact it is often presented as a feature by security admins. Many of them would never allow HTTPS connections from a secured environment if they cannot be deeply inspected (*). That actually means that when you HTTPS from the internal network through the dedicated proxy, everything can be logged. The only rule is that users shall be warned about it. It something is really private, it should simply not be done from the internal network.
It is common to use a strong peripheral security on large organizations through filtering proxies. Those proxies analyzes the peer and the kind of traffic in order to prevent various attacks and infections. But as HTTPS is crypted the proxy cannot know what is actually exchanged unless the MITM attack is active.
*.mydomain.local with no need to install a root certificate.
If the browsers of student's systems has a school certificate in the trusted root of the certificate installation (depending on the browser this cert might need to be the system's certificate bundle, or the browser's) then if traffic is going via an intercepting proxy (such as via on the school's wifi), the school is able to decrypt the traffic with the private key. Connections to the websites are therefore not secure end-to-end, but the proxy can re-establish a secure connection to the website itself and keep the data secure in transit at least. These devices are also known as SSL-Decrypters (although really its TLS/SSL), and almost every organisation i've worked with uses these in some capacity (i'm a penetration tester, i work in a lot of banks).
There are a number of reasons why you would want to do this, but most installations boil down to companies wanting to snoop on users to more easily spot potential security incidents (malware on the wire) or just detect improper usage.
I was a school kid once and half of what i did on those computers was not school work at all, if schools can work out how to tackle the problem of kids using systems (even their own) for illegitimate tasks, its a good thing in my book. I'm a huge privacy advocate, but the school will only have these decrypting powers when you are connected to the internet via their proxy. So if you are connected to a network you don't trust and don't own, on a system you didn't provision yourself, you are playing by (and agreeing to) someone else's rules.
It depends on what you mean by "site certifite", but this answer is for the case of a root certificate authority:
Most schools - at least in the UK - I don't know about other countries, use some form of web filtering. This typically involves a firewall/proxy that intercepts web traffic and inspects the content of the page.
However HTTPS provides end-to-end encryption between the user's computer and the website, as a result when connecting to a HTTPs website all the proxy would be able to see is the destination IP address, but no information about the contents of the web page.
It would not be practical to simply block all HTTPS traffic, so instead to maintain the filtering system requires the school to break the end-to-end encryption model, by terminating the encryption at the firewall/proxy. It then passes on the connection to the user, but it has to be using their own certificate. This setup enables them to read all communication between the user's computer and the website. (A man-in-the middle attack)
HTTPs certificates are used to prevent this occurring maliciously - because the certificate presented was signed by the school's firewall/proxy (rather than a trusted certificate authority, e.g. Verisign) the laptop's software will not trust the connection (you would see a security warning/error message in your browser). However by installing the school's certificate as a trusted root authority, the connection would instead be trusted and your browser would then function as normal.
The consequence of this is that any HTTPS communication from your laptop can be intercepted and read by the school (even though it appears in the browser as being secured).
More generally anyone who had access to the school's certificate and private key, and also had physical access to intercept your laptop's internet traffic, would be able to read your SSL/TLS communications.
Have a look at this vendor for example: https://www.rm.com/products/online-safety-tools/rm-safetynet/ssl-interception
To avoid this, don't install their certificates, and instead use an OpenVPN connection over a port that they are not blocking (try 53, 80, 8080, 443 etc.)
There are two reasons:
The innocuous reason is that the schools is implementing certificate-based authentication and have their own PKI. The clients need the PKI-root certificate to verify the server certificates they are presented.
The malicious reason is SSL interception. With a root certificate installed, browsers can be redirected to a proxy, where SSL is intercepted and the content inspected before it is re-encrypted and sent to the actual server (or vice versa).
Unfortunately, you can't get one without the other. A root certificate is a root certificate. Your countermeasure is to not use this computer for sensitive things, such as online banking or private messaging.
(Posting this as an answer by request, and also since the original comment seems to have been well-received and I wouldn't want it to get deleted in a comment purge.)
In response to Lie Ryan noting that there are two basic types of certificates, root certificates and client certificates, and that client certificates are fine but you should be wary of custom root certificates because they have a potential for abuse, I added:
I would state that last line a bit more strongly: a root certificate that is under the control of the same people who own the network used to connect to the Internet should be regarded as spyware. It should be avoided if at all possible, and if it's not possible, the machine should be treated as compromised and used as little as possible. There's no legitimate reason to require you to put one on your own personal property. If the school wants to do that, they can supply the laptops themselves.
Another commenter asked what the link is between spying potential and being the operator of the network. So, some further expounding:
What a root certificate means is that the certificate owner not only certifies that its site is legitimate, but also has the authority to issue other certificates. This is how Certificate Authorities and the entire certificate infrastructure works: by installing the root certificate you say that you trust the judgment of the CA, and the CA then certifies that ordinary sites are legitimate, which you accept because a trusted CA said so.
The thing is, there's no technical requirement anywhere in that process involving input from the owner of the site. That's where the trust part comes in; we accept on faith that they've authenticated the site before issuing a certificate for it, and the few times when a CA has been caught failing to do so, retribution from the Internet has been swift and decisive, bringing consequences up to and including the CA going out of business for betraying the trust of essentially the entire world.
But if your main business isn't being a CA, that changes the calculus. If you run a network and can issue a rogue root CA on your clients' computers, you gain the ability to perform a man-in-the-middle attack. It works like this:
This will only work on the certificate owner's network because other networks that don't have a root certificate installed on your machine aren't going to be serving up phony site certificates.
You can make a parallel with a company. Why would a company need to install certificates on employee laptops (or personal devices)?
It comes to authentication. A certificate can be used as a credential to access a secure resource (school/company portal) without the need to provide a password. We all know the disadvantages of using passwords, thus a certificate (or another credential) is issued to each student that will identify him/her when accessing school web applications (mostly).
In the company I work for, prior to moving our authentication infrastructure to SAML 2.0, if we wanted (for convenience) to access enterprise related web applications using our personal mobile devices, a company certificate was installed in the device.
