The mathematics required for asymmetric cryptography are considered too expensive for online communications, so TLS starts by establishing a shared key between the parties, using a protocol called Diffie-Hellman-Merkle key exchange (or often just Diffie-Hellman).
Diffie Hellman (between hosts A and B) depends on a mathematical "mixture" algorithm, satisfying the following properties:
Using this algorithm, Diffie Hellman Merkle key exchange proceeds as follows:
If A wishes to communicate with B over a network controlled by E, E can perform a "man-in-the-middle attack": it can fool A into believing that it is B, and it can fool B into believing that it is A.
This can only be thwarted by using an out-of-band mechanism; some method of communication that E does not control. For example, A and B could establish a shared key using postal mail or telephone, or by physically meeting.
Out-of-band communication is expensive; it is certainly impractical to send a letter to facebook requesting a key whenever you want to log into their website. Digital Certificates provide a mechanism that minimizes the overhead of out-of-band communication.
A Certificate Authority is a company or organization whose role is to vouch for the integrity of other parties. Every party wishing to establish a secure TLS connection to some party contains a list of the public keys of certificate authorities that they trust. You can find out which certificate authorities your web browser trusts (and thus you also) by examining the security settings of your web browser.
You can think of the process of obtaining this list as the out-of-band communication that the CA performs with you.
The party wishing to verify their identity (such as trustedbank.com) communicates with the certificate authority using a secure out-of-band channel. The certificate authority gives mybank.com a statement that says "mybank.com's public key is Kbank", signed with kCA.
At this point, the CA's work is done. When You want to communicate with Bank.com, you first connect to bank.com and request their public key and certificate. They respond, and you are able to verify that the certificate has been signed by a CA you trust.
Once you have verified the certificate, you can use asymmetric encryption using the bank's public key to establish a shared secret (also called a session key); you can then use symmetric encryption with this key to encrypt and sign the remainder of the data to be transmitted.
Just as with DNS, there are a small number of trusted "root" CAs. They are able to delegate their signing authority to other CAs. For example, Cornell may have its own CA, which has its own public/private key pair (say kCornell and KCornell). A root CA has given the Cornell CA a certificate that says "Cornell is allowed to sign certificates in the .cornell.edu domain, and its public key is KCornell". A host wishing to obtain a cornell.edu certificate can then communicate (out-of-band) with Cornell, to obtain a certificate chain:
Anyone who trusts the CA will be willing to verify the first certificate; this then allows them to verify the second certificate.