This assumes that you know the basics of public key authentication and how a web browser communicates with a web server through a domain name.
The interaction is between the user's web browser and the company's web server.
Public Keys and Private Keys
The web server has a public key and a private key.
The private key can decrypt a message encrypted by the public key.
The public key can decrypt a message encrypted by the private key.
The certificate authority has their own public key and private key.
The web server sends its company information, public key, and the domain name (to be associated with the SSL certificate) to the certificate authority.
The certificate authority sends a confirmation message to the email address associated with the domain name, in order to prove that this request was made by the genuine owner of the domain name.
At this point, the certificate authority will wait until the domain name owner validates the request by email.
The certificate authority encrypts the web server's domain name, company info, and public key using their own private key.
The certificate authority sends the encrypted result to the web server.
This result is the SSL certificate, a text message containing the domain name, company info, and public key of the web server that has all been encrypted with the private key of the certificate authority.
The web server sends this certificate to the user's browser.
Trusted Certificate Authorities
The web browser comes pre-loaded with a list of trusted certificate authorities and their public keys.
The web browser decrypts the certificate using the public key of the corresponding certificate authority.
At this point, the web browser knows that the certificate and its contents are trustworthy because only a message encrypted with the certificate authority's private key could have been coherently decrypted by that certificate authority's public key.
The web browser now knows the trusted company info, public key, and domain name that is supposed to be associated with the web server, which is still suspicious.
The web browser confirms that the domain name on the certificate matches the actual domain name of the web server.
At this point, if the domain names match, the web browser determines that the web server is trustworthy enough to send encrypted data to.
Also at this point, the web browser determines that it can use the trusted public key of the certificate to encrypt its messages because only the private key of the genuine web server can decrypt that message.
Note that if an untrusted public key was used (not going through the certificate authority verification), the web browser may have encrypted and sent sensitive information only to be decrypted by the private key of a malicious server! In other words, it is imperative that the public key be trusted because encrypting a message with it is the only line of eavesdropping defense for the information that the web browser sends out.
Moving on, the web browser encrypts its message using the trusted public key and sends the encrypted message to the web server.
The web server decrypts the message with the genuine private key, if it has one, then reads the decrypted message successfully.
Shared Secret Key
When the web server responds to the web browser, that message must be sent securely as well.
The web browser could copy what the web server just did (excluding the certificate authority process) by generating a public key and private key for itself then sending its public key to the web server. This would establish a secure connection called 2-way asymmetric encryption. However, such communication is computationally taxing (relatively speaking).
So the standard approach is to use a shared secret key that can encrypt a message and also decrypt it.
The web browser generates a secret key, encrypts it using the trusted public key, then sends it to the web server.
If the web server is genuine, it will be able to decrypt the secret key successfully.
At this point, both the web browser and the web server have a shared secret key that they can use to encrypt and decrypt further communications henceforth.
For further reading: