In asymmetric cryptography:
- The private key is used for signing and deciphering/decrypting.
- The public key is used for verifying signatures and enciphering/encrypting.
See the glossary of the TLS specification:
public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can
only be decrypted with the associated private key. Conversely,
messages signed with the private key can be verified with the public
key.
In your example, you do indeed use the public key of the second certificate (a CA certificate) to verify the signature of the first certificate (an End Entity Certificate).
However, this step only establishes trust in the certificate itself. How you're going to use the public key of that EEC will depend on what it's used for.
When the certificate is presented by the server in SSL/TLS, the public key will be used as part of the handshake, to prove that the remote server has indeed the private key for the certificate it's using. Whether it's used for encrypting or verifying a signature depends on the details of the cipher suite used during this connection, more specifically, it depends on whether RSA or Diffie-Hellman (authenticated) key exchange is used.
A key point of the TLS handshake is to establish a shared pre-master secret between client and server. When using RSA key exchange, the client encrypts the pre-master-secret and sends it to the server (who is the only one able to decrypt it). When using DH, the client verifies the signature of the temporary parameters sent by the server during the DH exchange: the end result is also a shared pre-master-secret. The end-result is the same, though. If you really want to understand the difference between these two approaches, you'll probably have to read the TLS specification in details.
Other protocols and applications can make use of X.509 certificate (for example, e-mail signing/encryption with S/MIME). The public key in the certificate will always be used for one of:
- encrypting a piece of data that can only be decrypted by the entity who is identified by this certificate (i.e. the legitimate holder of the corresponding private key).
- verifying that a piece of data was signed by this entity.
The details of what that piece of data is and how it is used will vary depending on the protocol and application.