How many keys are used in this specific TLS 1.2 connection?

There are at least three keys:

1. X.509 public key: known to all parties who can connect and to the server: used to identify the server and as part of initial key exchange (first half of assymmetric key pair).
2. X.509 private key: known only to the server: used to prove that the server is entitled to represent itself as the subject of the public key (second half of assymmetric key pair)
3. session key: known to both the server and the single client of the connection: a symmetric key negotiated via key exchange and replaced based on cipher suite configuration. Used to encrypt data sent over the TLS connection

The session key can be replaced seamlessly during the session in certain configurations. This can be used to provide PFS (perfect forward secrecy) in cipher suites that support it.

There is no inherent bound on the number of session keys that can be used for a single connection.

In some configurations one or more X.509 CA intermediate public keys (chain) are also in the signing chain of the server's public key. These are known to all parties who connect to any server signed by the same chain and to the server. The server must provide these keys during TLS handshake. In all configurations of a CA validated TLS connection the chain will be signed at the root by a root CA which your client software is configured to trust inherently.

If you are including CA certs there are at least four keys and possibly more if intermediate CA certs are used.

All together there should be sixteen (16) keys that come in to play:

(a) GeoTrust Global CA signing key, used to self-sign GeoTrust’s certificate, and to sign Google Internet Authority G2’s certificate. Only Geo trust knows it.

(b) GeoTrust Global CA verification key, used to verify the signatures on GeoTrust’s certificate, and Google Internet Authority G2’s certificate. Everyone knows it.

(c) Google Internet Authority G2’s signing key, used to sign Google.ca’s certificate. Only Google Internet Authority G2 knows it.

(d) Google Internet Authority G2’s verification key, used to verify signature on google.ca’s certificate. Everyone knows it.

(e) Google.ca’s signing key, used to sign Google.ca’s ephemeral elliptic-curve Diffie-Hellman (ECDHE) public key. Only google.ca knows it.

(f) Google.ca’s verification key, used to verify the signature on google.ca’s ECDHE public key. Everyone knows it.

(g) Google.ca’s ECDHE public key, sent to client for key agreement. Everyone knows it.

(h) Google.ca’s ECDHE private key, used to generate the corresponding public key, and to apply to client’s public key to form shared secret. Only Google.ca knows it.

(i) Client’s ECDHE public key, sent to google.ca for key agreement. Everyone knows it.

(j) Client’s ECDHE private key, used to generate the corresponding public key, and to apply to google.ca’s public key to form shared secret. Only client knows it.

(k) Shared secret. It is the result of ECDHE key exchange, also called the pre-master secret. Only client and server know it.

(l) Master secret. Derived from pre-master secret and client/server random values, and used to derive the following symmetric key. Only client and server know it.

(m) Client-write symmetric encryption key. Only client and server know it.

(n) Server-write symmetric encryption key. Only client and server know it.

(o) Client-write MAC key. Only client and server know it.

(p) Server-write MAC key. Only client and server know it.

See The First Few Milliseconds of an HTTPS Connection, Generating Lots of Keys section.

You have:

• cient_write_MAC_secret[SecurityParameters.hash_size]
• server_write_MAC_secret[SecurityParameters.hash_size]
• client_write_key[SecurityParameters.key_material_length]
• server_write_key[SecurityParameters.key_material_length]
• client_write_IV[SecurityParameters.IV_size]
• server_write_IV[SecurityParameters.IV_size]

Although whether you'd call the IVs keys or not is another matter (and also they may not be used, e.g. in AES stream cipher mode).

Also you will have the private and public keys in the certificate.

Both parties know all the above keys, with the exception of the private key which only the server knows. MACs are used to authenticate each message, and write_keys are used to encrypt them. Note that the client and server use different keys to encrypt messages.

The public and private key pair are used to authenticate the server - that is, the client knows that they are talking to the correct server and that the connection has not been intercepted. This is either because the client encrypts a secret that can only be decrypted by the server with its knowledge of the private key, or that the server sends random numbers (in the case of Diffie-Hellman) that are signed by the private key. The client can use the public key to verify the signature.