Certificates are used for encryption (so that the traffic can only be read by the two peers involved) and signing (so that you can be certain that a server is the one matching the address you are connecting to). With these two functions in mind, I will try to briefly answer to your different scenarios:
- What happens when someone gets to know the secret key of the web server?
- The traffic (past, current and future) to the HTTPS service may be decrypted if captured, exposing sensitive data such as credentials.
- What happens when someone gets to know the CA secret key that signs the certificate of the web server?
- An attacker may be able to sign a new certificate, and the clients that consider the CA that signed your web server will trust it. In this way a cloned portal could impersonate your service, by being certified to be yours while it is not.
- What happens when someone gets to know the secret key of a certain CA?
- This one is trickier, and kind of the general case for item 2. The
thing is that with a trusted CA private key, you could sign
certificates and they will be trusted by clients that already trust
this CA. There are two different levels of compromise here: If an
intermediate CA key was leaked, you can always revoke it using the
root key. However if the root key is compromised, that CA is done,
you have to start a new CA if you want a trustworthy signer, that is
why the root key of a CA is usually recommended to be extremely well
protected, you can generate the intermediate to sign and then
air-gap or power-off the server with the root key.
When you speak about big CAs (Comodo, VeriSign, etc), trustworthiness is vital for them, once the systems trust them, stop trusting them will require software updates. A lot of these CA scandals have effectively terminated whole companies, to mention: StartSSL and DigiNotar.
Hope it helps. Regards