Certificates are useful because even if you have a key pair, that doesn't mean you can just send someone your public key and the receiver will know that **you** control the corresponding private key. There must be some way for the receiver to associate that key with your **identity** (your "self"). Otherwise, an attacker could just send the server his public key, claiming that it's yours, and the message would be sent to him (or, conversely, you could receive a public key from a fake server, and receive a message that is properly encrypted, signed, but didn't come from who you think it came).

One way to exchange keys securely would be in-person, but that's cumbersome and not always feasible. Another option is to use a trusted third-party in the process - Person A **signed** the public keys of both Person B and Person C and associated each key with the holder's ID, so as long as B has a copy of A's public key he can **verify** that C's key matches C's ID (even if that key/certificate was sent through an insecure channel). Thus, B can send confidential messages to C (and, as pointed out in [AJ Henderson's answer][1], the converse is also necessary if B wants to sign the message - C must have A's public key in order to verify B's identity).

So, answering your question, the certificates play a role in your process in the public key exchanging phase, everything else goes like you described. The contents of a certificate are one public key associated to one identifier (be it a domain name, or something else that uniquely identifies you, and that an honest third-party would not sign if they didn't know/trust you). And for who owns what, typically both own a list of trusted third-parties, used for verification, but nothing stops you from having also a list of known certificates from trusted individuals (in which case it doen't matter whether or not a third party signed them).


  [1]: http://security.stackexchange.com/a/32160/6939