On certain websites, clicking on the pad informs me that the site is being securelyconnected through a key exchange, ECDHE, and these keys are signed with RSA. But, when i open the full certificate for the site, the public key is RSA 2048 bits. This confused me, as i thought the public key should be ECC 256 bits, and not an RSA key, as the key exchange is ECC, and not RSA.
In the early days of SSL/TLS the server's long term private key was used directly in the key exchange process to establish a shared secret between client and server. The downside of this approach is that if an attacker managed to compromise the server's private key they could go back and decrypt any previous sessions.
So nowadays, the best practice is to use a randomly generated "ephemeral" key for the key exchange process. The server's long term key is used to sign the key exchange process and hence provide protection from man in the middle attacks.
It would be possible to devise an ephemeral key exchange scheme based on RSA alone, but it would perform badly because generating RSA keys is an expensive operation. Generally, for a given security level, ECDH is considered the least expensive option for ephemeral key exchange. traditional DH is also used.
If a system was being designed from scratch, then ECDSA would likely be the obvious choice for signing the key exchange, and indeed ECDH with ECDSA is a supported option in modern TLS clients and servers.
However many server admins don't want to be bothered with maintaining multiple different certificates for modern and legacy clients. So ECDH with RSA remains a common option.